Backup

[D@ve]

So, System läuft einigermaßen.
Jetzt geht es daran, ein Backup einzurichten. Will in den Wechselrahmen eine Platte einhängen, die den gesamten Server spiegelt, so dass ich die außerhalb aufbewahren kann.
Ich vermute mal, dass eine Kopie mit rsync da am meisten Sinn macht (habs mal getestet, scheint ganz gut zu funktionieren), oder gibt es Alternativen?

Macht hier auch ZFS Sinn, oder ist dafür ein anderes Filesystem für den Zweck empfehlenswerter? FAT32 hätte ja z.B. den Vorteil, dass ich auf die Daten zur Not auch mal von einem Windows System zugreifen kann.

Kann ich die Partitionen mit Boardmitteln irgendwie verschlüsseln (so dass ich die Platte auch in dritte Hände geben kann)?

Vielen Dank
Gruß, Dave

[Princo]

Wenn du jetzt ein ZFS-System hast, dann nimmst du für das Backup nicht rsync, sondern Snapshots sowie den zfs send/receive Befehl.
Ja, man kann es so einrichten, daß die Backup-Platte verschlüsselt ist.

Grüße
Princo

[D@ve]

Ja, man kann es so einrichten, daß die Backup-Platte verschlüsselt ist.

Wie geht das? Unter Disk->encryption taucht die Platte nicht auf. Unter Disk->ZFS finde ich nirgendwo eine Einstellung dazu...

Ja, man kann es so einrichten, daß die Backup-Platte verschlüsselt ist.

Was bietet das für Vorteile gegenüber rsync? Unter Snapshot fragt er aber nur nach einem Verzeichnis und nicht nach einem Ziel, wo er das speichern soll...

Gruß, Dave

[Princo]

Ja, man kann es so einrichten, daß die Backup-Platte verschlüsselt ist.

Wie geht das? Unter Disk->encryption taucht die Platte nicht auf. Unter Disk->ZFS finde ich nirgendwo eine Einstellung dazu...

Richtig, weil NAS4Free hier quasi modular funktioniert, d.h. zuerst werden die unformatierten Festplatten auf Blockebene verschlüsselt, und dann werden die weiteren Aktionen (formatieren, RaidZ-Einrichtung) mit den verschlüsselten Platten durchgeführt.
Wie das geht ist prinzipiell hier beschrieben: http://wiki.nas4free.org/doku.php?id=do ... encryption
Allerdings wird hier die Einrichtung eines SoftRaids mit UFS beschrieben.
Daher muß man ab dem Punkt "Format Encrypted disk" mit der Einrichtung von ZFS weitermachen.

Was bietet das für Vorteile gegenüber rsync? Unter Snapshot fragt er aber nur nach einem Verzeichnis und nicht nach einem Ziel, wo er das speichern soll...

Ganz einfach: Bei send/receive mit Snapshots "weiß" das System ganz exakt, welche Dateien verändert wurden, und daher übertragen werden müssen. Das ist bei rsync nicht unbedingt der Fall. Bei rsync müssen, genau genommen, sämtliche Dateien byteweise auf Veränderungen verglichen werden, damit ein vergleichbares Verhalten gegenüber zfs send/receive erreicht wird.

Die Nutzung von zfs send/receive hat weitere Vorteile:
Man hat nach dem Abgleich auf beiden Systemen den Vorher/Nachher Stand zum letzten Abgleich.
Bei rsync müssen Original- und Backup-Dateisystem gleichzeitig gemountet und irgendwie miteinander verbunden sein.
Das ist bei zfs send/receive nicht nötig. Hier kann der Abgleich auch mit Hilfe eines kleineren Transportmediums durchgeführt werden.

Das sind hier nur die imho wichtigsten Argumente.

Grüße
Princo

[D@ve]

Danke Crypt läuft... Hatte die falsche Reihenfolge...

Gibt es irgendwo ein Tutorial für Backups per Snapshot?

[Princo]

Gibt es irgendwo ein Tutorial für Backups per Snapshot?

Ja, hier: http://docs.oracle.com/cd/E19253-01/820 ... index.html

Grüße
Princo

Edit: Ich habe doch noch etwas Zeit gefunden.
Hier die Methode um den Pool Daten auf den Pool Backup im gleichen System zu backuppen:

Erstabgleich, Initialbackup:
Der Pool Backup sollte leer sein, am besten frisch angelegt.
Über eine ssh-Terminalsession:

Code: Select all

zfs snapshot -r Daten@2014-05-05
zfs send -R Daten@2014-05-05 | zfs receive -vF Backup

