Backup mit Netcat

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.

Author:

5 thoughts on “Backup mit Netcat”

  • 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.

  • 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

  • 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

  • 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

  • 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…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert