Speichern in S3 von zweitem PBS

[GMBauer]

Grüeziwoll beinand,

bitte entschuldigt die sicher sehr doofe Frage:

Folgende Situation:
PVE01 mit x VMs, die gesichert werden sollen.
PBS01, Backupziel von PVE01, verfügt über lokalen Datastore01
PBS02, synct alle Backups von PBS01 zu sich in den lokalen Datastore02

Nun soll PBS02 alle Backups auch auf einen S3-Endpoint syncen.

Dazu habe ich auf PBS02 einen pull-sync angelegt, der kann aber nur Inhalte von Datastore01 (also auf PBS01) auf den S3 schieben. Was muss ich machen, damit Inhalte von Datastore02 (also vom PBS02) auf den S3 geschoben werden?

Ich habe irgendwo einen Denkfehler, aber ich bin zu dumm...

 

[Bu66as]

Kein Denkfehler, das ist eher eine Einstellung im Sync-Job. Ein Pull-Sync kann auch von einem lokalen Datastore kommen. Leg auf PBS02 beim S3-Datastore einen neuen Pull-Sync-Job an. Bei "Source Remote" wählst du statt PBS01 einfach Local und als Quell-Datastore dann Datastore02. Damit synct PBS02 von seinem eigenen Datastore auf den S3-Datastore. Dein jetziger Job hat als Remote PBS01 drin und holt deshalb aus Datastore01.

Wenn du das zeitlich steuern willst, den Schedule so legen, dass er nach dem Sync PBS01 → PBS02 läuft. Dann hast du auf S3 immer den aktuellen Stand. Welche PBS-Version läuft bei dir auf PBS02? Bei den S3-Datastores hat sich da zwischen den Versionen einiges geändert.

 

[GMBauer]

Oh Mann, dankeschön. Vor lauter locals und remotes habe ich den Überblick verloren...

PBS-Versionen sind beide die aktuellsten.

Und von der Zeit her ist das kein Problem. Ich würde das so einstellen: 21 Uhr letztes Tagesupdate auf den PBS01, um 22 Sync auf PBS02. Um 23 Uhr hoch auf den S3.

Neues Problem: Der PBS02 hat auf den S3 hochgeladen von 21 Uhr (läuft noch im Testbetrieb) bis 2.30 Uhr. Dann ist der Upload komplett abgebrochen.

Fehlermeldung:

2026-11-03T01:52:45+01:00: [vm/202]: 2026-11-02T14:38:12Z: start sync
2026-11-03T01:52:45+01:00: [vm/202]: 2026-11-02T14:38:12Z/qemu-server.conf.blob: sync archive
2026-11-03T01:52:45+01:00: [vm/202]: 2026-11-02T14:38:12Z/drive-tpmstate0-backup.img.fidx: sync archive
2026-11-03T01:52:45+01:00: [vm/202]: 2026-11-02T14:38:12Z/drive-tpmstate0-backup.img.fidx: downloaded 6.727 KiB (459.735 KiB/s)
2026-11-03T01:52:45+01:00: [vm/202]: 2026-11-02T14:38:12Z/drive-scsi0.img.fidx: sync archive
2026-11-03T02:30:16+01:00: removing backup snapshot "/mnt/datastore/Cache/vm/202/2026-11-02T14:38:12Z"
2026-11-03T02:30:20+01:00: [vm/202]: 2026-11-02T14:38:12Z: cleanup error - unexpected status code: 503 Service Unavailable
2026-11-03T02:30:20+01:00: [vm/202]: percentage done: 58.33% (1/2 groups, 1/6 snapshots in group #2)
2026-11-03T02:30:20+01:00: [vm/202]: sync group vm/202 failed - 2026-11-02T14:38:12Z/drive-scsi0.img.fidx: handler failed: failed to upload chunk to s3 backend - upload failed: unexpected status code 504 Gateway Timeout
2026-11-03T02:30:20+01:00: Finished syncing namespace TestHetzner, current progress: 2 groups, 0 snapshots
2026-11-03T02:30:20+01:00: queued notification (id=a85b937c-2a6d-4429-ae74-9c1849ae5162)
2026-11-03T02:30:20+01:00: TASK ERROR: sync failed with some errors.

Ist aber ein Bucket, in dem ich schon ganz schön rumgemacht habe... Bin noch im Experimentierstadium. Laut anderen Forumsbeiträgen liegt das an der Infrastruktur in Helsinki bei Hetzner und soll bei Buckets in Nürnberg nicht vorkommen. Werde mal dahin wechseln.

btw: Die Anzeige "percentage done" hat mit dem tatsächlichen Datenumfang nichts zu tun, oder? Das beruht nur auf der Zahl der Snapshots und Gruppen... Seltsam...