Synology Snapshots - Wie genau funktionieren die?

[ArminA]

Hallo,

es steht die Idee im Raum, ein Veeam-Backup auf einer Synology NAS zusätzlich über SnapShots abzusichern. Jetzt stellt sich die Frage, wie viel Platz dafür verwendet wird.

Da das Veeam Backup große und täglich veränderte Dateien generiert, sind die Änderungen auf Dateiebene täglich sehr groß. Falls die SnapShots der Synology nun auf Fileebene anstatt auf Blockebene funktionieren (was ich vermute), wäre der dafür benötigte Platz sehr groß.

Hat da jemand nähere Infos oder Erfahrungen?

 

[plang.pl]

Willkommen hier im Forum!
Die arbeiten schon auf Blockebene im Zusammenhang mit dem darunter liegenden btrfs Dateisytem. Sprich die Snapshots brauchen keinen Platz, wenn sich keine Daten verändern. Und nur die veränderten Daten brauchen Platz

 

[maxblank]

Beim Veeam Backup werden aber ständig viele Dateien geändert und daher wachsen auch die Snapshots auf dem Synology NAS in diesem Anwendungsfall sehr schnell an.

Ich habe das auch so im Einsatz. Was willst du genau wissen?

Edit: BTRFS-Snapshots finden bei Synology auf Blockebene statt.

Es werden bei mir ca. 4 TB an Gesamtdatenbestand gesichert, tägliches Sicherungsdelta abends hat eine Größe von 96 - 104 GB. Das erste Full- und die folgenden inkrementellen Backups werden dann per Veaam Copy Job aufs NAS geschoben. Dann dort per Snapshots Replication mit einem immutablen Snapshot versehen, die dann 12 Tage aufbewahrt werden.

Größe Backup Veeam: 13 TB
Größe Snapshots: 7,5 TB

In meinem Fall werden also ca. 58% der Größe des Veeam Backups nochmals zusätzlich für Snapshots benötigt. Das ist natürlich vom Speicherverbrauch her für Snapshots ein unglückliches Beispiel und ein hoher Datenverbrauch, den Snapshots normalerweile gerade nicht haben.
Trotzdem ist es mir das bei den ganzen Vorteilen von Snapshots diesen zusätzlichen Speicherverbrauch wert.

 

[ArminA]

Herzlichen Dank für Eure Antworten.

Ich habe Einen Ordner auf der Synology in den Veeam täglich ein Backup generiert (incremental). Der Ordner beinhaltet ca. 11 TB an Daten. Die SnapShots der Synology für eine Woche sind fast 50 TB groß. Veeam zieht ja das Full-Backup täglich am Ende der Kette hinterher, indem es das nächste Incremental-Backup in das Full einbaut. Damit ändert sich die große Datei des Full-Backup logischerweise täglich. Auf Grund des Verhältnisses Daten zu Snapshots von 1:5 hatte ich die Vermutung, dass Synology eben die SnapShots nicht auf Blockebene sondern auf Fileebene macht. NetApp benötigt für viel mehr SnapShots nicht mal 10% des Platzes der Ausgangsdaten. Klar ist Synology nicht NetApp, aber trotzdem ist der von den SnapShots benötigte Platz für mich überdimensional groß.

Das Volume ist Btrfs. Die SnapShots sind immutablen. Das sind sie ja bei maxblanc auch. Das ist ja, wie Du sagst, ansich eine klasse Angelegenheit, der Platz wäre es mir auch wert. Nur stoße ich mit diesem Verhältnis Daten zu SnapShots halt sehr schnell an die Grenzen der Möglichkeiten bezüglich Plattenplatz.

Wenn die Snapshots, so wie bei Dir, ca. 50% der Ausgangsdaten wären, hätte ich kein Problem damit. Mir ist nicht klar, warum das bei mir 1:5 ist. Daher haben mich Eure Erfahrungen interessiert.

 

[maxblank]

Veeam zieht ja das Full-Backup täglich am Ende der Kette hinterher, indem es das nächste Incremental-Backup in das Full einbaut. Damit ändert sich die große Datei des Full-Backup logischerweise täglich.

