dd welche bs ???

[Mathew]

Hallo,

ich nutze bei größeren Umstellungen und Eingriffen:

dd if=/dev/hda bs=32 | gzip -c | ncftpput -c -V -u user -p pass ftpserver ddhda.gz

um meinen server im rescuesystem auf den ftpserver zu sichern.

Ist ein bs=32 ok oder sollte ich 64k nehmen ??? Oder spielt das alles keine Rolle hauptsache ich nehme immer die gleichen Werte beim zurückspielen ???

[Sidolin]

Man sollte wirklich nicht gerade dd für sicherungen nehmen, stell dir vor, du brauchst mal nur eine einzige datei aus der sicherung...

Nimm besser tar mit den passenden Optionen.

[Mathew]

jedes mal das gleiche !!! Ich habe eine Frage über bs gestellt und nicht welche Datensicherung ich verwenden soll.

Der Server wird jeden Tag mit tbackup von 4psa gesichert und zusätzlich noch mit tar auf einen anderen Backupserver. Mir geht es aber um den Parameter bs.

[Jasper]

jedes mal das gleiche !!! Ich habe eine Frage über bs gestellt und nicht welche Datensicherung ich verwenden soll.


ja, das nervt gewaltig.



Der Server wird jeden Tag mit tbackup von 4psa gesichert und zusätzlich noch mit tar auf einen anderen Backupserver. Mir geht es aber um den Parameter bs.

ich verwende grössere bs von 128k-10m, wobei festplattengrösse mod bs = 0 sein sollte. am sichersten ist 512b, dass passt für alle platten weil alle pc-festplatten 512b sektorgrösse haben, aber das ist elende langsam. einfach mal austesten, bei welcher bs die performance am besten ist.


-j

[Mathew]

hmm, danke für Deine Antwort. Habe nur festgestellt, dass DD ja alles kopiert, somit auch die gelöschten Dateien. Wenn ich ne Partition mit 500MB habe und dort sind Daten mit 100MB drauf, erstellt er mit eine Dumpdatei mit 300MB. Somit müsste ich vorher irgendwie die gelöschten Dateien auf 0 bringen, damit er diese besser komprimieren kann. Was mit dann aber vom Eingriff ins Dateisystem zu Riskant wäre. 500MB sind ja Peanuts, aber bei einem DD von 40 oder 80GB dann schon Hammer, so lange ist die Nacht nicht.

Jetzt würde ich im Rescuesystem booten, mit:
dd bs=512 count=1 if=/dev/hda of=/backup/bootblock
den Bootsector sichern. Anschliessend alle Partitionen auf /mnt mounten und dann ein tar –czvl /mnt --exclude /mnt/backup–f /mnt/backup/system.tar.gz

Damit sollte ich dann alles gesichert haben.

Dann kann ich mit:
dd bs=512 count=1 if=/backup/bootblock of=/dev/hda den Bootblock zurückspielen. Mounte alle Partitionen in /mnt, lösche komplett /mnt (bis auf /mnt/backup/) und mache ein tar -xzvl /mnt/backup/system.tar.gz /mnt

Damit sollte dann alles wieder nach einem Neustart im System vorhanden sein oder ???

Keine Probleme mit /dev oder Berechtigung ??? Werde das eh noch auf einem Testsystem prüfen, wollte aber nur Wissen, ob die Idee schon so richig ist, dass es funktioniert. Dankääääääää

[HirschHeisseIch]

/dev sollte kein Problem darstellen, da es eh ein Pseudo-Dateisystem ist (je nach Distri)bzw. die Rechte mit gesichert werden.

[Jasper]

hmm, danke für Deine Antwort. Habe nur festgestellt, dass DD ja alles kopiert, somit auch die gelöschten Dateien. Wenn ich ne Partition mit 500MB habe und dort sind Daten mit 100MB drauf, erstellt er mit eine Dumpdatei mit 300MB. Somit müsste ich vorher irgendwie die gelöschten Dateien auf 0 bringen, damit er diese besser komprimieren kann. Was mit dann aber vom Eingriff ins Dateisystem zu Riskant wäre. 500MB sind ja Peanuts, aber bei einem DD von 40 oder 80GB dann schon Hammer, so lange ist die Nacht nicht.


