ZFS-Synchronisierung über unzuverlässiges, langsames WAN. ZFS-Replikation oder rsync?

Ich wurde beauftragt, eine externe Sicherung über das WAN durchzuführen. Beide Speicherboxen sind FreeBSD-basierte NAS-Boxen, auf denen ZFS ausgeführt wird.

Ein- bis zweimal pro Woche werden 15 bis 60 GB Fotodaten auf das Office-NAS übertragen. Meine Aufgabe ist es, herauszufinden, wie diese Daten mithilfe der SEHR LANGSAMEN DSL-Verbindung (~ 700 KBit / s Upload) so zuverlässig wie möglich außerhalb des Standorts abgerufen werden können. Die Empfangsbox ist mit 30 MBit / s nach unten und 5 MBit / s nach oben in einem viel besseren Zustand.

Ich weiß, dass das Tragen einer Festplatte außerhalb des Standorts Daten viel schneller verschieben würde, aber in diesem Fall ist dies keine Option.

Meine Optionen scheinen entweder zu sein:

• ZFS inkrementelles Senden über ssh
• Rsync

rsync ist eine altehrwürdige Lösung und verfügt über die überaus wichtige Fähigkeit, einen Sendevorgang fortzusetzen, wenn etwas unterbrochen wird. Es hat den Nachteil, dass es über viele Dateien iteriert und nichts über Dedup weiß.

Das Senden von ZFS-Snapshots überträgt möglicherweise etwas weniger Daten (es weiß viel mehr über das Dateisystem, kann dedupieren, die Metadatenänderungen effizienter verpacken als rsync) und hat den Vorteil, dass der Dateisystemstatus ordnungsgemäß dupliziert wird, anstatt nur zu kopieren Dateien einzeln (was festplattenintensiver ist).

Ich mache mir Sorgen um die ZFS-Replikationsleistung [1] (obwohl dieser Artikel ein Jahr alt ist). Ich mache mir auch Sorgen, dass ich die Übertragung erneut starten kann, wenn etwas ausfällt - die Snapshot-Funktion scheint dies nicht zu beinhalten. Das gesamte System muss vollständig freihändig sein.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

Mit beiden Optionen sollte ich in der Lage sein, die Priorisierung des Datenverkehrs aufzuheben, indem ich ihn über einen bestimmten Port weiterleiten und dann den QOS auf den Routern verwenden kann. Ich muss bei jeder Übertragung erhebliche negative Auswirkungen auf die Benutzer an beiden Standorten vermeiden, da dies mehrere Tage dauern wird.

Also ... das ist mein Denken zu diesem Thema. Habe ich gute Optionen verpasst? Hat noch jemand etwas Ähnliches eingerichtet?

1. Wenn Sie maximal 6 GB pro Tag übertragen können (vorausgesetzt, kein Overhead und kein konkurrierender Datenverkehr) und Sie "15-60 Gigs" mit einer Häufigkeit von "ein- oder zweimal pro Woche" verschieben müssen, entspricht dies 15-120 GB pro Woche oder zwischen 2 und 17 GB pro Tag. Da es notwendig ist, einen Spitzenbedarf zu planen und 17 GB sogar Ihr theoretisches Maximum von 6 GB bei weitem überschreiten , ist es wahrscheinlich, dass Sie ein sehr ernstes Bandbreitenproblem haben. Was braucht es, um die Verbindung zu aktualisieren? Wenn ein Upgrade der Verbindung nicht möglich ist, sollten Sie die Möglichkeit in Betracht ziehen, physische Medien planmäßig (z. B. wöchentlich) zu versenden.

2. Unter der Annahme, dass Sie die Bandbreitenberechnung ein wenig sinnvoller gestalten können, ist rsync wahrscheinlich die beste Option. Das Deduplizierungsbewusstsein wäre beim Replizieren hochredundanter Daten (z. B. Images von virtuellen Maschinen) von großem Wert, sollte jedoch bei eindeutigen digitalen Inhalten (Audio, Video, Fotos) nur einen geringen oder keinen Nutzen haben ... es sei denn, Benutzer sind dies natürlich versehentliches Speichern doppelter Kopien identischer Dateien.