Das kommt drauf an, was du bei Veeam eingestellt hast. Für mich hört sich das so an, als ob du „Reverse incremental“ eingestellt hast.
Dadurch wächst bzw. verändert sich natürlich das „Veeam Full Backup File“ (vbk) ständig, da es von Veeam nach dem Backup gemerged wird.
Dann ändert sich natürlich aus Sicht von Snapshot Replication die gesamte Datei und es wird täglich immer die gesamte Dateigröße in Form vom Speicherplatz belegt.

Ich würde an deiner Stelle „Incremental“ einstellen und dann zum beliebigen Tag X (z.B. Ende der Woche) ein Synthetic Full fahren. Dann muss Snapshot Replication nur das erzeugte Delta (vib) sichern.

Bei der Backupsicherheit hast du keine Nachteile und es ist laut Veeam bzw. deren Best Practices der gängige Weg.

 

[ArminA]

Danke für Deine Antwort. Das Backup ist incremental (hab ich oben schon geschrieben). Bei incremental ist das Full bei Veeam immer die älteste Datei (ohne zusätzlichen erzwungen Full). Auch bei incremental änderst sich damit das Full täglich, da das darauffolgende Incremental eingemerged wird.

Du sagst: "Dann ändert sich natürlich aus Sicht von Snapshot Replication die gesamte Datei und es wird täglich immer die gesamte Dateigröße in Form vom Speicherplatz belegt."

Also doch auf Fileebene und nicht auf Blockebene!?

 

[maxblank]

Bei mir sieht die Veeam Backup Kette mit meinen Einstellungen bei Veeam für eine Woche so aus.



Am 13.04.2024 wurde das Full erzeugt und seit dem nicht mehr geändert bzw. nicht gemerged. Und diese Datei frisst dann bei neuen Snapshots keinen Speicherplatz, sondern nur die incrementellen Backups. Die werden erzeugt bis Samstag und dann erfolgt ein Synthetic Full.

Block- oder Fileebene spielt in meinen Augen da keine Rolle, da sich die Datei so oder so bei dir geändert hat und neu per Snapshot gesichert werden muss, da zum letzten Snap ein Unterschied besteht.

Wenn Veeam einen kompletten tagtäglichen Merge der VBK durchführt, weiß ich nicht, inwieweit die Metadatenaufzeichung der Snapshots das nachverfolgen kann. Ich gehe hier vom Worst Case aus und daher wachsen bei dir die Snapshots so an.

 

[plang.pl]

So kenne ich das im Zusammenhang mit Veeam auch. Das "Active Full" Backup, also das erste Kettenglied, wird nicht verändert

 

[maxblank]

Bei Incremental nein, bei Reverse Incremental schon.

 

[ArminA]

Das ist bei Veeam nicht so einfach wie es auf den ersten Blick aussieht. Baut man eine Incremental-Kette z.B. mit 7 Tagen Vorhaltezeit, dann wird am ersten Tag ein Full (F) erzeugt. Die nächsten 6 Tage jeweils ein Incremental (I). Ab der 8. Sicherung wird das Full quasi immer einen Tag nach vorne geschoben indem das nächste I rein-gemered wird (weil eingestellt 7 Tage Vorhaltezeit).

Das gilt unter der Annahme, dass KEIN erzwungener Full zwischendrin erzeugt wird. Dann wird es etwas komplizierter, aber im Enddefekt vom Prinzip her nicht sehr verschieden.

Damit ändert sich nach dem 7. Tag die große Datei des Full jeden Tag. Wenn das Mechanismen wie SnapShots nicht auf Blockeben arbeiten, verbraucht das enorm Platz (weil jeden Tag quasi eine komplett neue Datei Full). Systeme auf Blockebene (z.B. NetApp) sehen Änderungen in den Files (Blöcke) und speichern nur diese. Daher spielt es durchaus eine enorme Rolle, ob man hier auf Block- oder Filebene arbeitet.

 

[maxblank]

Wie du an meinen Ausführungen, Screenshots und Erklärungen gesehen hast, klappt es in meinem Fall genau so, wie es in meinen Augen zu erwarten ist.
Und nochmals, die Snapshots bei Synology funktionieren auf Blockebene.



Quelle: https://www.synology.com/de-de/dsm/feature/snapshot_replication

 

[maxblank]

Auch hier wird ab Minute 4:02 die Blockebene von Synology, auf der Snapshots funktionieren, nochmals erwähnt. https://youtu.be/L3jwBGkXy0s?si=Gs7kOnJcTp_f-CQN