Backups sind ein leidiges Thema… Niemand macht sie gerne, aber sie sind durchaus nützlich wenn man sich wieder einmal eine Datei versenkt hat.
Nur – wie backuppe ich am Besten? – Nun, für diese Frage gibt es kein Patentrezept, da es immer auf das System ankommt.
Ein einfaches Vollbackup einer Maschine auf ein anderes System erreicht man sehr einfach mit kommerziellen Tools oder Netcat. Ja, richtig gelesen… netcat. Wichtig dabei ist, dass man exklusiven Zugriff auf die Festplatten bekommt. Dies geht am Einfachsten durch das Booten von einer Live-CD.
Netcat ist nicht nur ein Telnet-Programm sondern eine Art Schweizer Taschenmesser im Bezug auf Netzwerkaktivitäten, wie wir an folgendem Beispiel sehen können:
nc -l -p 666 > image.gz
In diesem Beispiel lassen wir Netcat auf unserem entfernten System laufen, wo die Backups abgelegt werden sollen. Netcat öffnet einen Port (666). Den Output leiten wir in eine Datei.
Auf dem zu backuppenden System lesen wir die Platte mit Hilfe des Befehls dd aus, gzippen und schicken die Daten als Stream an den anderen Netcat.
dd if=/dev/hda | gzip | nc -w 5 remote_ip 666
remote_ip ist dabei die IP Adresse des Servers auf welchem das Backup liegen soll.
Doch was nützt die beste Backup-Methode wenn die Rücksicherung fehlt? Sehen wir uns einmal das Szenario an:
Wir beginnen mit einem Server, welcher diesmal die eben gebackuppte Maschine ist:
nc -l -p 666 | gunzip -c | dd of=/dev/hda
Dann streamen wir das Image über das Netzwerk zum neuen Server wo wir es mit dd auf die Platte zurückschreiben.
cat image.gz | nc -w 5 remote_ip 666
Auf diese Weise kann man schnell und schmerzlos Backups von Partitionen und Festplatten erstellen. Voraussetzung dafür sind jedoch idente Grössen von Quell- und Ziellaufwerk.
Tim says:
Ich bins nochmal. :)
Habe soeben einen interessanten Artikel gefunden:
https://web.archive.org/web/20130518071333/http://www.davidpashley.com:80/blog/linux/copying-files-with-netcat
In den Kommentaren schlägt jemand das Programm mbuffer vor. Ich habe es mir mal angeschaut und es scheint genau das zu sein, was ich suche. Mit –md5 kann man sich nämlich einen Hash aller transferrierten Daten erstellen lassen. Außerdem soll es auch mit variierenden Geschwindigkeiten zurecht kommen und effizienter als netcat sein (höhere I/O-Raten). Ich werde es demnächst ausprobieren, aber es scheint ein guter Ersatz für netcat zu sein.
Tim says:
Interessant. Was mich noch brennend interessiert, ist, was passiert, wenn beim Transfer über das Netzwerk Fehler auftreten. Das ist zwar unwahrscheinlich, aber kann durchaus vorkommen. Ich vermute, dass dank der Gzip-Komprimierung, beim Rücksichern der Befehl abbricht (so sollte es auch sein). Aber beim Sichern wird ja direkt auf dem Client komprimiert und an einen netcat-Server geschickt, der die Daten einfach so annimmt und auf Festplatte speichert. Gut, man könnte irgendwie versuchen von einem gzippten /dev/hda eine Checksum zu erstellen (dd if=/dev/hda of=/dev/stdout | sha1sum?!), aber was ist der beste Weg hierfür, um auf dem Client möglichst wenig Daten anfallen zu lassen? Am besten fände ich, wenn während die Daten geschickt werden, gleichzeitig von den komprimierten Daten eine Checksum erstellt wird. Die kann z.B. über einen zweiten Channel (netcat-Server) geschickt werden. Auf dem Server wird dann von jedem angekommenen Paket die Checksum erstellt und mit der Checksum, die auf dem Client generiert wurde verglichen. So hätte ich das gelöst. Die Frage ist nur, wie?
Danke schonmal. :)
Gruß
Tim
Tim says:
Okay, tatsächlich ist mbuffer schneller. Ich habe die Komprimierung komplett deaktiviert. So sieht dann der Befehl für den Server aus:
mbuffer -I 3333 –md5 -o out
Und für den Client:
mbuffer -i /dev/sda1 -O 192.168.0.22:3333 –md5
Es sichert also die lokale /dev/sda1 Partition auf dem entfernten Server in der Datei out.
Das schöne an mbuffer ist, dass es eine Fortschrittsanzeige hat. So kann man immer überblicken, wie lange es noch dauert und kann die aktuelle Geschwindigkeit einsehen.
Wenn ich jetzt z.B. es so schreiben würde, merkt man gleich, dass die Geschwindigkeit langsamer ist (in meinem Fall zwar nur 1 MB/s, dennoch nicht zu verachten):
dd if=/dev/sda1 | mbuffer -O 192.168.0.22:3333 –md5
Interessant wäre es, wenn mbuffer Komprimierung (gzip reicht eigentlich) unterstützt, sodass man gar keine Pipes benötigt. Dadurch erreicht man gute Geschwindigkeiten und kann zudem noch den Komfort eines MD5-Hashes genießen.
Und hier die Seite des Entwicklers: http://www.maier-komor.de/mbuffer.html
Gruß
Tim
Tim says:
Dein Blogsystem ist bisschen komisch. Ich habe eben eine Nachricht geschickt, die wieder nicht akzeptiert wurde. :( Kurz zusammengefasst, hier die Befehle; Auf Server: mbuffer -I 3333 –md5 -o out und auf Client: mbuffer -i /dev/sda1 -O 192.168.0.22:3333 –md5
Stargazer says:
Mein Blog-System nimmt zuerst alle Kommentare an um sie mir dann zur Moderation vorzulegen, was mir einigen Spam auf der Seite erspart. Im Prinzip dauert es eine Weile bis ich mich wieder einlogge um den Kommentar dann freizuschalten.
Was das Buffering betrifft – du planst diese Backups doch nicht quer über das Netz zu jagen?? Die Methode ist – wegen mangelnder Verschlüsselung für das LAN gedacht. Wenn es über das Netz gehen soll würde ich einen SSH Tunnel vorschlagen bzw die Ausgabedatei direkt auf einen anderen Rechner zu leiten. Dann erledigt SSH die Flusssteuerung…