Hallo old-papa, hallo kreuzberger,
Es war mir völlig klar, daß die von mir präferierte Methode auf Unverständnis stößt, weil sie (auf den ersten Blick) von den üblichen Methoden abweicht.
Zum Hintergrund: ich habe einge Jahrzehnte als Administrator einer mittelgroßen Organisation gearbeitet, und war dort u.a. auch für das Backup zuständig.
Die von mir beschriebene Methode ist aber nur die eigentliche Kernlösung, d.h. ich habe hier nur das Grundprinzip beschrieben. Die Lösung ist jedoch sehr flexibel.
Natürlich läßt sich diese Methode auch automatisieren, und hier im Forum finden sich auch die entsprechenden Skripte dazu.
Ich rate dennoch von einer Automatisierung ab, dazu später mehr.
Es wurden von euch eine Reihe von Punkten angesprochen, und ich versuche darauf einzugehen.
USB-Platten
Hier sind nicht die Festplatten das Problem, sondern die USB-Chipsets in den Rechnern. Diese entsprechen meist nicht den Standards, was im normalen Betrieb oft nicht auffällt. Wenn man aber versucht 3TB Daten am Stück zu übertragen, kommt es oft zu Problemen. Zudem werden meistens auch keine S.M.A.R.T.-Informationen darüber übertragen. Es hat schon seinen guten Grund, weshalb USB-Platten bei FreeBSD stiefmütterlich behandelt werden, denn die Dinger haben im professionellen Bereich nichts verloren.
Im privaten Bereich sind sie die beste Methode seine Daten zu schreddern. Daher verwende ich für den externen Anschluß ganz einfach eSATA.
Das funktioniert ja nur mit ZFS
Richtig, denn NAS4Free setzt man ja auch gerade deswegen ein, weil man da ZFS hat.
Und wenn man ZFS hat, dann sollte man auch dessen Vorteile nutzen.
Und einer der Vorteile von ZFS sind die Snapshots, und die Möglichkeiten von zfs send/receive.
Der User muß dazu auf die Kommandozeile
Na und? NAS4Free ist kein Consumer-System. Wenn man weiß, was man tut, dann erhält man viel mehr Möglichkeiten, als es ein abgeschlossenes System bieten kann.
Außerdem läßt sich das auch mit Skripten automatisieren (wovon ich abrate).
Warum nicht rsync?
Ich liebe rsync, und setze es hier auch intensiv ein. Allerdings nutze ich es nur für den Abgleich zwischen NAS und PC-Clients. Für den Abgleich zwischen zwei NAS verwende ich zfs send/receive.
Dazu muß man wissen, wie rsync den Unterschied zwischen zwei Dateien ermittelt: Es wird nur verglichen, ob sich das Dateidatum und die Dateigröße unterscheiden. Gibt es da einen Unterschied, wird die Datei übertragen.
Für 99,9% der Dateien mag das ausreichend sein, aber es gibt tatsächlich Fälle, bei denen sich Größe und Datum der Datei nicht ändert, der Inhalt der Datei aber sehr wohl.
Welche Dateien das sind, und ob solche Dateien bei euch vorliegen, kann ich nicht wissen. Das hängt von euren Systemen ab.
Mir ist das erstmalig vor vielen Jahren bei Truecrypt-Containern aufgefallen. Damals war der TC-Client standardmäßig so eingestellt, daß er das Datum der Container-Datei nie geändert hat, auch wenn sich der Inhalt änderte. Das hatte zur Folge, daß rsync die Container-Datei nur ein einziges mal sicherte, und dann nicht mehr.
Nun, ein weiteres Beispiel wären Bilddateien, bei denen man das Dateidatum gerne auf dem Aufnahmedatum setzt. Ändert man jetzt die EXIF- oder IPTC-Informationen, und setzt das Datum der Datei wieder auf das Aufnahmedatum (das macht eure Verwaltungssoftware u.U. automatisch), so kann es sein, daß sich die Dateigröße nicht ändert, und diese Datei nicht neu gesynct wird.
Versteht mich nicht falsch, das sind nur zwei Beispiele aus meinem Bereich. Ihr mögt diese Szenarien bei euren Anwendungen für nicht relevant halten, aber für mich zählt schon alleine die prinzipielle Möglichkeit, daß das auftreten kann.
Natürlich kann man rsync so konfigurieren, daß die Dateien beim syncen inhaltlich verglichen werden (das wäre der Parameter -c), aber dann geht die Abgleichgeschwindigkeit rapide in den Keller.
In der Praxis mache ich daher immer zwei Abgleiche nacheinander. Der Erste ohne den Parameter -c, der Zweite dann mit. Dadurch habe ich sowohl Speed, als auch Integrität. Es ist übrigens erstaunlich, wie viele Dateien dann noch beim zweiten Abgleich übertragen werden.
Es gibt noch einen weiteren Nachteil bei der Verwendung von rsync: Man hat keinen klar definierten Stand des Datenbestandes, wenn während des Abgleichs weiter gearbeitet wird. Das mag für den Heimbereich irrelevant sein, in allen anderen Einsatzgebieten kann aber ein Problem darstellen.
Noch ein Nachteil von rsync gegenüber zfs send/receive:
Sender und Empfänger müssen gleichzeitig miteinander verbunden sein. Bei zfs kann die Übertragung auch asynchron erfolgen (z.B. mittels einer Transportfestplatte). Gerade das ist ein Feature, welches für den Heim-Einsatz relevant ist, wenn man zwar eine streng getrennte Aufstellung haben möchte, die Datenleitungen aber nicht genügend Geschwindigkeit aufweisen, und sich große Datenmengen ändern.
Noch ein Nachteil von rsync:
Die Datasets werden nicht übernommen. Sie werden nur als Verzeichnisse gespiegelt, aber Dinge wie eine eingestellte Kompression werden nicht übernommen.
Ein, nach der erwähnten Methode repliziertes Backup-NAS, kann jederzeit zum Haupt-NAS werden, da alles exakt so übertragen wird, wie es auf dem Haupt-NAS vorliegt. Und das auch noch mit wesentlich höherer Geschwindigkeit.
Wie sieht es mit der Geschwindigkeit aus?
Bei rsync geht die Geschwindigkeit runter, wenn viele kleine Dateien übertragen werden. Außerdem wird es sehr langsam, wenn die Datenintegrität geprüft wird.
Bei zfs send/receive müssen die zu übermittelnden Dateien nicht erst aufwendig ermittelt werden, und die Daten werden als Block übertragen. Dadurch können auch inkrementelle Abgleiche mit voller Bandbreite übertragen werden. Siehe Beispiel weiter unten.
Bei zfs send/receive kann nur der ganze Pool gesichert werden?
Falsch.
Bei zfs send/receive können nur ganze Datasets gesichert werden.
Es gibt zig verschiedene Methoden wie man das mit einer Auswahl der zu sichernden Datasets handhaben kann.
- man kann die zu sichernden Datasets im Skript angeben,
- oder die Dataset-Bezeichnungen aus einer Textdatei lesen,
- oder ein Attribut in den Datasets setzen, welches dann von den Skripten ausgewertet wird
- oder man kann die Datasets hierarchisch organisieren (Pool > Dataset > Unterdataset > Unterunterdataset), und dann nur einzelne Zweige davon abgleichen.
Und: Ja, das geht alles auch mit NAS4Free.
Warum widerspreche ich sämtlichen empfohlenen "Best Practices" in Bezug auf Backup?
Da tue ich nicht, denn in der Praxis lasse ich jeden Tag ein Autosnapshot auf meine Pool erstellen. Damit habe ich zumindest einen (oder beliebig viele) definierte/n gesicherte/n Stand/Stände, der/die mir z.B. bei versehentlich gelöschten Dateien hilfreich zur Seite stehen.
Das ist übrigens etwas, was mit rsync überhaupt nicht funktioniert (stimmt nicht ganz, ist aber nicht so einfach). Da habe ich nur den Stand vom Haupt-NAS, und den von Backup-NAS. Das macht genau zwei Datenstände.
"Best Practices" stellen zwar eine Grundlinie dar, aber wenn etwas noch besser geht, dann sollte man sich da auch weiter entwickeln.
Aber!
Wenn ich (so wie der old-papa) einmal in der Woche mein Haupt-NAS auf mein Backup-NAS synchronisiere, dann lasse ich das auf gar keinen Fall automatisch machen.
Was ist denn, wenn ich mir auf dem Haupt-NAS so einen Verschlüsselungstrojaner eingefangen habe (d.h. ein Client ist davon befallen, und verschlüsselt auch die Shares) und man bemerkt das nicht schnell genug? Dann wird u.U. der ganze schadhafte Datenbestand völlig automatisch auf das Backup-NAS gespiegelt.
Ein ganz tolles Konzept.
Das passiert übrigens gerade "den Besten der Besten":
https://www.heise.de/security/meldung/R ... 57047.html
da sind sicher ganz viele Leute dabei, die sich sklavisch an die "Best Practices" gehalten haben.
Sorry, aber ich bin zu lange in dem Geschäft tätig, als daß ich mich an diesen "Best Practices" stur fest klammere. Ich habe mit den gängigen Backup-Systemen (ja, auch Bandsystemen) gearbeitet, und kenne die Vor- und Nachteile. Meine Rechner (nicht die privaten) stehen verteilt in Bunkern, haben autonome Stromversorgungen und Löschsysteme. Ich habe Sicherheitskonzepte entwickelt, umgesetzt, und erfolgreich im praktischen Einsatz, und dabei rede ich nicht von ein paar Dutzend Büro-PCs.
Mich hat es immer geärgert, daß es für den Heimbereich nichts richtig Passendes gab. Mit NAS4Free hat sich das geändert, auch wenn es dafür noch keine GUI gibt (was kein Nachteil ist).
Das, was ich oben beschrieben habe, bezieht sich darauf, daß man sich einmal in der Woche um den Abgleich kümmern muß. Dabei schaut man dann auch etwas genauer hin. So lasse ich mir zuerst anzeigen, wieviel Daten übertragen werden sollen.
Beispiel:
Mein Haupt-NAS hat gerade einen Datenbestand von 6.78TB
In der letzten Woche haben sich 5,25 GB verändert, oder sind neu hinzu gekommen. Das passt genau.
Auf dem System befinden sich hundertausende Verzeichnisse und Einzeldateien, welche in 31 Datasets organisiert sind, und irgendwo dazwischen gab es ein paar Veränderungen.
Ratet mal, wie lange der Abgleich dauert, wenn man es mit zfs send/receive macht.
Keine zwei Minuten.
Zwei Minuten!!!
Da denke ich doch nicht mal ansatzweise darüber nach, dafür rsync zu benutzen. Vor allem, weil bei ZFS auf jeden Fall auch die Datenintegrität gewährleistet ist.
Zwei Minuten!!!
Noch etwas:
Die Befehle müssen nicht direkt auf der Konsole eingegeben werden.
Man braucht dafür keine zwei Monitore und Tastaturen. Wofür der old-papa dann noch zwei Mäuse braucht, weiß ich allerdings nicht
Nee, das geht ganz einfach über zwei ssh-Sessions, und der Verwendung des tmux-Befehls.
Die Übertragung läuft dann vollständig und direkt zwischen den beiden NAS ab. Ein Monitor-PC ist nicht nötig.
Der Stand der Übertragung kann jederzeit angezeigt werden.
Irgendwas werde ich vergessen haben, aber das kommt dann noch.
Grüße
Princo
)
) Overkill 
