Backup/Restore mit dd

[Harald]

Hallo zusammen,

ich würde gerne eine externe USB-Platte als Backupmedium nutzen.
Nun frage ich mich gerade, ob ich was falsch mache, wenn ich wie folgt vorgehen würde.

Rechnerplatte /dev/hda besteht (z.B.) aus /dev/hda1 (swap), /dev/hda2 (/) und /dev/hda3 (/home).

Wenn ich nun mit irgendeiner Installationsversion von CD boote bzw. Knoppix und die USB-Platte z.B. nach /backup einhänge, könnte ich (das ist die Frage) sicher mit:

dd if=/dev/hda of=/backup/mein_backup.bkup

Alle drei Partitionen sichern, oder?
Wäre es umgekehrt wirklich möglich, die komplette Platte wieder so zurückzusichern, d.h. ist danach der Bootsektor und aller pipapo wieder funktionsfähig?
Wenn ja, wäre das eine schöne Backupmöglichkeit eines komplettes Rechners.

Wenn das so nicht geht, würde ich gerne wissen, ob es ein paar Schalter gibt, um sicher(er) zu sein.

Z.B. habe ich nicht herausgefunden, ob man die mit dd erzeugte Datei nach der Erzeugung nochmals überprüfen kann, ob sie wirklich fehlerfrei (bzw. gleich dem Original) ist.

Vielen Dank für jeden Tip.

Harry

[ziegenmelker]

Hallo,

Rechnerplatte /dev/hda besteht (z.B.) aus /dev/hda1 (swap), /dev/hda2 (/) und /dev/hda3 (/home).

Wenn ich nun mit irgendeiner Installationsversion von CD boote bzw. Knoppix und die USB-Platte z.B. nach /backup einhänge, könnte ich (das ist die Frage) sicher mit:

dd if=/dev/hda of=/backup/mein_backup.bkup

Alle drei Partitionen sichern, oder?

ich würde die swap-Partition nicht mitsichern, sondern /dev/hda2 und /dev/hda3 getrennt und zusätzlich den MBR und die Partitionstabelle.

Wäre es umgekehrt wirklich möglich, die komplette Platte wieder so zurückzusichern, d.h. ist danach der Bootsektor und aller pipapo wieder funktionsfähig?

Ja. Bei meiner Variante halt erst den MBR + Partitionstabelle, und dann die Partitionen

Wenn ja, wäre das eine schöne Backupmöglichkeit eines komplettes Rechners.

Das ist es, hat jedoch den Nachteil, daß die Datenmenge schon gewaltig ist. AFAIK gab es kürzlich in der c't einen Artikel, wie man das auch mit zusätzlicher Komprimierung machen kann.

Wenn das so nicht geht, würde ich gerne wissen, ob es ein paar Schalter gibt, um sicher(er) zu sein.

Sicher ist es IMHO, für zusätzliche Schalter: man dd

Z.B. habe ich nicht herausgefunden, ob man die mit dd erzeugte Datei nach der Erzeugung nochmals überprüfen kann, ob sie wirklich fehlerfrei (bzw. gleich dem Original) ist.

AKAIK kann man eine Partitionsdatei auch wieder mounten und so den Inhalt selektiv zurückholen, bzw. überprüfen, das habe ich jedoch noch nicht probiert. Ich habe bisher eine defekte 80GB (schei.. IDE!) Platte auf eine neue gedumpt - durch viele defekte Sektoren hat das über 30Std. gedauert - und dann als ich die Austauschplatte bekam wieder eine Kope auf die neue Platte gemacht, alles ohne Probleme. Ab und an will ich meine Versuche, die Partitionstabellen zu restaurieren mal wieder fortsetzen.

cu,
ziegenmelker

[Harald]

Hallo Ziegenmelker,

Rechnerplatte /dev/hda besteht (z.B.) aus /dev/hda1 (swap), /dev/hda2 (/) und /dev/hda3 (/home).

Wenn ich nun mit irgendeiner Installationsversion von CD boote bzw. Knoppix und die USB-Platte z.B. nach /backup einhänge, könnte ich (das ist die Frage) sicher mit:

dd if=/dev/hda of=/backup/mein_backup.bkup

Alle drei Partitionen sichern, oder?

ich würde die swap-Partition nicht mitsichern, sondern /dev/hda2 und /dev/hda3 getrennt und zusätzlich den MBR und die Partitionstabelle.

Die (unnötige) Swap wäre mir egal, es geht mir nur um Sicher- und Einfachheit.
Wenn ich das aber richtig sehe, ist bei /dev/hda der MBR usw. doch dabei, oder?