Nach einigen Recherchen glaube ich, dass Sie Recht haben, Schnappschüsse zu senden. Das ZFS SENDund die RECEIVEBefehle können in bzip2 weitergeleitet werden, und diese Datei kann dann mit dem anderen Computer synchronisiert werden.

Hier sind einige Quellen, die ich verwendet habe:

• Das Oracle Solaris ZFS-Administratorhandbuch auf Seite 221 (oder die Webversion hier ) spricht darüber.

• Ich habe auch einen Blog-Beitrag gefunden , der ein einfaches Beispiel dafür gibt. In diesem Blog wurde auch gezeigt, wie der Bitstrom durch bzip2 geleitet und gesendet wird.

Ich hatte keine Beiträge mit Replikationsskripten gefunden, aber ich habe jemanden gefunden, der sein Sicherungsskript veröffentlicht hat . Das heißt, ich habe es nicht verstanden, so dass es Müll sein kann.

Viele auf der Website sprachen davon, einen Cron-Job einzurichten, um dies häufig zu tun. In diesem Fall können Sie replizieren / sichern, ohne die Bandbreite und die Benutzer zu beeinträchtigen, und eine gute Notfallwiederherstellungsfunktion darstellen, da die Offsite-Daten aktueller sind. (Das heißt, nach dem ersten Datenblock beim Start.)

Auch hier denke ich, dass Sie die richtige Idee hatten, Schnappschüsse zu senden. Die Verwendung von SEND/ scheint viele Vorteile zu haben RECEIVE.

EDIT: Nur eine beobachtete video1 video2 das kann suports die Verwendung hilft SEND/ RECEIVEund spricht über rsync (beginnt bei 3m49s). Ben Rockwood war der Sprecher und hier ist ein Link zu seinem Blog .

Was ist der Zweck der Backups und wie muss auf sie zugegriffen werden?

Wenn Ihre Backups hauptsächlich für die Notfallwiederherstellung bestimmt sind, sind ZFS-Snapshots möglicherweise vorzuziehen, da Sie ein Dateisystem auf den genauen Zustand zurücksetzen können, in dem es sich zum Zeitpunkt des letzten Inkrements befand.

Wenn Ihre Backups den Benutzern jedoch auch Zugriff auf Dateien gewähren sollen, die möglicherweise versehentlich gelöscht, beschädigt usw. wurden, ist rsync möglicherweise die bessere Option. Endbenutzer verstehen das Konzept von Snapshots möglicherweise nicht oder Ihr NAS bietet Endbenutzern möglicherweise keinen Zugriff auf frühere Snapshots. In beiden Fällen können Sie rsync verwenden, um ein Backup bereitzustellen, auf das der Benutzer über das Dateisystem leicht zugreifen kann.

Mit rsync können Sie das Flag --backup verwenden, um Sicherungen von geänderten Dateien beizubehalten, und mit dem Flag --suffix können Sie steuern, wie alte Versionen von Dateien umbenannt werden. Dies macht es einfach, ein Backup zu erstellen, in dem Sie möglicherweise alte Versionen von Dateien wie datiert haben

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Sie können dies einfach mit einem Cronjob kombinieren, der einen Befehl find enthält, um alte Dateien nach Bedarf zu löschen.

Beide Lösungen sollten in der Lage sein, genügend Metainformationen über Dateien zu speichern, um als Backup zu fungieren (rsync bietet --perms, --owner usw. Flags). Ich verwende rsync, um große Datenmengen zwischen Rechenzentren zu sichern, und bin mit dem Setup sehr zufrieden.

ZFS sollte die Funktion "Wiederaufnahme des Sendens" erhalten, mit der eine unterbrochene Replikation etwa im März dieses Jahres fortgesetzt werden kann. Das Feature wurde von Matt Ahrens und einigen anderen Personen fertiggestellt und sollte bald vorgelagert werden.

Vielleicht wäre ein WAN-Komprimierungsgerät eine Lösung ...? Wir verwenden Riverbed und sind sehr zufrieden mit ihnen (z. B. wird NetApp SnapMirror sehr gut komprimiert, bis zu 80-90%).