PBS 3.0 Storage Sync Job Option transfer-last funktioniert nicht wie erwartet

[florian.schroen]

Hallo,
ich habe einen Sync Job erstellt mit transfer-last = 2 un eine Kopie mit überschaubarer Speicherbelegung zu erhalten.

Danach habe ich transfer-last = 7 gesetzt, weil doch noch recht viel Platz auf dem lokalen Storage ist.

Es werden aber keine weiteren (alten) Backups kopiert.
Ich interpretiere das Log so, das alle Backups älter als das neueste übersprungen werden.
Das wiederspricht für mich aber der transfer-last Intention.

Kann mir das bitte jemand erklären?

Backups auf remote: 35
Backups auf local: 2

2023-07-14T18:19:15+02:00: ----
2023-07-14T18:19:15+02:00: Syncing datastore 'nas-nfs', namespace 'bare-metal' into datastore 'local', namespace 'bare-metal'
2023-07-14T18:19:15+02:00: found 1 groups to sync
2023-07-14T18:19:15+02:00: sync group host/apphost
2023-07-14T18:19:15+02:00: skipped: 34 snapshot(s) (2023-01-28T23:00:01Z .. 2023-07-12T22:00:01Z) - older than the newest local snapshot
2023-07-14T18:19:15+02:00: re-sync snapshot host/apphost/2023-07-13T22:00:02Z
2023-07-14T18:19:15+02:00: no data changes
2023-07-14T18:19:15+02:00: percentage done: 100.00% (35/35 snapshots)
2023-07-14T18:19:15+02:00: Finished syncing namespace bare-metal, current progress: 0 groups, 35 snapshots
2023-07-14T18:19:15+02:00: ----

# cat sync.cfg
sync: s-a0d3fd88-123a
        comment test  sync
        ns
        owner root@pam
        rate-in 50 MiB
        remote localhost
        remote-ns
        remote-store nas-nfs
        remove-vanished true
        schedule 10,19:30
        store local
        transfer-last 7

Hier wird von einem nfs storage (produktives Backup-Ziel; Sata HDD NAS) auf einen lokalen nvme storage (neu) gesyned. Später soll das Backup auf den local storage erfolgen und später mittels sync job auf das nfs übertragen werden.

 

[ProxiumMoxium]

Hey,

hast du hierfür eine Lösung gefunden gehabt?
Ich frage mich gerade Dasselbe

 

[fabian]

sync transferiert immer nur snapshots die nach dem letzten lokal bereits vorhandenen snapshot erzeugt worden sind (sonst wuerde jeder sync ein davor gemachtes prune auf target seite wieder rueckgaengig machen). eine option um aeltere, fehlende oder korrupte snapshots ebenfalls zu syncen ist in arbeit.

 

[ProxiumMoxium]

Danke für die Antwort - gleichwohl sie Inhaltlich unbefriedigend ist

Spricht heiß´t für mich: Die letzten beiden gesyncten Stände Löschen und alles neu syncen lassen...
Also 200 GB erneut über die WAN Leitung prügeln

 

[fabian]

solange du keine GC machst, sind die chunks der letzten beiden snapshots ja schon da und muessen auch nicht nochmal uebertragen werden..

 

[ITT]

Ich steh da auch gerne mal vor diesem Problem.
Wie umgehe ich dies?

Ich mache zB. wie oben beschrieben transfer-last = 2 in einen definierten Namespace.
Will ich anschliessend nun zB. transfer-last = 7 erreichen, funktioniert das wie oben beschrieben eben nicht.
Also gehe ich her und lege einen temporären Namespace an, synce diesen mit dem vorherigen Namespace OHNE der transfer-last Funktion.
Danach lösche ich den Quell-Namespace, lege diesen gleich wieder an und synce vom temporären (ebenfalls ohne transfer-last).
Anschliessend kann ich den temporären wieder entfernen.

Der ursprüngliche Namespace ist nun nicht mehr von der transfer-last-Geschichte "vorbelastet".

Schöner Workaround

Anders gesagt, wenn man mal durchschaut hat, was der PBS kann und was er NICHT kann, ist man in der Lage die positiven & negativen Eigenschaften auszunutzen.

 

[fabian]

wie oben geschrieben - du kannst auch sicherstellen dass am ZIel keine GC passiert, dann die Gruppe(n) loeschen und anschliessend mit neuem transfer-last syncen (die bereits vorher gesyncten chunks werden dann wiederverwendet, d.h. fuer die bereits einmal gesyncten snapshots werden nur die metadaten, fuer die "neuen" - eigentlich aelteren - werden die noch fehlenden chunks gesynct). nach dem der neue sync durch ist, kannst du dann GC wieder anmachen..