Wie würde Dein Vorschlag aussehen, d.h. wo liegt der MBR und diese Tabelle genau, so daß man das getrennt sichert?
Kannst Du mir mal ein Beispiel nennen?

Wäre es umgekehrt wirklich möglich, die komplette Platte wieder so zurückzusichern, d.h. ist danach der Bootsektor und aller pipapo wieder funktionsfähig?

Ja. Bei meiner Variante halt erst den MBR + Partitionstabelle, und dann die Partitionen

Wenn ja, wäre das eine schöne Backupmöglichkeit eines komplettes Rechners.

Das ist es, hat jedoch den Nachteil, daß die Datenmenge schon gewaltig ist. AFAIK gab es kürzlich in der c't einen Artikel, wie man das auch mit zusätzlicher Komprimierung machen kann.

Ja, sicher ein Pipe über gzip oder so. Ist aber zunächst nicht so wichtig.

Wenn das so nicht geht, würde ich gerne wissen, ob es ein paar Schalter gibt, um sicher(er) zu sein.

Sicher ist es IMHO, für zusätzliche Schalter: man dd

Z.B. habe ich nicht herausgefunden, ob man die mit dd erzeugte Datei nach der Erzeugung nochmals überprüfen kann, ob sie wirklich fehlerfrei (bzw. gleich dem Original) ist.

AKAIK kann man eine Partitionsdatei auch wieder mounten und so den Inhalt selektiv zurückholen, bzw. überprüfen, das habe ich jedoch noch nicht probiert. Ich habe bisher eine defekte 80GB (schei.. IDE!) Platte auf eine neue gedumpt - durch viele defekte Sektoren hat das über 30Std. gedauert - und dann als ich die Austauschplatte bekam wieder eine Kope auf die neue Platte gemacht, alles ohne Probleme. Ab und an will ich meine Versuche, die Partitionstabellen zu restaurieren mal wieder fortsetzen.

Muß ich mal probieren, vielen Dank. Vielleicht geht es so ähnlich, wie man auch eine ISO-Datei (also Kopie einer CD) einbinden kann?

Harry

[fastix®]

Moin!

Die (unnötige) Swap wäre mir egal, es geht mir nur um Sicher- und Einfachheit.
Wenn ich das aber richtig sehe, ist bei /dev/hda der MBR usw. doch dabei, oder?

Dabei schon, aber das ist eben die ganze Platte. Und genau das kann später Probleme machen.

info dd

stellt für Dich wertvolle Informationen bereit :)

Muß ich mal probieren, vielen Dank. Vielleicht geht es so ähnlich, wie man auch eine ISO-Datei (also Kopie einer CD) einbinden kann?

Ja.

Der erste Sektor der Festplatte sollte sich übrigens mit:

dd if=/dev/hda count=1 bs=512 of=bootsektor

sichern lassen.
http://www.glossar.de/glossar/1frame.htm?http%3A//www.glossar.de/glossar/z_festplatte.htm

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Harald]

Hi,

Der erste Sektor der Festplatte sollte sich übrigens mit:

dd if=/dev/hda count=1 bs=512 of=bootsektor

sichern lassen.
http://www.glossar.de/glossar/1frame.htm?http%3A//www.glossar.de/glossar/z_festplatte.htm

danke!!!
Ist darin dann auch die Tabelle enthalten oder nur der MBR?

Harry

[Vinzenz Mai]

Hallo Harald

http://www.glossar.de/glossar/1frame.htm?http%3A//www.glossar.de/glossar/z_festplatte.htm
Ist darin dann auch die Tabelle enthalten oder nur der MBR?

Du hast in der von fastix verlinkten Seite den Artikel über den MBR gelesen?
Wenn nein, hole dies bitte nach.

Freundliche Grüße

Vinzenz

[Harald]

»» Du hast in der von fastix verlinkten Seite den Artikel über den MBR gelesen?

Wenn nein, hole dies bitte nach.

ja, aber nur nicht direkt verstanden, daß die Tabelle ja den Partitionseinträgen entspricht! ;-)

Danke!

[Sven Rautenberg]

Moin!

Die (unnötige) Swap wäre mir egal, es geht mir nur um Sicher- und Einfachheit.

Und Geschwindigkeit?

dd mag ja auf den ersten Blick ganz charmant wirken, weil es so low-level arbeitet, dass man im Fall eines Falles einfach nur die gesamte Sicherung zurückspielt und dann wieder dort ist, wo man zum Zeitpunkt der Sicherung auch war.