klar, dd erstellt eine 1:1 kopie. für ext2/ext3 ist dump/restore (mittelding zwischen dd und tar) recht gut.



Dann kann ich mit:
dd bs=512 count=1 if=/backup/bootblock of=/dev/hda den Bootblock zurückspielen. Mounte alle Partitionen in /mnt, lösche komplett /mnt (bis auf /mnt/backup/) und mache ein tar -xzvl /mnt/backup/system.tar.gz /mnt

Damit sollte dann alles wieder nach einem Neustart im System vorhanden sein oder ???


das kann schief gehen. verwende zum entpacken auf jeden fall --numeric-owner und --preserve. damit habe ich schon unzählige systeme geclont. und den bootloader neu zu initialisieren nicht vergessen.


-j

[fsd]

hmm, danke für Deine Antwort. Habe nur festgestellt, dass DD ja alles kopiert, somit auch die gelöschten Dateien. Wenn ich ne Partition mit 500MB habe und dort sind Daten mit 100MB drauf, erstellt er mit eine Dumpdatei mit 300MB. Somit müsste ich vorher irgendwie die gelöschten Dateien auf 0 bringen, damit er diese besser komprimieren kann. Was mit dann aber vom Eingriff ins Dateisystem zu Riskant wäre. 500MB sind ja Peanuts, aber bei einem DD von 40 oder 80GB dann schon Hammer, so lange ist die Nacht nicht.


aber erst meckern, wenn einer tar vorschlägt...
Ich schlage übrigens rsync vor.

[Mathew]

da stand ja auch nicht tar zur Diskussion. In meinem nächsten Beitrag steht ja auch, dass ich tar nutze.

Aber Dir düfte das Problem doch auch bekannt sein, dass der Thread auseinandergeht, jeder seinen Vorschlag gibt und das eigentliche Ziel nicht erreicht wird, sondern jeder seine Meinung abgibt.

1. Ich hab nen Golf und der stottert, was könnte das sein ???
2. Klar, Golf, hol Dir nen BMW, der stottert nicht.
3. BMW, nimm lieber Audi.

;-)))))))

[fsd]

da stand ja auch nicht tar zur Diskussion. In meinem nächsten Beitrag steht ja auch, dass ich tar nutze.

Aber Dir düfte das Problem doch auch bekannt sein, dass der Thread auseinandergeht, jeder seinen Vorschlag gibt und das eigentliche Ziel nicht erreicht wird, sondern jeder seine Meinung abgibt.

1. Ich hab nen Golf und der stottert, was könnte das sein ???
2. Klar, Golf, hol Dir nen BMW, der stottert nicht.
3. BMW, nimm lieber Audi.

;-)))))))

Du hast aber trotzdem meinen Vorschlag mit rsync nicht überlesen?

[Mathew]

rsync ist sicher gut, aber ich habe ne andere Idee ;-)
Ich brauche ja den ganzen Kram nicht übers Netz sichern. Das macht der ja jeden Tag von selber. Mit geht es ja darum, vor einem Update einfach die Software zu sichern um bei einem Fehler, alles ohne viel Aufwand zurückzuspielen.

Daher mache ich einfach ein cp -a

Kopiere also im rescue komplett / in ein backupordner. Ohne Komprimierung oder Sonstiges. Sollte beim Update (Software) was schiefgehen, kopiere ich im rescue einfach die Sachen wieder zurück nach /.

Dafür sollte doch ein "cp -a" völlig ausreichen oda ???

Kein mysql oder sonstwasproblem ;-)

[Pixelbrei]

Ein Problem könnte folgendes sein:
Du hast ein cp-backup. Du installierst irgendeine Software oder erstellst andere Daten. Dein System geht kaputt, du kopierst zurück. Dann liegen die alten Dateien, die vorm backup noch nicht existierten, einfach so im system rum. z.b. ein neu installieres programm. oder config-dateien. auf diese weise kann das Dateisystem ziemlich zugemüllt werden.
Einen mysql-server würde ich vorm kopieren beenden, dann dürfte es da auch keine Probleme geben.

Und bei mir steht in der *shrc

alias cp="rsync"
*fg*

[Mathew]

danke für Deine Info.

- Der Ordner wird natürlich vorher gelöscht, bevor ich zurückspiele.
- im rescue läuft eh kein mysql