[HOWTO] festplatten-backup mit bormitteln

Backup howto Teil 1

Ich habe mich nun schon 2 wochen mit dem Thema beschäftigt, wie man unter linux jede art von partitionen (oder ganzen festplatten) kopiert, bzw wie man ein image davon erstellt. Dies ist die Ausbäute:

erste entscheidung:
Kompression, ja oder nein? Diese Frage ist einfach beantwortet: Wenn genug plattenplatz vorhanden ist, ist die kompression überflüssig, ansonsten durchaus sinnvoll. Wenn man sich jedoch für die kompression entscheidet, wird eine schnelle cpu benötigt, da alles bzip2 viel rechenleistung benötigt.

2. entscheidung:
Wohin mit dem backupfile? Am besten ist es, eine backup-platte zu haben, auf dem die images gelagert werden. Alternativ kann auch ein netzwerkvolume via nfs gemountet werden. Eine eher theoretische möglichkeit ist das aufbewaren der dateien auf cd. bei heutigen platte mit 200gb speicher ist diese möglichkeit jedoch nicht rentabel. Falls man sich für ein dvd-backup entscheidet, benötigt man sehr viel temporären platz, da zuerst die platte ausgelesen wird, und anschließend die ausgelesene imagedatei auf dvd gebannt wird.

3. 2gb-grenze:
Fat ist ein 32bit dateisystem, dh, dass die maximale dateigröße 2gb beträgt. Wenn das zielvolume so eine parition ist, muss gesplittet werden. Das splitten ist auch wegen der besseren handhabung der "kleinen" dateien sinnvoll.

4. auswählen des quellmediums:
Es können sowol einzelne partitionen wie auch ganze platten gesichert werden. Das dateisystem ist dabei nicht von bedäutung. dh, es können fat, nfs, extN, reiserFS, XFS usw volumes gesichert werden. Bei einer ganzen platte wird zb /dev/hda als quelle angegeben. hda heißt, dass die erste platte am ersten ide kanal verwendet werden soll. hdb ist die zweite platte am ersten ide kanal, hdc die erste platte am 2. kanal, und hdd das zweite gerät am 2. kanal. SCSI geräte werden mit /dev/sda, /dev/sdb usw angesprochen. USB-platten werden als SCSI emuliert, somit besitzen diese auch device-files wie /dev/sda.
Partitionen werden mit /dev/hda1, /dev/hda2 usw angegeben. Also zuerst die platte, dann die partitionsnummer. eine liste der gemounteten partitonen erhällt man mit dem befehl "df" oder unter kde "kdf".

5. befehle zum sichern:
In einer konsole muss folgender befehl ausgeführt werden:
dd if=/dev/hda | bzip2 -c | split -b 700m - | /mnt/sicherung.
Hierbei muss hda durch die entsprechende platte, und /mnt/sicherung durch den zielpfad ersetzt werden. eventuell können "| bzip2 -c" und "| split -b 700m -" weggelassen werden. (die namen sprechen für sich)

6. Restaurieren einer platte:
Es muss ein ersatzsystem wie zb knoppix gestartet, und das volume mit der sicherung gemountet werden. folgende zeile schreibt die partition auf die platte zurück:
cat /mnt/sicherung* | bzcat | dd of=/dev/hda
Die entsprechenden glieder müstten natürlich wieder geändert werden. "split" legt dateien mit sicherung.aa oder sicherung.bb an, deswegen muss ein * nach /mnt/sicherung gesetzt werden.

7. /dev/zero-trick:
Wenn eine platte/partition großteils leer ist, sollte unbedingt ein "dd if=/dev/zero of=/mnt/platte/null.txt" ausgefüht werden. dabei wird der freie platz mit nullern überschrieben. anschließend muss diese datei wieder gelöscht werden. Bei der anschließenden sicherung kann nun eine hohe kompression erzielt werden, da sich "0" hervorragend kompromieren lässt.