Aber es gibt in meinen Augen handfeste Nachteile:
1. Die Sicherung prüft nicht, ob das Ausgangsmaterial korrekt ist. Schäden im Dateisystem werden nicht entdeckt, weil das Dateisystem bei der Sicherung gar nicht benutzt wird.
2. Es wird tatsächlich die gesamte Festplattengröße gesichert - auch dann, wenn sich nur ein Byte geändert hat. Sowas dauert - im Idealfall liest die Festplatte vielleicht 30 MB pro Sekunde und benötigt so 45 Minuten für das komplette Auslesen von 80 GB. Das ist nicht mal eben "kurz vor Feierabend" gestartet. Wie schnell die speichernde Platte ist, ist dabei noch nicht berücksichtigt.
3. Das Rückspielen erfordert zwingend eine Mindestfestplattengröße, wie auch gesichert wurde, ist aber nicht imstande, Veränderungen an der Partitionierung einer Ersatzplatte zu erlauben. Alle bestehenden Partitionen sind wieder exakt so groß, wie sie vorher waren - auch dann, wenn die Ersatzplatte mittlerweile doppelt so groß geworden ist und aufgrund der Betriebserfahrung eventuell eine veränderte Partitionierung wünschenswert wäre.
4. Damit das System tatsächlich ein Backup ist, ist auf dem Sicherungslaufwerk die doppelte Festplattengröße für mindestens zwei parallele Sicherungen erforderlich. Das System ist kein Backup, wenn während der Sicherung einer neuen Kopie die alte bestehende Kopie vorher gelöscht werden muß. Gerne passiert genau während dieser Operationen das Unglück.

Meine Empfehlung wäre "rdiff-backup". Das arbeitet dateiorientiert, meckert also bei Fehlern im Dateisystem, es sichert (Grundlage ist rdiff) nur die Veränderungen in den Dateien (hält die Backups klein), die Sicherung ist direkt per Dateisystem zugriffsfähig, die Sicherung kann beliebig lokal oder über das Netzwerk (z.B. mit SSH) ablaufen, und es werden automatisch Sicherungsgenerationen angelegt, man kann also auch ältere Versionen jederzeit zurückholen.

Was mit rdiff-backup natürlich nicht funktioniert, sind die Bootsektoren. Da darf dd dann gerne mal aktiv werden.

http://www.nongnu.org/rdiff-backup/

• Sven Rautenberg

[Harald]

Hallo Sven,

Die (unnötige) Swap wäre mir egal, es geht mir nur um Sicher- und Einfachheit.

Und Geschwindigkeit?

nicht so wichtig.

dd mag ja auf den ersten Blick ganz charmant wirken, weil es so low-level arbeitet, dass man im Fall eines Falles einfach nur die gesamte Sicherung zurückspielt und dann wieder dort ist, wo man zum Zeitpunkt der Sicherung auch war.

Ich dachte nicht daran, das Ganze als einzige Methode zu nutzen.
Ich würde eher so vorgehen, daß ich die komplette Platte (von mir aus auch komprimiert) ablege und immer wieder wichtige Daten (/etc, /home, ...) direkt sichere.
Ich denke, das wäre doch dann ok, oder? So könnte man ratzfatz die Platte zurücksichern und dann aktuell(er)e Daten aus der anderen Sicherung entnehmen.

http://www.nongnu.org/rdiff-backup/

Danke für den Tip. Sieht nach einer guten Sache aus.
Meine Wahl für dd war eher, daß es immer verfügbar ist.
(Ähnlich wie bei vi, der auch auf [not M$] Servern da ist!)

Harry

[ziegenmelker]

Hallo,

2. Es wird tatsächlich die gesamte Festplattengröße gesichert - auch dann, wenn sich nur ein Byte geändert hat. Sowas dauert - im Idealfall liest die Festplatte vielleicht 30 MB pro Sekunde und benötigt so 45 Minuten für das komplette Auslesen von 80 GB.

wer sagt denn, daß man mit dd nur ganze Partitionen/Platten sichern kann? Das geht auch mit einer einzelnen Datei. Außerdem versucht dd auf massivste Art und Weise auch defekte _Bytes_ noch von der Platte zu bekommen! Und das alles auch über ein Netzwerk. Für ein regelmäßiges Backup würde ich das aber trotzdem nicht verwenden, aber als Grundsicherung ist es kaum zu schlagen.

cu,
ziegenmelker

[Sven Rautenberg]

Moin!

wer sagt denn, daß man mit dd nur ganze Partitionen/Platten sichern kann? Das geht auch mit einer einzelnen Datei.

Naja, da die Unix-Philosophie "Alles ist Datei" greift, kann man mit dd eigentlich nur Dateien sichern. Aber das Problem ist, dass es außer "echten" Dateien oder Gerätedateien wie /dev/hda1 bzw. /dev/hda, die gleich gesamte Partitionen oder Festplatten gibt, kein Zwischenstück wie "nur ein Verzeichnis" oder "eine Gruppe von Verzeichnissen" gibt.

