Snapshots mit dem Linux Terminal zu einem anderen NAS migrieren
Das btrfs Dateisystem
Schnappschüsse werden auf einem Synology NAS mit dem btrfs Dateisystem realisiert. Btrfs ist ein sog. Copy-on-write Dateisystem. Dies bedeutet, dass der Zustand der gespeicherten Daten eingefroren werden kann und ab jedem solchen Einfrierpunkt (Snapshot) Änderungen im Dateisystem diesen Zustand nicht verändern sondern Änderungen nur noch in einer parallelen Kette von Datenblöcken hinzu geschrieben werden.
Durch dieses Verfahren kann btrfs rasend schnell nahezu beliebige Snapshots speichern, ohne das System zu belasten. Die Schnappschüsse erfordern ein Minimum an Speicherbedarf. Da nur geänderte Blöcke gespeichert werden müssen nicht geänderte Blöcke nur einmal gespeichert werden, egal in wie vielen Dateiversionen sie vorkommen.
Für die Replikation bedeutet dies, dass man btrfs Snapshots nicht auf Dateiebene kopieren kann, sondern dass sie auf Blockebene kopiert werden müssen. Dieser Punkt macht die Replikation auf ein anderes NAS schwierig.
Snapshots kopieren mit btrfs send und receive
Btrfs implementiert Verfahren, um Snapshots von einem System auf ein anderes System zu übertragen. In der Theorie ist dies recht einfach.
Mit dem list Kommando werden alle Snapshots sortiert nach ID ausgeben. Die ältesten Untervolumen stehen an oberster Stelle. Hier ein Liste von Snapshots für die Freigabe sync auf volume2
btrfs subvolume list -qu --sort ogen /volume2 |grep sync
ID 411903 gen 3081072 top level 257 parent_uuid - uuid 275e8874-b927-b643-8344-364b0e235840 path sync
ID 411905 gen 3081148 top level 276 parent_uuid - uuid 5827cebd-c7ff-fa43-92f9-eccea2c3c790 path @sharesnap/sync
ID 411906 gen 3080898 top level 411905 parent_uuid 275e8874-b927-b643-8344-364b0e235840 uuid 2b1b8b7a-6e2d-d544-a94c-504a3b2cc715 path @sharesnap/sync/GMT+02-2021.09.03-12.45.49
ID 411907 gen 3080901 top level 411905 parent_uuid 275e8874-b927-b643-8344-364b0e235840 uuid 455e684e-f57f-814a-85d8-f63583b09a3e path @sharesnap/sync/GMT+02-2021.09.03-12.46.11
ID 411908 gen 3080903 top level 411905 parent_uuid 275e8874-b927-b643-8344-364b0e235840 uuid d3b8c6f2-2542-6247-899d-f9bb43519b80 path @sharesnap/sync/GMT+02-2021.09.03-12.46.32
Im nächsten Schritt werden alle Sub-Volumes auf „read-only“ gesetzt und alle Sub-Volumes, die kein Snapshot sind, d.h. die keine Parent UUID haben, werden übertragen.
btrfs property set -ts /volume[x]/volume-name ro true
Für die Übertragung muss btrfs auf dem Ziel-NAS mit root Rechten ausgeführt werden. Da Synology NAS Server kein root Login mit Passwort erlauben muss eine Schlüssel-Authentifizierung aufgesetzt werden.
Die Übertragung erfolgt mit dem btrfs send Kommando:
btrfs send /volume2/sync | ssh root@Ziel-NAS "btrfs receive /volume1/"
btrfs send /volume2/@sharesnap/sync | ssh root@Ziel-NAS "btrfs receive /volume1/@sharesnap/"
Problematisch wird der Prozess bei der Übertragung der Snapshots. Snapshots werden wie oben beschrieben kopiert. Ohne Referenz auf ein Parent Volumen werden die Snapshots allerdings aufgelöst und belegen exklusiven Speicher am Ziel. Der Unterschied wird deutlich, wenn man sich die Speicherbelegung auf dem Quell- und Ziel-NAS anschaut.
Auf dem Quell-NAS teilen sich die Schnappschüsse Speicher
ash-4.4# btrfs filesystem du -s --si -g /volume2/@sharesnap/sync/GMT*
Total Exclusive Set shared Filename
0.06GB 0.00GB 0.06GB /volume2/@sharesnap/sync/GMT+02-2021.09.03-12.45.49
0.12GB 0.00GB 0.12GB /volume2/@sharesnap/sync/GMT+02-2021.09.03-12.46.11
0.15GB 0.00GB 0.15GB /volume2/@sharesnap/sync/GMT+02-2021.09.03-12.46.32
0.09GB 0.00GB 0.09GB /volume2/@sharesnap/sync/GMT+02-2021.09.03-12.46.56
Auf dem Ziel NAS wird der Speicher hingegen exklusiv belegt.
ash-4.4# btrfs filesystem du -s --si -g /volume1/@sharesnap/sync/GMT*
Total Exclusive Set shared Filename
0.06GB 0.06G 0.00GB /volume1/@sharesnap/sync/GMT+02-2021.09.03-12.45.49
0.12GB 0.12G 0.00GB /volume1/@sharesnap/sync/GMT+02-2021.09.03-12.46.11
0.15GB 0.15G 0.00GB /volume1/@sharesnap/sync/GMT+02-2021.09.03-12.46.32
0.09GB 0.09G 0.00GB /volume1/@sharesnap/sync/GMT+02-2021.09.03-12.46.56
Auch wenn die Snapshots faktisch kopiert sind und zur Verfügung stehen, so belegen sie auf dem Ziel-NAS ein Vielfaches an Speicher. Ein Kopieren von Snapshots ohne Deduplizierung kommt so allenfalls für sehr kleine Datenbestände in Betracht.
Um die Deduplizierung am Ziel zu erhalten kennt „btrfs send“ die-p Option, mit der die Referenz auf das Elternvolumen angegeben wird. Damit dies funktioniert benötigt das Eltern-Volumen auf beiden NAS Systemen die gleiche UUID. Leider ist dies in der Regel nicht der Fall, was zu der Fehlermeldung „cannot find parent subvolume“ führt.
ash-4.4# btrfs send -p /volume2/sync/ /volume2/@sharesnap/sync/GMT+02-2021.09.03-12.47.23 | ssh root@Ziel-NAS "btrfs receive /volume1/@sharesnap/sync/"
At subvol /volume2/@sharesnap/sync/GMT+02-2021.09.03-12.47.23
At snapshot GMT+02-2021.09.03-12.47.23
ERROR: cannot find parent subvolume
Auf vollwertigen Linux Systemen gibt es verschiedene Ansätze, dieses fehlerhafte Matching aufzulösen. Synology NAS Systeme laufen auf einem stark angepassten und optimierten Linux System auf dem man nur sehr eingeschränkt zusätzliche Software installieren kann. In das UUID Matching einzugreifen wäre nur mit ganz erheblichen Eingriffen ins System möglich. Aus diesem Grund haben wir einen anderen Ansatz entwickelt, Snapshots zu übertragen.
btrfs Snapshots mit rsync kopieren
Grundsätzlich ist es nicht möglich btrfs Snapshots mit rsync zu kopieren. btrfs Snapshots werden auf Blockebene erstellt während rsync auf Dateiebene arbeitet. Durch eine Kombination aus Operationen auf Block- und Dateiebene lassen sich bestehende Snapshots auf einem anderen NAS nahezu identisch erzeugen. Die so erzeugten Snapshots sind zwar nicht auf Blockebene identisch, wie sie es bei einem Transfer mittels „btrfs send“ wären, sie sind aber in den entscheidenden Kriterien Versionierung und Speicherbelegung nahezu identisch.
Vorbereitungen
Die für die Replikation ausgeführten Befehle benötigen root Rechte auf dem Ziel NAS. Da der DSM kein root Login mittels Passwort zulässt ist im ersten Schritte eine Key Authentifizierung einzurichten. Im nächsten Schritt wird mittels rsync eine Kopie des aktuellen Datenstands auf das Ziel-NAS übertragen. Um sicherzustellen, dass sich dieser Datenstand während der Replikation der Snapshots nicht ändert werden allen Usern die Schreibrechte für die Freigabe entzogen. Von dieser Version wird über die Oberfläche ein Snapshot angelegt.
Übertragung der Snapshots
Alle Schnappschüsse einer Freigabe werden mit dem „btrfs list“ Befehl angezeigt:
btrfs subvolume list -qu --sort ogen /$SRCVOLUME |grep $SRCSHARE/GMT |awk -F "path @sharesnap/$SRCSHARE/" '{print $2}'
wobei $SRCVOLUME das Volumen ist, auf dem die Freigabe $SRCSHARE gespeichert ist. Das Ergebnis ist eine Liste aller Snapshots.
GMT+02-2021.09.07-21.54.57
GMT+02-2021.09.07-21.55.22
GMT+02-2021.09.07-21.55.50
GMT+02-2021.09.07-21.56.23
Alle Schnappschüsse, die auf das Zielsystem übertragen werden sollen, werden jetzt der Reihe nach überspielt.
rsync -avz -e '/bin/ssh -i /root/.ssh/id_rsa' --delete --checksum --inplace --numeric-ids --progress -X --syno-acl /$SRCVOLUME/@sharesnap/$SRCSHARE/$SNAPSHOT/ root@$DSTIP:/$DSTVOLUME/$DSTSHARE/
Der Inplace Parameter
Wichtig ist der inplace Parameter. Rsync synchronisiert standardmäßig in temporäre Dateien, die nach vollständiger Übertragung verschoben werden. Dies steht im Konflikt mit der blockbasierten Deduplizierung von btrfs und kann dazu führen, dass Speicherplatz für den gleichen Block doppelt allokiert wird. Ist der inplace Parameter gesetzt werden geänderte Blöcke direkt in die Zieldatei geschrieben. Der Nachteil dieses direkten Schreibens ist, dass im Falle eines Fehlers bei der Übertragung oder einer Unterbrechung, die Zieldatei korrupt sein kann. Es muss sicher gestellt werden, dass der rsync Aufruf vollständig und fehlerfrei durchläuft. Im Zweifel kann der Aufruf wiederholt werden.
Der Checksum Parameter
In seltenen Fällen kann es vorkommen, dass Dateien sich verändern, ohne, dass sich die Dateigröße und das Modifikationsdatum ändern. rsync würde im Standard solche Dateien als gleich klassifizieren. Eine ordentliche Backup Strategie ist darauf ausgelegt, auch solche Fehler mit Hilfe von Snapshots abzufangen. Der Kopiervorgang muss solche Unterschiede erkennen. Durch die checksum Option werden für alle Dateien mit gleicher Dateigröße und gleichem Modifikationsdatum Prüfsummen errechnet und verglichen. Dies stellt absolut identische Kopien sicher.
Die checksum Option ist rechenintensiv und verlangsamt den Prozess erheblich. Liegen die Quelldaten auf einer Freigabe mit aktivierten Prüfsummen und ist die Datenträgerbereinigung kürzlich gelaufen, so kann auf diese Option verzichtet werden.
Der syno-acl Parameter
Der syno-acl Parameter bestimmt, ob Dateien am Ziel mit Access Control Listen oder mit einfachen Linux Dateisystem Berechtigungen angelegt werden. In der Regel sind ACLs immer vorhanden und sollten auch kopiert werden. Ausnahmen bestehen ggf. bei Dateien, die über Skripte oder Linux Tools wie rsync, scp, ftp, usw. direkt auf das System kopiert wurden.
Der numeric-ids Paramter
Dieser Parameter ist relevant wenn Nutzer- und Gruppen-IDs sich zwischen zwei Systemen unterscheiden. Bei dateibasierten Backups von Linux / Unix Systemen ist es häufig wichtig, die Benutzer- und Gruppen-IDs zu erhalten. Dieser Parameter stellt sicher, dass Dateien und Verzeichnisse mit der richtigen ID angelegt werden auch wenn der entsprechende User und die Gruppe am ziel nicht existieren oder andere IDs haben.
Erstellung der Snapshots auf dem Zielsystem
Nach jedem rsync Lauf muss der entsprechende Snapshot auf dem Zielsystem angelegt werden.
ssh root@$DSTIP "btrfs subvolume snapshot -r /$DSTVOLUME/$DSTSHARE/ /$DSTVOLUME/@sharesnap/$DSTSHARE/$SNAPSHOT"
Die Metadaten für den DSM
Aus Dateisystemsicht ist man an dieser Stelle fertig. Die Snapshots existieren sauber im System, nur der DSM kennt sie noch nicht. Die Snapshotsteuerung mit der Snapshot-Replication Anwendung erfolgt über eine Meta-Datei. Für jede Freigabe, aus Dateisystemsicht für jedes Subvolumen, wird eine eigene Meta-Datei gepflegt.
/$SRCVOLUME/@sharesnap/@$DSTSHARE.meta
In der Meta-Datei werden für jeden Snapshot relevante Informationen gespeichert auf die die Snapshot-Replication Anwendung zurück greift.
[GMT+02-2021.09.07-22.32.22]
hide=false
take-by=synoscgi_SYNO.Core.Share.Snapshot_1_create
uuid=a0e963bf-0323-b644-902d-0be886059bd5
lock=true
desc=Init
ruuid=a0e963bf-0323-b644-902d-0be886059bd5
snap_size=271519744
Als abschließenden Schritt müssen diese Einträge für jeden Snapshot erstellt werden.
Es ist elementar wichtig, dass diese Metadatei richtig und vollständig erstellt wird. Existieren Snapshots im System, die dem DSM nicht bekannt sind führt dies an verschiedenen Stellen im DSM zu teils schwerwiegenden Fehlern.
Aufräumarbeiten
Zum Schluss wird der im ersten Schritt angelegte Schnappschuss mit dem aktuellen Datenbestand über die Wiederherstellung reaktiviert und die Rechte für die Freigabe werden zurück gesetzt.
Snapshot Vergleich
Eine Auswertung über den benötigten Speicher der Snapshots zeigt eine sehr ähnliche Deduplizierung. Hier ein Beispiel einer von uns durchgeführten Migration.
Auswertung auf dem Quell-NAS
ash-4.4# btrfs filesystem du -s --si -g /volume2/@sharesnap/BackupS9/GMT*
Total Exclusive Set shared Filename
158.50GB 0.90GB 157.60GB /volume2/@sharesnap/BackupS9/GMT+02-2021.04.01-00.00.03
160.38GB 0.12GB 160.26GB /volume2/@sharesnap/BackupS9/GMT+02-2021.05.01-00.00.04
164.14GB 0.14GB 164.00GB /volume2/@sharesnap/BackupS9/GMT+02-2021.06.01-00.00.03
168.32GB 1.41GB 166.91GB /volume2/@sharesnap/BackupS9/GMT+02-2021.07.01-00.00.03
158.22GB 0.06GB 158.15GB /volume2/@sharesnap/BackupS9/GMT+02-2021.08.01-00.00.04
167.24GB 0.00GB 167.24GB /volume2/@sharesnap/BackupS9/GMT+02-2021.09.08-00.00.03
ash-4.4# btrfs filesystem du -s --si -g /volume2/@sharesnap/BackupS9/
Total Exclusive Set shared Filename
976.80GB 2.63GB 199.91GB /volume2/@sharesnap/BackupS9/
Auswertung nach der Migration auf dem Ziel-NAS
ash-4.4# btrfs filesystem du -s --si -g /volume1/@sharesnap/BackupS9/GMT*
Total Exclusive Set shared Filename
158.51GB 0.89GB 157.62GB /volume1/@sharesnap/BackupS9/GMT+02-2021.04.01-00.00.03
160.39GB 0.05GB 160.33GB /volume1/@sharesnap/BackupS9/GMT+02-2021.05.01-00.00.04
164.14GB 0.06GB 164.09GB /volume1/@sharesnap/BackupS9/GMT+02-2021.06.01-00.00.03
168.33GB 1.33GB 167.00GB /volume1/@sharesnap/BackupS9/GMT+02-2021.07.01-00.00.03
158.23GB 0.04GB 158.19GB /volume1/@sharesnap/BackupS9/GMT+02-2021.08.01-00.00.04
167.26GB 0.00GB 167.26GB /volume1/@sharesnap/BackupS9/GMT+02-2021.09.08-00.00.03
ash-4.4# btrfs filesystem du -s --si -g /volume1/@sharesnap/BackupS9/
Total Exclusive Set shared Filename
976.85GB 2.36GB 200.04GB /volume1/@sharesnap/BackupS9/
Die Reihenfolge, in der Snapshots migriert werden ist für den Speicherbedarf entscheidend. Aktuell unterstützen Synology NAS Datendeduplizierung nur sehr eingeschränkt, z.B. in Active Backup for Business. Eine Deduplizierung auf Volumen-Ebene unterstützen nur wenige Modelle. Selbst bei diesen Modellen gibt es viele Einschränkungen, so können z.B. in Schnappschüssen gespeicherte Daten generell nicht dedupliziert werden. Für die oben beschriebene Vorgehensweise ist es somit entscheidend, in welcher Reihenfolge die Snapshots erzeugt werden.
btrfs kann Änderungen in Dateien sehr effektiv speichern, in dem es nur die geänderte Blöcke speichert. Ist eine Datei in einem älteren Snapshot vorhanden, in einem jüngeren hingegen nicht, so erkennt btrfs dies nicht und speichert die Datei doppelt. Genau das passiert häufig, wenn der älteste Schnappschuss zuerst kopiert wird. Erfolgt die Erstellung der Schnappschüsse in die andere Richtung tritt dieser Effekt wesentlich seltener auf, im Ergebnis können die neu erstellten Schnappschüsse sogar weniger Speicherplatz benötigen als die Ursprünglichen.
Speicherbedarf von Snapshots ermitteln
Über Snapshot Replication kann der von Snapshots belegte Speicherplatz ermittelt werden. Für das obige Beispiel ergeben sich folgende Wert:
Von Schnappschüssen belegter Speicher auf dem Quell-NAS
Von Schnappschüssen belegter Speicher auf dem Ziel-NAS, jüngste Schnappschüsse zuerst kopiert
Von Schnappschüssen belegter Speicher auf dem Ziel-NAS, älteste Schnappschüsse zuerst kopiert
Automatisierung
Sollen viele Snapshots überspielt werden so lässt sich der hier beschriebene Prozess über ein Skript leicht vollautomatisieren.
Die Vorgehensweise kann auch bei sehr großen Datenbeständen angewendet werden, der „Delta Transfer Algorithmus“ von rsync arbeitet äußerst effektiv und zuverlässig.
Spezielle Anwendungen
Snapshots arbeiten auf Synology NAS auf Freigabeebene. Liegen wichtige Daten, die häufig versioniert werden sollen und weniger wichtige Daten auf derselben Freigabe so kann es vorkommen, dass die Schnappschüsse mit unwichtigen Daten aufgebläht werden.
Mit der oben beschriebenen Vorgehensweise können Daten selektiv migriert werden. Schnappschüsse können dabei nur für Unterverzeichnisse erhalten werden. Auf der anderen Seite können Daten auch z.B. im Rahmen einer Umstrukturierung konsolidiert und Schnappschüsse von unterschiedlichen Freigaben zusammengeführt werden. Schlussendlich können Daten zur Rückgewinnung von Speicher selektiv aus Schnappschüssen gelöscht werden .
Über den Autor
Dieser Beitrag wurde durch NAS-Central.de verfasst. NAS-Central vertreibt seit 2005 NAS Server und Lösungen auf NAS Server Basis. Das Angebot gehört zu dem Systemhaus LogicTri aus Trier.
Auf NAS-Central finden sie Komplettlösungen aus den Bereichen Office & Collaboration, Storage & Backup, Virtualisierung, Vernetzung und mobile Lösungen sowie individuelle Lösungen passgenau für ihre Anforderungen.
Für gängige Installationen werden pauschale Installations- sowie Wartungspakete angeboten.
NAS-Server und zugehörige Komponenten können über den angegliederten NAS Server Shop bezogen werden. Dies ist allerdings keine Voraussetzung, um angebotene Services zu nutzen. Services werden im gleichem Umfang auch für Fremdgeräte angeboten.
Besuchen sie die Angebote von NAS-Central.de und Logictri.de und kontaktieren sie den Anbieter gerne, falls sie Hilfe oder ein Angebot erhalten möchten.
