Hi mahlzeit,
bevor ich die zfs send/receive Sache erkläre, möchte ich dich um ein Experiment bitten, und das betrifft deine externe Sicherung per rsync auf die Synology und den Debian Server:
Mache einen ganz normalen Abgleich, und führe gleich danach einen neuen Abgleich durch. Bei dem zweiten Abgleich fügst du beim sendenden rsync den Parameter -c hinzu, und schaltest das Logging ein (--log-file=FILE).
Für mich ist dabei von Interesse, ob bei dir durch den Parameter -c auf einmal zusätzliche Dateien übertragen werden (deswegen die Logdatei).
Solltest du bei deiner normalen Übertragung schon den Parameter -c verwenden, dann brauchst du den Test natürlich nicht durchführen.
Der Parameter -c bewirkt eine zusätzliche Überprüfung der Dateien, weil der rsync bestimmte Dateikonstellationen nicht überträgt. Der zusätzliche Parameter kann allerdings die Übertragungszeit erheblich verlängern.
Nun zum zfs send/receive. Ich hatte das letztens jemanden per Mail geschickt, und kopiere das hier einfach mal rein (daher die kurzen Zeilenumbrüche).
### Erstabgleich ###
Beide Maschinen haben bei mir den gleichen Poolnamen "Daten" (nicht
zwingend nötig).
Erstabgleich zwischen NAS4FreeA und NAS4FreeB (vorzugsweise per
direkter Konsoleneingabe auf den NAS'sen):
NAS4FreeB ist der Empfänger:
Code: Select all
nc -l 9000 | zfs receive -vF Daten
NAS4FreeA ist der Sender:
Code: Select all
zfs snapshot -r Daten@2013-10-26
zfs send -R Daten@2013-10-26 | nc -w 6 NAS4FreeB 9000
### Ende Erstabgleich ###
## Nachfolgende Abgleiche ##
Auf der Empfängerseite der gleiche Befehl wie oben.
Auf der Senderseite
Code: Select all
zfs snapshot -r Daten@2013-10-27
zfs send -RI 2013-10-26 Daten@2013-10-27 | nc -w 6 NAS4FreeB 9000
(-RI ist ein großes R und ein großes Ihh)
### Ende nachfolgende Abgleiche ###
### Wissenswertes ###
Bei dieser Methode wird der ganze Pool übertragen. Dabei werden sogar
die Eigenschaften der Datasets mit transferiert (z.B. Kompression).
Das wird durch den Parameter -R erreicht.
Auf der Senderseite können die übertragenen Snapshots BIS AUF DEN
LETZTEN gelöscht werden (zfs destroy -r Daten@...). Der letzte
Snapshot muß behalten werden.
Wenn man auf der Senderseite einen neuen rekursiven Snapshot anlegt,
sollte man danach keine alten Snapshots mehr löschen. Alte Snapshots
sollte vorher gelöscht werden.
Bei den nachfolgenden Abgleichen kann es auf der Empfängerseite am
Ende eine Fehlermeldung geben ("failed to read from zfs-Stream" oder
so). Das scheint normal zu sein. Nachzählen der Daten ergibt
identische Werte.
Wenn man auf der Senderseite ein neues Dataset anlegt, sollte man dort
gleich einen rekursiven Snapshot für den Pool anlegen, solange das
neue Dataset noch leer ist. Ansonsten kann es beim Abgleich ein
Problem geben (Dataset könnte ohne Daten übertragen werden). Das
scheint ein Bug zu sein.
Der Grund, warum ich auf beiden Systemen den gleichen Poolnamen
verwende: Wenn mir NAS4FreeA komplett abrauchen würde, dann mache ich
einfach NAS4FreeB zu NAS4FreeA, übertrage die Konfig, und kann ohne
weitere Änderungen weiterarbeiten.
### Wichtig ###
Meinen Beobachtungen nach, überträgt zfs send/receive nicht wirklich
blockweise, sondern orientiert sich am Filesystem. Wenn man z.B. ein
komprimiertes Dataset überträgt, werden die Daten zur Übertragung
dekomprimiert, übertragen, und dann auf Empfängerseite wieder
komprimiert. Erkennbar ist das an den unterschiedlichen
Übertragungsraten bei komprimierten Datasets. Das gilt wohl für alle
Kompressionsarten bis auf zle (zle wird vermutlich unverändert
übertragen). Dabei gilt übrigens nicht, ob die Daten tatsächlich
komprimiert sind, sondern wie die Einstellung des Datasets ist. Auf
die Art kann man Datasets per Übertragung quasi nachträglich komprimieren.
### Ende der Mail ###
Noch ein paar Anmerkungen dazu:
Die beschriebene Methode überträgt die Daten unverschlüsselt, und ist auf Geschwindigkeit ausgelegt, damit ideal für den Einsatz im eigenen Netz, und für den Erstabgleich von Offsite-Systemen geeignet.
Die nachfolgenden Abgleiche können auch anders gestaltet werden. Man kann den Backup-Datenstream auch in eine Datei umleiten, diese Datei dann auf eine kleine Transportfestplatte kopieren, die Transportfestplatte an das Zielsystem anschließen, und den Datenstrom auf das Zielsystem einspielen. Damit kann man Szenarien realisieren, bei denen Quell- und Zielsystem nicht miteinander verbunden sind.
Natürlich kann man die Abgleichdaten auch per ssh-Verschlüsselung und mit Komprimierung übertragen.
Worin liegen die Unterschiede zwischen "rsync" und "zfs send/receive"?
rsync ist für die Übertragung zwischen unterschiedlichen (OS) Systemen geeignet. Es ist aber sehr langsam, wenn man auf exakte Datenübertragung Wert legt (dazu dient der obige Test).
zfs send/receive funktioniert nur zwischen ZFS-fähigen Systemen. Es ist extrem schnell und exakt in der Datenübertragung. Zudem kann man OffSite-Szenarien realisieren, was mit rsync nicht geht.
Da mit Snapshots gearbeitet wird, kann während der Übertragung mit dem System weitergearbeitet werden.
Wenn du jetzt schon Daten auswärts lagerst, scheinst du sehr viel Wert auf Datensicherheit (physikalisch) zu legen. Daher solltest du dich intensiv mit den ZFS-Snapshots beschäftigen, denn damit lassen sich viele Fälle abdecken, für die man "früher" Backups verwendet hat. Dazu muß man zwar in einigen Dingen etwas umdenken, aber es ergeben sich völlig neue Möglichkeiten im Vergleich zu den "klassischen" Methoden des Datenmanagements.
Grüße
Princo
Meine Antworten beziehen sich immer auf die englischsprachige GUI. ECC-RAM ist Pflicht beim Einsatz von ZFS.