Außerdem versucht dd auf massivste Art und Weise auch defekte _Bytes_ noch von der Platte zu bekommen!

Was ist, wenn die Festplatte physikalisch perfekt ist, aber die perfekt lesbaren Bytes logisch falsch sind? Soll ja durchaus vorkommen, dass Dateisysteme inkonsistent werden, wenn mitten im Schreibvorgang irgendwas ausfällt, z.B. der Strom. Ja, Journaling-Filesysteme helfen dagegen, aber auch die sind kaum unfehlbar.

Für ein regelmäßiges Backup würde ich das aber trotzdem nicht verwenden, aber als Grundsicherung ist es kaum zu schlagen.

Ich würde dd dann anwenden, wenn es an die Datenrettung geht und das Backup unauffindbar oder unbrauchbar ist. :) Nicht vorher.

• Sven Rautenberg

[ziegenmelker]

Hallo,

Außerdem versucht dd auf massivste Art und Weise auch defekte _Bytes_ noch von der Platte zu bekommen!

Was ist, wenn die Festplatte physikalisch perfekt ist, aber die perfekt lesbaren Bytes logisch falsch sind? Soll ja durchaus vorkommen, dass Dateisysteme inkonsistent werden, wenn mitten im Schreibvorgang irgendwas ausfällt, z.B. der Strom. Ja, Journaling-Filesysteme helfen dagegen, aber auch die sind kaum unfehlbar.

es ist doch vollkommen egal, ob der Filesystem-Check vor, oder nach dem Dump gemacht wird, führt er nicht zum Erfolg ist es schliesslich egal.
Außerdem kenne ich kein Dateisystem unter Linux, welches bei mir jemals im Betrieb inkonsistent geworden wäre und bei einem Systemcrash würde doch wohl jeder das Backup wiederholen - nach einem Filesystemcheck natürlich.

Für ein regelmäßiges Backup würde ich das aber trotzdem nicht verwenden, aber als Grundsicherung ist es kaum zu schlagen.

Ich würde dd dann anwenden, wenn es an die Datenrettung geht und das Backup unauffindbar oder unbrauchbar ist. :) Nicht vorher.

Eine Grundsicherung hat nichts mit einem regelmäßigen Backup zu tun. Ich rede von CD rein, booten und mit dd die Grundkonfiguration wiederherstellen, egal wieviele Betriebssysteme und auf welcher Platte.
Ja und machen würde ich es als erstes, dann die Backups der Daten einspielen, egal womit die gemacht wurden, das/die Backup-Programm(e) ist(sind) ja dann wieder 'installiert'.
Wer das professionell vorbereiten möchte, der kann nicht belegten Platz in den Partitionen vor einem Dump mit NULLEN vollschreiben, dann ist bzip2 umso effektiver (kann man auch mit dd machen *gg*).

cu,
ziegenmelker

[fastix®]

Moin!

dd if=/dev/hda of=/backup/mein_backup.bkup

Mein Vorredner hat Recht. Es ist eine bessere Idee Partitionstabellen (und Bootsektor) sowie die Partitionen einzeln zu sichern - und den Swap auszulassen.

Das ist es, hat jedoch den Nachteil, daß die Datenmenge schon gewaltig ist. AFAIK gab es kürzlich in der c't einen Artikel, wie man das auch mit zusätzlicher Komprimierung machen kann.

