Archiv verlassen und diese Seite im Standarddesign anzeigen : Festplatte mit dd sichern und zurückspielen
ich möchte mit einem antiX Live-System auf einem USB-Stick eine Festplatte auf einer 2.Partition auf demselben Stick mit dd sichern. Ich werde dann also den Befehl
dd if=/dev/sdb of=/dev/sda2/sicherung.img
verwenden. Danach möchte ich die antiX-Version auf der zuvor gesicherten Festplatte installieren; d.h. alles wird gelöscht und neu beschrieben.
Falls da etwas nicht klappt, schreibe ich die Sicherung mit
dd if=/dev/sda2/sicherung.img of=/dev/sdb
wieder zurück.
Die Fragen jetzt :
1. funktioniert das auch so oder brauch ich da Optionen für dd ?
2. bekomme ich da sicher keine Problem mit dem Alignment wie beim Klonen auf eine SSD-Platte (siehe Warnung bei ubuntuusers.de) ?
3. ich habe in der menu.list und fstab die Partitionen der zu sichernden Festplatte mit UUIDs eingebunden -- muß ich das ändern, auch wenn das Zurückspielen auf dieselbe Festplatte erfolgt ?
4. gibt's da sonst noch was zu beachten ?
1.) klappt, eventuell bs=1M um bessere Performance zu bekommen
2.) mir nicht bekannt
3.) kA, würde mich auch interessieren
4.) mir nicht bekannt und hatte damit auch noch nie Probleme beim Sichern und Zurückspielen
zu 2) ich weiss es nicht, aber es wird hier (http://www.thomas-krenn.com/de/wiki/Partition_Alignment#Alignment_.C3.BCberpr.C3.BCfen ) beschrieben, wie man es prüfen kann
zu 3) siehe hier:
...buntu wiki (http://wiki.ubuntuusers.de/fstab#Klonen-von-Festplatten):
Vor dem Klonen von Festplatten sollte man die fstab wieder komplett auf die "echten" Geräteknoten (/dev/sd*) umstellen, statt UUIDs zu verwenden.
zu 3.) würde ich sagen, dass eine mit dd gesicherte Partition beim zurückspielen des img wieder die alte UUID hat. Somit müsste die zur menu.lst passen.
http://linuxwiki.de/UUID
Eine mit dd oder ähnlichem kopierte Partition besitzt die gleiche UUID wie die Quellpartition.
zu 4.) Hier sehe ich Probleme mit grub. Wenn grub zwischendurch neu in den MBR installiert wurde, wird er evtl. die menu.lst nicht mehr finden.
Danke schon einmal für den bisherigen Input.
Laut http://media-addicted.de/alignment-von-partitionen-auf-ssds-ohne-datenverlust-und-neuinstallation-aendern/769/ wird GParted die /dev/sda2 ja von Haus aus nach den MiB ausrichten. Reicht das dann ? Je mehr man dazu liest, desto unsicherer wird man....
bei den UUIDs gibt's ja mehrere Meinungen :D ;
Die Frage ist da eher, ob das BIOS da was neues zuweist...
ich denke, sicherheitshalber ändere ich die menu.list und fstab auf die /dev/sd.. Methode
@hafgan : ich erstell ja ein Image von der kompletten Platte, also inklusive MBR, der dann jeweils mitkopiert wird.
Ach so ja, Du klonst ja die ganze Festplatte. Dann ist der MBR natürlich dabei. Müsste also alles ohne Anpassungen funktionieren
So, hab jetzt nochmal gelesen:Wie ich verstanden hab, wird aber die UUID nicht vom BIOS zugewiesen sondern wird bei der Formatierung festgelegt. Und da liegt dann das Problem beim Clonen mittels dd. So könnte man eine zweite Festplatte mit der selben UUID erzeugen. Und dann gibts natürlich Probleme für das System. Dann ist es sicherer mittels der /dev/sd.. zu arbeiten.
Wenn Du ausschließen kannst, dass Du nicht zwei geclonte Festplatten mit dem selben UUID laufen hast, sollte nichts passieren.
Nochmal eine Frage: Du speicherst den Output von dd in ein /dev/sdXY/ als Datei ab? Hab ich noch nicht ausprobiert, aber ist es nicht ratsamer die Partition nach /mnt zu mounten und dorthin die Datei zu speichern?
So, hab jetzt nochmal gelesen:Wie ich verstanden hab, wird aber die UUID nicht vom BIOS zugewiesen sondern wird bei der Formatierung festgelegt. Und da liegt dann das Problem beim Clonen mittels dd. So könnte man eine zweite Festplatte mit der selben UUID erzeugen. Und dann gibts natürlich Probleme für das System. Dann ist es sicherer mittels der /dev/sd.. zu arbeiten.
Wenn Du ausschließen kannst, dass Du nicht zwei geclonte Festplatten mit dem selben UUID laufen hast, sollte nichts passieren.
ja, so hab ich das auch verstanden
Nochmal eine Frage: Du speicherst den Output von dd in ein /dev/sdXY/ als Datei ab? Hab ich noch nicht ausprobiert, aber ist es nicht ratsamer die Partition nach /mnt zu mounten und dorthin die Datei zu speichern?
Das ich das mit einer Live-Version mache, wird so RAM und Dateisystem nicht benutzt und das ist vermutlich schneller; ansonsten ist das g'hupft wie g'sprungen.
Ich kann das sowieso erst am Wochenende machen, also danke an alle erstmal.
corresponder
28.01.13, 22:13
rsync!
;-)
Das ich das mit einer Live-Version mache, wird so RAM und Dateisystem nicht benutzt und das ist vermutlich schneller; ansonsten ist das g'hupft wie g'sprungen.
Ich kann das sowieso erst am Wochenende machen, also danke an alle erstmal.
Hm, also entweder ich habs falsch verstanden oder ... Man kann doch keine Datei in eine nicht gemountete Partiton schreiben... oder doch? :confused: lkwg82 hats zwar bestätigt dass es geht, aber ich würde mir das nochmal genau ansehen! Wozu dann überhaupt noch mounten?
rsync!
Benutze ich jetzt auch öfter für solche Zwecke. Aber der MBR ist dann nicht mit kopiert.
Klar kannst du eine Datei auf die Grätedatei der Partition schreiben. Damit schreibst du aber nicht IN das Dateisystem, sondern darüber. Man verwendet das also beim Klonen...
Klar kannst du eine Datei auf die Grätedatei der Partition schreiben. Damit schreibst du aber nicht IN das Dateisystem, sondern darüber. Man verwendet das also beim Klonen...
OK, wieder was gelernt! :) Und wie kommst Du anschließend wieder an die Datei um zurück zu sichern? Ohne zu mounten dann?:
dd if=/dev/sda2/sicherung.img of=...
Naja, du kannst nacher nur die ganze Partition wieder zurückklonen...
Naja, du kannst nacher nur die ganze Partition wieder zurückklonen...
Ganz genau! Ganze Partitionen können über /dev/sd... geklont werden. Z.B. von /dev/sdb1 auf /dev/sdc1. Das ist klar. Aber wenn ich den Output in eine Datei umleite (sicherung.img) brauch ich ein Dateisystem. Zumindest spätestens, wenn ich die Datei als Input beim Zurücksichern verwenden will. Oder sehe ich das falsch?
Daher GLAUBE ich nicht, dass das Vorhaben aus Beitrag 1 funktioniert. Aber ich lasse mich gerne eines besseren belehren. Delix, würd mich wirklich interessieren!
Gruß und schönen Abend.
hafgan
Stimmt, was da steht mach kein Sinn. Dateien existieren erst, wenn es ein Dateisystem gibt. Von daher ist das, was delix macht Schwachfug.
Naja, du kannst nacher nur die ganze Partition wieder zurückklonen...Nicht ganz richtig. Mit dd erzeugst Du ein Image einer Partition oder Festplatte. Als Loop-Device kannst Du dieses ganz normal mounten und auf einzelne Files zugreifen.
Gruss Pit.
für die Ungläubigen :
http://www.linuxtal.de/infos/anleitung_dd.pdf
die Frage ist, ob das auch bei SSDs bzw. USB-Sticks funktioniert, da hier das Beschreiben anders organisiert ist
Also ich denke das das kein Problem sein dürfte. Auch die neuen Hybrid-ISOs kann man ja mit dd auf USB-Sticks kopieren. Man sollte es nur nicht ständig machen, weil das zu erhöhtem Verschleiß bei den ganzen Flash-Geräten führt.
Nicht ganz richtig. Mit dd erzeugst Du ein Image einer Partition oder Festplatte. Als Loop-Device kannst Du dieses ganz normal mounten und auf einzelne Files zugreifen.
Gruss Pit.
Ja, und darüber kann man das Backup auch aktualisieren ohne dd und damit langes Kopieren. Das Allermeisten hat sich ja meist nicht geändert, aber mit dd kopiert man ja alles mit.
Man kann effizienter einfach mit
rsync -iavxSHz <quelle> <ziel>
abgleichen und das auch remote (über ssh), beispielsweise von oder nach
root@192.168.1.23:/windows/C/tmp/
so, jetzt hier der Bericht :
ad 1.) nein, so geht's nicht. Das scheitert schon daran, daß der cli-installer von AntiX nur in der ISO vorhanden ist, nicht in der installierten Version -- und bei der iso hab ich keine 2. Partition
zum dd - Befehl:
da scheint sich einiges geändert zu haben. Mit einer coreutils_v.8.8 + kernel 2.6.32 geht das Schreiben auf den Stick ohne Einhängen, das Zurückschreiben aber nicht ohne Einhängen
Bei coreutils_v.8.13 + Kernel 3.2.0 geht beides nicht ohne Einhängen
Ich hab dann versucht, das Image auf einen Stick mit installiertem AntiX zu schreiben. Hier hat dann der Rechner (Igel Winstra 4210) schlapp gemacht. Beim ersten Versuch sind 1 GB übertragen worden, beim zweiten 1,6 GB -- und dann jeweils Abbruch ohne Meldung und Landung im User-Login (!?!).
Fazit :
ich denke mit rsync oder Ähnlichem fährt man da besser.
Bei mir hat die Installation von AntiX gottseidank reibungslos geklappt, sodaß ich auf das Image nicht angewiesen bin.
Also Vorsicht noch bei der oben verlinkten Anleitung : ist (zumindest bei neueren Versionen + USB-Sticks) nicht korrekt !
Kurt Sommer
02.02.13, 15:02
Die UUID ist soweit mir bekannt formatseitig festgelegt, muss somit beim Zurückspielen nichts geändert werden, es sei denn du hast die Partitionierung geändert.
Zum Zurückspielen einzelner Dateien hängst du das Image mit:
mount -o loop /Pfad/zum/Image /mountpoint ein
Noch schönen Tag...
Kurt
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.