Falls ihr noch fragen habt, stellt sie

gruß, buhi

 

Hi,

es war für mich als absoluter Linux-NewBie interessant diese Diskussion zu verfolgen.

Mein Linux-Backup habe ich mit DOS-Mitteln erstellt.

Mit zwei solchen Backup-Programmen habe ich es versucht - der Sieger war 'Ghost'.
'HD-Copy' setzte dabei 2 Stunden an, was mit einem Verify dann eben doppelt soviel Zeit in Anspruch nimmt - 'Ghost' erledigte die Aufgabe dagegen in 20 (40) Minuten (mittlere Komprimierungs-Angabe 'schnell') und gesplittet auf einem normalen 1Ghz-Rechner.

Ein Restore nach gelöschter Linux-Partition war erfolgreich.

Claro, keine Lösung mit Bordmitteln - aber auch begehbar.

MfG Doofchen

 

@ cirad

Danke für deine ergänzungen

bitumen

 

# Natürlich könnte man auch scp verwenden, dies
# hätte jedoch den Nachteil, dass keine
# Unterverzeichnisse mitkopiert werden
scp -r

# root@linux$ tar zcvf - /home | ssh IP "cat >
# homes_backup.tgz"
Vielleicht sollte man auch noch erwähnen, daß IP auch ein normaler Name inklusive Verzeichnis sein kann, beispielsweise mein.rechner.de:/backup, denn in der Regel hat man ein Backup eher nicht unter /root rumfliegen, das wiederum auf Root rumfliegt.

 

Teil2: backup über ssh

Backups lassen sich Einfach über NFS oder SMB auf remote-datenträgern speichern. Bei solchen Methoden (zb NFS) kommt ein Netzwerktraffic von +50% zustande, da NFS ein RPC-dienst ist. Außerdem sind NFS und SMB unverschlüsselt und belasten den rechner erheblich. (obwohl das bei heutigen pc-s nicht viel ausmacht)
Eine optimale Lösung für ein Backup über das Netzwerk bietet ssh. DIe Entwickler von SSH haben peinlich genau darauf geachtet, dass sich ssh so wie die anderen unix Befehle verhält. Folglich können auch pipes verwendet werden, worauf dieser Nachtrag basiert.
Natürlich könnte man auch scp verwenden, dies hätte jedoch den Nachteil, dass keine Unterverzeichnisse mitkopiert werden. Außerdem gehen Benutzer und Rechte flöten. Daher gehen wir folgendermaßen vor:

root@linux$ tar zcvf - /home | ssh IP "cat > homes_backup.tgz"

In diesem Beispiel wird das /home Verzeichnis nach homes_backup.tgz komprimiert im targz format abgelegt. IP steht für die ip-adresse der remote-maschine. Die zwischen den " (Anführungszeichen) enthaltenen Befehle werden über die ssh verbindung ausgeführt. Folglich könnte ein anderer befehl so lauten:

root@linux$ tar zcvf - /home | ssh IP "cd /backup; rm ./homes_backup.tgz;cat > homes_backup.tgz"

Dabei wird das alte backup im /backup Verzeichnis gelöscht, bevor das neue geschrieben wird.

Für die Wiederherstellung der Dateien gibt es 2 möglichkeiten über ssh:

root@linux$ ssh IP "cd /home; tar zpvxf -" < homes.tgz
oder
root@linux$ ssh IP "cat homes.tgz" | tar zpvxf -

Welches der zwei Befehlszeilen sinnvoller ist, hängt davon ab, an welchem rechner man gerade eingeloggt ist.


Ein weiterer Lösungsansatz fürs backup übers Netzwerk wäre rsync. Vielleicht kommt ja irgendwann Teil No.3
Viel spaß bei experimentieren,

bitumen (alias blakcomb)

 

Danke für die Anleitung, sehr verständlich!

Mein Urteil: sehr gut!