Wir legen dazu einfach das eine oder andere Rohr und geben dem (de-) Kompressor tüchtig Strom:
(dd benutzt Standard-IO, wenn if oder of nicht gegeben ist und gzip gibt mit -c auf der Standardausgabe aus...

Beim Sichern:

dd if=/dev/hda1 | gzip -c > /backup/mein_backup.bkup.gz

Rücksichern:
gzip -cd /backup/mein_backup.bkup.gz | dd of=/dev/hda1

Bei einer gepackten Rücksicherung ist allerdings das Mounten ziemlich schwierig, was es nahezu unmöglich macht die Datei zu verifizieren.
Sonst könnte man als Möglichkeit in Betracht ziehen mit:

mount -o loop -t reiserfs /backup/mein_backup.bkup /mnt die Platte zu laden und (ersteres ohne mounts!) mit

ls -l /* | md5sum

sowie

ls -l /backup/* | md5sum

die entsprechenden MD5- Summen zu bilden. In vielen Fällen reicht das. Natürlich darf dabei nicht mal im /tmp - Ordner was verändert worden sein. Gegebenenfalls halt stichprobenartig einzelne Dateien gegeneinander prüfen. Für alle Dateien sehe ich da eine Menge Probleme (Dateien, die ausgeschlossen werden müssten (z.b. /etc/mtab)).

Ein Tipp noch :)

Die externen USB-Platten verlassen den Laden mit FAT- Dateisystem. Das kann maximal 2 GBytes pro Datei. Also umformatieren zu ext3...

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Harald]

Hi,

dd if=/dev/hda of=/backup/mein_backup.bkup

Mein Vorredner hat Recht. Es ist eine bessere Idee Partitionstabellen (und Bootsektor) sowie die Partitionen einzeln zu sichern - und den Swap auszulassen.

wo der MBR und Tabelle liegt, habe ich leider noch nicht rausgefunden.
Ist das abhängig von der Größe der Platte?

Das ist es, hat jedoch den Nachteil, daß die Datenmenge schon gewaltig ist. AFAIK gab es kürzlich in der c't einen Artikel, wie man das auch mit zusätzlicher Komprimierung machen kann.

Wir legen dazu einfach das eine oder andere Rohr und geben dem (de-) Kompressor tüchtig Strom:
(dd benutzt Standard-IO, wenn if oder of nicht gegeben ist und gzip gibt mit -c auf der Standardausgabe aus...

Beim Sichern:

dd if=/dev/hda1 | gzip -c > /backup/mein_backup.bkup.gz

Rücksichern:
gzip -cd /backup/mein_backup.bkup.gz | dd of=/dev/hda1

Die Größe ist mir wirklich egal. Die Laptop-Platte hat nur 20Gig.
Die externe 200! ;-)

Das Laptop hat aber nur 800Mhz, d.h. gzip bremst dabei "etwas".
Hinzu kommt, daß das Teil nur USB 1.1 hat, wo man jetzt überlegen mag, was wirklich bremst. Ich wollte mir aber auch noch eine PC-Card mit USB2 zulegen, dann wäre _nicht komprimieren_ eher von Vorteil, gell?

Bei einer gepackten Rücksicherung ist allerdings das Mounten ziemlich schwierig, was es nahezu unmöglich macht die Datei zu verifizieren.
Sonst könnte man als Möglichkeit in Betracht ziehen mit:

mount -o loop -t reiserfs /backup/mein_backup.bkup /mnt die Platte zu laden und (ersteres ohne mounts!) mit

ls -l /* | md5sum

sowie

ls -l /backup/* | md5sum

Das habe ich auch schon hinbekommen! ;-)

die entsprechenden MD5- Summen zu bilden. In vielen Fällen reicht das. Natürlich darf dabei nicht mal im /tmp - Ordner was verändert worden sein. Gegebenenfalls halt stichprobenartig einzelne Dateien gegeneinander prüfen. Für alle Dateien sehe ich da eine Menge Probleme (Dateien, die ausgeschlossen werden müssten (z.b. /etc/mtab)).

Ein Tipp noch :)

Die externen USB-Platten verlassen den Laden mit FAT- Dateisystem. Das kann maximal 2 GBytes pro Datei. Also umformatieren zu ext3...

Da ich als Basissystem kein Windows benutze, habe ich das direkt nach dem Auspacken _ordentlich_ formatiert! ;-))

Danke jedenfalls!

Harry

[Sven Rautenberg]

Moin!

Die Größe ist mir wirklich egal. Die Laptop-Platte hat nur 20Gig.
Die externe 200! ;-)

Naja, mit USB 1.1 dauert die Sicherung ja auch nur 4 Stunden, wahrscheinlich länger (11 MBit/s angenommen).

Ich kann mir nicht vorstellen, dass du das so häufig anwirfst, wie es sich für ein Backup gehören würde.

• Sven Rautenberg

[Harald]

Hallo Sven,

Die Größe ist mir wirklich egal. Die Laptop-Platte hat nur 20Gig.
Die externe 200! ;-)

Naja, mit USB 1.1 dauert die Sicherung ja auch nur 4 Stunden, wahrscheinlich länger (11 MBit/s angenommen).

Ich kann mir nicht vorstellen, dass du das so häufig anwirfst, wie es sich für ein Backup gehören würde.

• Sven Rautenberg

ich komme auf 5,5h! ;-)
ca. 200.000/3600s =~ 5.5h

Wenn das zuverlässig läuft, wäre es rel. egal. Kann ja über Nacht geschehen. Aber (gerade bei einem Laptop, das ja doch mal unsanfter landen könnte) ist das sicher was wert.
USB2 anzuschaffen, werde ich mir aber auch nochmal überlegen.
Wenn man sich z.B. das ansieht, ist das ja schon ein Unterschied bzgl. der Geschwindigkeit. Ich frage mich nur, ob das dann auch mit Knoppix oder Suse-Rescue erkannt wird...

Harry

[Harald]

ich komme auf 5,5h! ;-)
ca. 200.000/3600s =~ 5.5h

20.000/3600s natürlich...

[ziegenmelker]

Hallo,

wo der MBR und Tabelle liegt, habe ich leider noch nicht rausgefunden.
Ist das abhängig von der Größe der Platte?

hier einige Infos rund um Master-Bootsektor und Partitionstabellen.
http://w-hermanns.de/inhalt/wartung/mbr.html

Also wenn du nur die ersten 512 Bytes sicherst, dann ist das voll ausreichend, denn ein eventuell vorhandene erweiterte Partition ist hier eingetragen. Wenn du die dann sichern würdest, dann erhältst du automatisch auch alle darin liegenden logischen Laufwerke wieder zurück. Du darfst allerdings _NICHT_NUR_ die logischen Laufwerke sichern, die könntest du ohne manuelles Partitionieren der Zielplatte sonst nicht wieder genau so zurückspielen. Naja, es wäre auch nicht wirklich ein Problem, die Daten wären in jedem Fall vorhanden.

Wen das Thema interessiert, ich habe (leider) noch weitere interessante Links zu dem Thema.

cu,
ziegenmelker

[Harald]

Hallo Ziegenmelker,

wo der MBR und Tabelle liegt, habe ich leider noch nicht rausgefunden.
Ist das abhängig von der Größe der Platte?

hier einige Infos rund um Master-Bootsektor und Partitionstabellen.
http://w-hermanns.de/inhalt/wartung/mbr.html

super!

Also wenn du nur die ersten 512 Bytes sicherst, dann ist das voll ausreichend, denn ein eventuell vorhandene erweiterte Partition ist hier eingetragen. Wenn du die dann sichern würdest, dann erhältst du automatisch auch alle darin liegenden logischen Laufwerke wieder zurück. Du darfst allerdings _NICHT_NUR_ die logischen Laufwerke sichern, die könntest du ohne manuelles Partitionieren der Zielplatte sonst nicht wieder genau so zurückspielen. Naja, es wäre auch nicht wirklich ein Problem, die Daten wären in jedem Fall vorhanden.

danke!

Wen das Thema interessiert, ich habe (leider) noch weitere interessante Links zu dem Thema.

Mittlerweile interessiert mich das immer mehr!
Aber fürs erste reichen die ganzen Informationen.

Vielen Dank an Dich, Fastix und Sven!!!

Harry

[ziegenmelker]

Hallo,

Das Laptop hat aber nur 800Mhz, d.h. gzip bremst dabei "etwas".
Hinzu kommt, daß das Teil nur USB 1.1 hat, wo man jetzt überlegen mag, was wirklich bremst. [...]

Das kannst du ja testen, indem du einen kleinen Teil (z.B. 50MB = 100.000 Sektoren) einer Partition mal unkomprimiert mal komprimiert in eine Datei auf deinem USB-Laufwerk schreibst.

cu,
ziegenmelker

[Harald]

Hallo,

Das Laptop hat aber nur 800Mhz, d.h. gzip bremst dabei "etwas".
Hinzu kommt, daß das Teil nur USB 1.1 hat, wo man jetzt überlegen mag, was wirklich bremst. [...]

Das kannst du ja testen, indem du einen kleinen Teil (z.B. 50MB = 100.000 Sektoren) einer Partition mal unkomprimiert mal komprimiert in eine Datei auf deinem USB-Laufwerk schreibst.

Dabei habe ich was witziges festgestellt.
dd ist schon fertig aber die USB-Platte rödelt noch 3 Minuten rum.
Speichert die das zwischen? Mehr als 8MB Cache dürfte die doch nicht haben, oder? Oder liegt das an Linux?

[ziegenmelker]

Hallo,

dd ist schon fertig aber die USB-Platte rödelt noch 3 Minuten rum.
Speichert die das zwischen? Mehr als 8MB Cache dürfte die doch nicht haben, oder? Oder liegt das an Linux?

ich habe keine Erfahrung mit USB-Festplatten. Ich konnte auch noch nicht bemerken, ob dd beim Schreiben einen Cachè benutzt, die verwendeten Platten waren halt immer etwa gleich schnell.
dd liest notfalls auch kleinstmögliche Einheiten (Sektoren?) aus, möglicherweise wird aber beim Schreiben der Cachè benutzt.

cu,
ziegenmelker

[Vinzenz Mai]

Hallo Harald

dd ist schon fertig aber die USB-Platte rödelt noch 3 Minuten rum.
Speichert die das zwischen? Mehr als 8MB Cache dürfte die doch nicht haben, oder? Oder liegt das an Linux?

Sehr wahrscheinlich letzteres. Schließlich nutzt Linux im Normalfall möglichst viel freien Hauptspeicher als Festplattenpuffer. Wieviel RAM hast Du, wieviel ist davon als Festplattenpuffer genutzt, rechne es Dir aus, ob es mit der USB 1.1-Datenübertragungsrate hinkommt.

Freundliche Grüße

Vinzenz

[Harald]

Hi,

dd if=/dev/hda of=/backup/mein_backup.bkup

Mein Vorredner hat Recht. Es ist eine bessere Idee Partitionstabellen (und Bootsektor) sowie die Partitionen einzeln zu sichern - und den Swap auszulassen.

sorry, aber dazu hätte ich noch eine Frage:

Wenn ich hda1, hda2, hdaN gesichert habe, wie sichere ich die dann zurück, wenn ich nicht mehr weiß, wie meine Partitionen (Größe) ausgesehen hatten?
Darin sehe ich eher einen Nachteil, oder?

Wenn bspw. die hda1 2Gig hatte, muß ich doch vor dem Restore sicher wieder eine Partition erstellen, die diese Größe hat und dann das Abbild dorthin schaufeln, oder?

Bei meiner ersten Idee, die ganze Platte zu sichern, brauche ich mir dabei aber keinen Kopf zu machen.

Und nochmal zur Swap-Partition:
Wenn man, wie Du vorgeschlagen hattest, das über gzip/bzip2 komprimiert, sollte das sicher extrem klein werden. Da sind doch sicher nur null-Bytes o.ä. drin?

Harry

[ziegenmelker]

Hallo,

Wenn ich hda1, hda2, hdaN gesichert habe, wie sichere ich die dann zurück, wenn ich nicht mehr weiß, wie meine Partitionen (Größe) ausgesehen hatten?
Darin sehe ich eher einen Nachteil, oder?

das steht in der Partitionstabelle im MBR (für z.B. /hda1 bis hda4, jedoch nicht für hda4 etc.)

Und nochmal zur Swap-Partition:
Wenn man, wie Du vorgeschlagen hattest, das über gzip/bzip2 komprimiert, sollte das sicher extrem klein werden. Da sind doch sicher nur null-Bytes o.ä. drin?

nein, der (Teil-)Inhalt wird ja nie geNULLt, sondern nur freigegeben.

cu,
ziegenmelker

[Harald]

das steht in der Partitionstabelle im MBR (für z.B. /hda1 bis hda4, jedoch nicht für hda4 etc.)

ok, aber das in der Klammer ist irgendwie widersprüchlich, oder? ;-)

[ziegenmelker]

Hallo,

das steht in der Partitionstabelle im MBR (für z.B. /hda1 bis hda4, jedoch nicht für hda4 etc.)
ok, aber das in der Klammer ist irgendwie widersprüchlich, oder? ;-)

gut aufgepasst. ;-)
Weißt du jetzt schon, was da richtigerweise stehen sollte?

cu,
ziegenmelker

[Harald]

Hallo,

das steht in der Partitionstabelle im MBR (für z.B. /hda1 bis hda4, jedoch nicht für hda4 etc.)
ok, aber das in der Klammer ist irgendwie widersprüchlich, oder? ;-)

gut aufgepasst. ;-)
Weißt du jetzt schon, was da richtigerweise stehen sollte?

hdb1...hdb4 ?

[ziegenmelker]

Hallo,

Hallo,

das steht in der Partitionstabelle im MBR (für z.B. /hda1 bis hda4, jedoch nicht für hda4 etc.)
ok, aber das in der Klammer ist irgendwie widersprüchlich, oder? ;-)

gut aufgepasst. ;-)
Weißt du jetzt schon, was da richtigerweise stehen sollte?

hdb1...hdb4 ?

nein, sondern
...das steht in der Partitionstabelle im MBR (für z.B. /hda1 bis hda4, jedoch nicht für hda5 etc.)

hda1 bis hda4 sind primäre Partitionen, logische Laufwerke fangen bei hda5 an.
Beispiel:
hda1: Primäre Partition
hda2: Erweiterte Partition
hda5: logisches Laufwerk in hda2, der erweiterten Partition
hda6: logisches Laufwerk in hda2, der erweiterten Partition.

Die logischen Laufwerke sind _in_ der erweiterten Partition als verkettete Liste angelegt, daher ist es unter Umständen wichtig, die ganze Partition hda2 zu sichern, die logischen Laufwerke sind dann mit dabei.

cu,
ziegenmelker

[Vinzenz Mai]

Hallo ziegenmelker

hda1 bis hda4 sind primäre Partitionen, logische Laufwerke fangen bei hda5 an.
Beispiel:
hda1: Primäre Partition
hda2: Erweiterte Partition

hda3: Primäre Partition (swap)

hda5: logisches Laufwerk in hda2, der erweiterten Partition
hda6: logisches Laufwerk in hda2, der erweiterten Partition.

Die logischen Laufwerke sind _in_ der erweiterten Partition als verkettete Liste angelegt, daher ist es unter Umständen wichtig, die ganze Partition hda2 zu sichern, die logischen Laufwerke sind dann mit dabei.

Deswegen ist es durchaus eine gute Idee, für die Auslagerung eine primäre Partition zu verwenden, die _hinter_ den genutzen Primärpartitionen liegt.

Freundliche Grüße

Vinzenz

[ziegenmelker]

Hallo Vinzenz,

hda1 bis hda4 sind primäre Partitionen, logische Laufwerke fangen bei hda5 an.
Beispiel:

------^^^^^^^^^

hda1: Primäre Partition
hda2: Erweiterte Partition

hda3: Primäre Partition (swap)

hda5: logisches Laufwerk in hda2, der erweiterten Partition
hda6: logisches Laufwerk in hda2, der erweiterten Partition.

Die logischen Laufwerke sind _in_ der erweiterten Partition als verkettete Liste angelegt, daher ist es unter Umständen wichtig, die ganze Partition hda2 zu sichern, die logischen Laufwerke sind dann mit dabei.

Deswegen ist es durchaus eine gute Idee, für die Auslagerung eine primäre Partition zu verwenden, die _hinter_ den genutzen Primärpartitionen liegt.

Das ist alles eine Frage wieviele Installationen man auf seinen Platten hat, hier 5 · SCSI und 2 · IDE , mit bis zu 8 Partitionen/logischen Laufwerken pro Platte (und einem Höllenlärm). ;-)
Ansonsten ist es richtig, besser eine primäre Partition für swap zu nehmen, wo die jedoch liegt, ob als hda1 oder hda3, ist egal.

cu,
ziegenmelker

[Vinzenz Mai]

Hallo ziegenmelker

Das ist alles eine Frage wieviele Installationen man auf seinen Platten hat, hier 5 · SCSI und 2 · IDE , mit bis zu 8 Partitionen/logischen Laufwerken pro Platte (und einem Höllenlärm). ;-)

Hab' ich zu Hause nicht, aber bei einem Arbeitgeber schon gehabt. Den Lärm kann ich bestätigen, machen sogar die 3xSCSI beim jetztigen Arbeitgeber.

Ansonsten ist es richtig, besser eine primäre Partition für swap zu nehmen, wo die jedoch liegt, ob als hda1 oder hda3, ist egal.

Wenn es um Performance geht, ist eine eigene Platte für das Auslagern (eigentlich wäre ja Paging korrekter als Swapping) optimal. Und überflüssig, diesen Bereich redundant auszulegen (aber irgendeinen Ersatz im Schrank liegen haben) :-)

Freundliche Grüße

Vinzenz

[fastix®]

Moin!

Wenn ich hda1, hda2, hdaN gesichert habe, wie sichere ich die dann zurück, wenn ich nicht mehr weiß, wie meine Partitionen (Größe) ausgesehen hatten?

Deine Sicherungen sind Byte für Byte genau so groß wie es die künftigen Partitionen sein werden.
Ein ls -l reicht also um zu wissen, wie groß die Partitionen sein müssen. Außerdem sicherst Du ja die Tabelle :)

Darin sehe ich eher einen Nachteil, oder?

Die künftigen Partitionen können aber bei den meisten Partitionstypen beliebig größer sein (meines Wissens selbst bei FAT). Da Du gegebenenfalls eine neue, also oft auch größere Platte einbaust, könntest Du die Größe der Partitionen neu entscheiden wollen. Genau das geht, wenn Du Partition für Partition sicherst. Ich sehe also in der Einzelsicherung einen Vorteil.

Darüber hinaus: Diese Art der Sicherung macht bei Partionen Sinn, die Programme enthalten, also relativ statisch sind. Grund: Du hast sehr schnell wieder ein lauffähiges System. (Und brauchst zum Herstellen nur die Datensicherung und eine beliebige LINUX-Recovery oder Boot-CD: knoppix, kanotix, SuSE-Test-CD, Red-Hat-Recovery-CD....) Es macht auch Sinn zum Zwecke des clonens von Installationen. Aber wie andere auch schon geschrieben haben: Für die Datensicherung ist das keine allzugute Idee, weil der Aufwand zu hoch ist. Hier bieten sich ernsthaft diverse Sicherungsprogramme und sogar selbstgeschriebene Skripte auf Grundlage von tar, gzip, e.t.c. an.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®