Weitere Abgleiche verlaufen dann nach folgendem Muster:

Code: Select all

zfs snapshot -r Daten@2014-05-06
zfs send -RI Daten@2014-05-05 Daten@2014-05-06 | zfs receive -vF Backup
zfs destroy -r Daten@2014-05-05 #(wenn man mag)

Hinweise dazu:
Wichtig ist, daß die beiden Pools nach dem Erstabgleich immer über den letzten Snapshot "verbunden" bleiben.
Es kann ein Problem auftreten, wenn auf dem "Daten"-Pool neue Datasets angelegt werden, UND bereits mit Daten gefüllt werden, bevor der nächste Abgleich stattgefunden hat. Probier das einfach aus, dann siehst du, was ich meine. (Es wird ein leeres Dataset übertragen, beim nächsten Abgleich werden nur neue Daten des Datasets übertragen. Daten die gleich nach der Anlage des Datesets raufkopiert wurden, sind nicht im Backup.).

Falls du nach dem Abgleich über Disks|ZFS|Configuration|Synchronize ein Synchronize durchführst, wirst du mit einem ziemlich lästigen Fehler des Web-GUIs konfrontiert: Das funktioniert nämlich nicht richtig, wenn du verschiedene Pools mit gleichnamigen Datasets im System hast. Es werden dir nur die Datasets eines Pools angezeigt. Dafür wurde bereits ein Ticket aufgemacht, das Problem wurde aber wohl noch nicht behoben.
Da du den Backup-Pool immer aus dem System nimmst, ist das Problem in der Paxis nicht sooo relevant. Unschön ist es dennoch.

Der Backup-Pool ist für sämtliche anderen Datenablagen tabu. Beim Abgleich werden sämtliche Daten, welche nicht auch im Datenpool enthalten sind, gnadenlos gelöscht.

Auch wenn es einen in den Fingern juckt: Diese Form des Backups sollte nicht automatisiert werden (dazu hatte ich dir bereits etwas erzählt).

Noch etwas, und das ist ganz besonders wichtig:
Wenn du vorhast, an deinem Daten-Pool tiefgreifende Arbeiten durchzuführen (ihn beispielsweise mit zus. Festplatten zu erweitern), dann mach kurz vorher ein komplettes neues Initialbackup.

Ein solches Initialbackup sollte man auch ohne anstehende Systemarbeiten einmal im Jahr machen. Das kann man dann auch gleich mit einem Initialrestore verbinden. Stichwort "Defragmentierung".

Edit2: Noch etwas Wichtiges: Der Backup-Pool sollte natürlich auch mit Redundanz (also ZFS-Mirror oder RaidZ) versehen sein. Eine einzelne Festplatte mit ZFS freut zwar den Sparfuchs, ist hier aber nicht ausreichend.

[D@ve]

Okay, nachdem was du hier schilderst ist das mit den Snapshots wohl nicht das richtige.
Hier geht es um Komplettbackups, die etwa im Drei-Monatsrythmus gemacht werden und außer Haus gebracht werden. Für den Worst-Case, dass das Hausabbrennt etc.
Das heißt ich habe zwei weitere Platten (da nehme ich meine beiden alten 1TB WD black, die reichen erstmal) und die ich dann immer abwechselnd tausche. Bei diesem Zeitabstand kann ich dann auch nicht gewährleisten, dass ich da nicht neue Datasets angelegt habe.
Dass ich darüber dann eine Historie wiederherstellen könnte, brauche ich da garnicht.

Aber für ein wöchentliches Inhouse-Backup wäre das ggF eine gute Lösung...

Eine einzelne Festplatte mit ZFS freut zwar den Sparfuchs, ist hier aber nicht ausreichend.

Ist das wieder ein ZFS-Problem? Alternative würde ich dann nämlich doch auf FAT32 setzen.
Eigentlich will ich kein Mirroring sondern lieber zwei unabhängige Platten auf die ich abwechselnd sichere, das bietet viel größere Vorteile.

Diese Form des Backups sollte nicht automatisiert werden (dazu hatte ich dir bereits etwas erzählt).

Und ich hatte Dir auch gesagt, dass ich das anders sehe . Ein Backup muss optimalerweise zu 100% automatisch laufen ohne dass man einen Finger krumm machen muss, sonst macht man es eh im Zweifelsfall garnicht. Ich kenne diverse Fälle von hohem Datenverlust obwohl eine perfekte, technische Backup-Strategie vorhanden war, die aber daran gescheitert ist, dass der MItarbeiter einmal am Tag auf einen Knopf hätte drücken müssen...

Gruß, Dave