Hallo, vorab: ich nutze hier Clonezilla schon seit vielen Jahren und habe schon etliche "Platte auf Platte" Backups erstellt. Arbeite dabei die Reihenfolge stets streng nach Checkliste ab. Bin aber kein Linux-Experte. Aktuell war auf einem Dual-Boot Notebook mit Windows/Ubuntu ein Backup auf eine baugleiche HDD zu machen. Beide Platten waren WD1600BEVT mit je 160 GB. Das letzte Backup wurde 2019 erstellt. Das Backup lief wie üblich ohne Probleme durch. Nach dem Neustart des Systems fiel dann auf, dass die Maus tot war und der Router nicht gefunden wurde. Als dann das Notebook noch die interne Festplatte als neue Hardware gefunden hatte, wusste ich, dass was faul war. Das Backup lief in die falsche Richtung, ich hatte jetzt das System von 2019. Zu der Zeit hatte ich eine andere Maus und einen anderen Router. Nachdem ich das System wieder aktualisiert hatte, habe ich erneut ein Backup angestoßen und mir diesmal vorab mittels CrystalDiskInfo die Nummern der Platten notiert und genau aufgepasst. Denn Clonezilla zeigt zu sda bzw. sdb auch die Nummern der Platten an. Und es ist so, dass sda nicht die Quellplatte ist und sdb nicht die Zielplatte, sda und sdb sind vertauscht. Habe dann von sdb nach sda kopiert und es hat gepasst. Die beiden zentralen Fragen wären: 1. Was ist da angebrannt? 2. Bekommt man das irgendwie repariert? Hans
Deshalb gibt es UUIDs. Die Reihenfolge sda, sdb ist lediglich diejenige, mit der die FP vom System gefunden wurden.
Klemm die Zielplatte an dem Menüpunkt an,
wo es dich dazu auffordert.
Das ist doch irgendwo auf "halbem Wege" der ganzen Enterdrückerei.
und dann
>> 5 Sekunden warten
Wenn die Quellplatte bereits beim Booten dran ist,
sollte die sda sein.
:
Bearbeitet durch User
.● Des|ntegrator ●. schrieb: > Klemm die Zielplatte an dem Menüpunkt an, > wo es dich dazu auffordert. /dev/sdx sind keine Platten am USB Port! SATA ist selten hotplugfähig. Noch was: Die UUID wird mitgeclont. Man sollte also nach dem clonen der Platte die UUID der Backuplatte ändern. Sonst hat man das nächste Mal wieder das gleiche Problem.
:
Bearbeitet durch User
Clonen verzeiht keine Irrtümer. Wenn Quelle und Ziel irrtümlich vertauscht wurden, hat man im schlimmsten Fall blitzschnell 2 leere Datenträger. Deswegen bevorzuge ich Images sofern möglich.
Klarheit verschafft stets ein:
1 | ~$ lsblk -oNAME,SIZE,MODEL,SERIAL|grep "sd[a-z] " |
2 | sda 232,9G Samsung_xxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxx |
3 | sdb 186,3G STxxxxxxxxx xxxxxxxx |
4 | sdc 931,5G SAMSUNG_xxxxxxx xxxxxxxxxxxxxx |
5 | sdd 1,4T SAMSUNG_xxxxxxx xxxxxxxxxxxxxx |
6 | sde 3,6T STxxxxxxxxx-xxxxxx xxxxxxxx |
7 | sdf 28,6G Ultraxxxx xxxxxxxxxxxxxxxxxxxx |
Darf man sich in ein bash script schreiben.
:
Bearbeitet durch User
Beitrag #8055208 wurde vom Autor gelöscht.
Lu schrieb: > Deswegen bevorzuge ich Images sofern möglich. so auch hier. und das Image muss man auch mit einer dritten Platte testen. Sprich nicht einfach nur Image erstellen und weg legen. Das wäre im Bedarfsfalle nicht der erste Fehler im Sinne von "Image kann nicht gelesen werden"
Andreas B. schrieb: > SATA ist selten hotplugfähig. Ich hatte noch keinen Rechner, wo es nicht hotplugfähig war. Tatsächlich ist das Teil der Spezifikation – gegebenenfalls muss man es im Firmware-Setup einstellen.
Lu schrieb: > Deswegen bevorzuge ich Images sofern möglich. > Die dann nicht gehen wenn du sie brauchst? Ich habe noch nie diesen Fehler beim klonen mit Clonezilla gehabt. Bei mir wird die Quellplatte richtig erkannt. Meine Quelle ist eine Toshiba, die Zielplatte eine Samsung. Alleine deswegen kann ich die gut auseinanderhalten. Natürlich muss man die Eintragung der Laufwerke überprüfen...immer. Früher hatte ich zwei baugleiche Laufwerke, die kann man nur über die Seriennummer auseinander halten.
Herbert Z. schrieb: > Ich habe noch nieee diesen Fehler beim klonen mit Clonezilla gehabt. Ich habe vor Jahren schon mal eine leere Diskette auf eine volle "gesichert" und viel dabei gelernt. *Sie waren dann beide leer!*
Hans H. schrieb: > Nach dem Neustart des > Systems fiel dann auf, dass die Maus tot war und der Router nicht > gefunden wurde. Neustart: Neue Zuteilung von sda und sdb zu den Platten möglich. Also: Hersteller/Typ/Grösse/ggf.Seriennummer checken!
Stephan S. schrieb: > Neustart: Neue Zuteilung von sda und sdb zu den Platten möglich. > Also: Hersteller/Typ/Grösse/ggf.Seriennummer checken! Nach dem Klonvorgang hat er entweder die Neue auf die alte Platte geschrieben. Dann sind beide gleich. Oder er hat die Alte auf die neue Platte geschrieben. Dann sind ebenfalls beide gleich. Also sollte es egal sein in welcher Reihenfolge die beiden Platten auf sda und sdb gemappt werden.
Man könnte ja auch ganz einfach selbst mal einen Blick auf die Daten werfen bevor man startet. Zur Not mtime auf /var/log/journal/*/*.journal oder pagefile.sys per Skript vergleichen oder sowas.
Man sollte immer wissen was man tut und den gröbsten aller Fehler durch "kontrolletti" ausschließen. Quelle und Ziel vertauschen ist echt schlecht...
Andreas B. schrieb: > Deshalb gibt es UUIDs. > Die Reihenfolge sda, sdb ist lediglich diejenige, mit der die FP vom > System gefunden wurden. Das ist die richtige Antwort. Bei allem, was durchnummeriert ist / keine UUID oder ähnliches hat, geht man am besten davon aus, dass die Reihenfolge zufällig ist. Zumindest als grobe Faustregel, auf manche Sachen, wie die Partitionsnummer, kann man sich natürlich schon verlassen.
Hans H. schrieb: > Was ist da angebrannt? Dein Fehler: Du hast nur auf die logische Platten-Bezeichnungen geschaut und irrtümlicherweise angenommen, dass die immer und ewig mit denselben physischen Platten verbunden sind. Sind sie aber nicht. > Bin aber kein Linux-Experte. Wenn du unter Windows D: nach E: kopierst, kann dir genau dasselbe Missgeschick passieren. > Arbeite dabei die Reihenfolge stets streng nach Checkliste ab. In der Checkliste fehlt der Punkt "Prüfe vor dem Starten des Kopierens zweimal, ob wirklich die richtige physische Platte als Zielplatte genutzt wird."
Beitrag #8055295 wurde vom Autor gelöscht.
Frank D. schrieb: > Andreas B. schrieb: >> /dev/sdx sind keine Platten am USB Port! > So pauschal einfach falsch. Stimmt, da habe ich was verwechselt.
Jack V. schrieb: > Andreas B. schrieb: >> SATA ist selten hotplugfähig. > > Ich hatte noch keinen Rechner, wo es nicht hotplugfähig war. Tatsächlich > ist das Teil der Spezifikation – gegebenenfalls muss man es im > Firmware-Setup einstellen. Meines Wissens braucht es dazu spezielle HW. Oder geht das mit diesen getrennten Steckern für Power & Daten?
"ls -lR /dev/disk/" liefert Platten in verschiedenen Geschmacksrichtungen Da ist für jeden was dabei. Und wenn man das Image als File in ein Filesystem schreibt besteht noch weniger Verwechslungsgefahr.
:
Bearbeitet durch User
Andreas B. schrieb: > Meines Wissens braucht es dazu spezielle HW. Oder geht das mit diesen > getrennten Steckern für Power & Daten? Das geht problemlos mit den normalen SATA Steckern (mit engen Grenzen für die Anzahl der Steckvorgänge). Wenn man's oft machen will, dafür gibt es extra eSATA Steckanschlüsse zB. für die Slotblende.
G. K. schrieb: > "ls -lR /dev/disk/" liefert Platten in verschiedenen > Geschmacksrichtungen > > Da ist für jeden was dabei. …und nur (im Sinne von ausschließlich) /dev/disk/by-id/ enthält von der Hardware abgeleitete Namen, welche wie oben schon gelistet zB. auch SERIAL beinhalten.
Lu schrieb: > Clonen verzeiht keine Irrtümer. Wenn Quelle und Ziel irrtümlich > vertauscht wurden, hat man im schlimmsten Fall blitzschnell 2 leere > Datenträger. Da Clonezilla ja auch den Typ/Hersteller anzeigt und sich die bei mir grob unterschieden ist Clonen für mich ein akzeptabler Weg.
Andreas B. schrieb: > Meines Wissens braucht es dazu spezielle HW. Oder geht das mit diesen > getrennten Steckern für Power & Daten? SATA ist prinzipiell hotplugfähig, genau dafür wurden die Steckverbinder mit vorauseilenden Massekontakten erfunden. Aber nicht jeder SATA-Hostcontroller kommt damit zurecht, und erst recht nicht jedes Betriebssystem. Am wenigsten Ärger hat man, wenn man eine der zu klonenden Platten/SSDs an einem USB-SATA-Adapter betreibt. Der ist prinzipiell immer hotplugfähig, und der sollte selbst unter Clonezilla leicht vom SATA-Controller des PCs zu unterscheiden sein. Sofern man keinen Uralt-PC verwendet, der nur USB2.0 kennt, ist so etwas auch ausreichend schnell. Bei SATA-SSDs ist die USB-Lösung vielleicht 10..20% langsamer, aber das auch nur, solange der Cache der SSD ausreicht.
Harald K. schrieb: > Aber nicht jeder SATA-Hostcontroller kommt damit zurecht, und erst recht > nicht jedes Betriebssystem. Welches denn nicht? Selbst Windows (getestet mit 10 und 11) kommt heutzutage damit zurecht, Linux und FreeBSD ebenso. MacOS, OpenBSD und TempleOS habe ich noch nicht probiert, bei den beiden BSDs würde ich es allerdings annehmen. Letzteres kommt vermutlich wirklich nicht damit klar – aber ich kenne keinen, der das ernsthaft nutzt. Und wie gesagt: Ich hatte noch keinen Rechner, bei dem es nicht funktioniert hat, und ich hab ’ne Zeitlang wirklich viele Rechner am Wickel gehabt (als in den Firmen die Hardware auf ’nen Win11-fähigen Stand gebracht wurde – da haben wir die Datenträger im laufenden Betrieb an die Boards gehängt und abgezogen, weil’s halt am schnellsten ging). Einer meiner PCs kam damit mal nicht zurecht (glaube, das hatte ich hier im Forum irgendwo auch mal geschrieben), aber da war’s besagte Einstellung im Firmware-Setup.
:
Bearbeitet durch User
Rolf schrieb: > In der Checkliste fehlt der Punkt "Prüfe vor dem Starten des Kopierens > zweimal, ob wirklich die richtige physische Platte als Zielplatte > genutzt wird." Nach der aktuell üblen Erfahrung habe ich meine Checkliste angepasst. Ich hielt bei einem Backup die Richtung von A nach B in Stein gemeißelt. Bei meinem zweiten und hauptsächlich genutzten System ist dies und war das auch immer so. Clonezilla gibt hier bei der Auswahl der Platten folgende Info aus: Wählen Sie die lokale Original-Platte. Die erste Platte im System ist "hda" oder "sda", die zweite Platte ist "hdb" oder "sdb"... Ich verstehe als erste Platte die Platte, die fest im Gerät verbaut ist. Desweiteren liefert Clonezilla hier bei der Auswahl von Quell-und Zielplatte folgende Informationen zur Platte: Speicherplatz - Hersteller - Modellnummer (MDL) - Seriennummer (S/N) Alle vier Angaben stehen auf dem Label der Platte und werden einem auch in CrystalDiskInfo angezeigt. Man kann also eine Platte eindeutig zuordnen und sollte sda bzw. sdb besser vergessen.
Herbert Z. schrieb: > Lu schrieb: >> Deswegen bevorzuge ich Images sofern möglich. > Die dann nicht gehen wenn du sie brauchst? Das ist auch meine Befürchtung. Und bei einem testweisen zurück laden des eben erstellten Images hat man sich schnell mal sein System versaut. Bei einem Backup auf eine zweite Platte kann ich zum Testen mal eben umstecken, ohne mein aktuelles System zu riskieren.
Daniel A. schrieb: > Andreas B. schrieb: >> Deshalb gibt es UUIDs. >> Die Reihenfolge sda, sdb ist lediglich diejenige, mit der die FP vom >> System gefunden wurden. > > Das ist die richtige Antwort. Bei allem, was durchnummeriert ist / keine > UUID oder ähnliches hat, geht man am besten davon aus, dass die > Reihenfolge zufällig ist. Die Reihenfolge ist aber nicht zufällig. Der TE wird, wie in seinen Threads üblich, mindestens einen Fakt nicht genannt haben, der zu einer anderern Bennungsreihenfolge geführt hat.
Man kann ein Image erzeugen auf einem großen Datenträger und später auf eine neue Platte zurückspielen. Das kostet zwar Zeit, hat aber den Vorteil, dass man später noch ein Image als Backup im Schrank herumliegen hat, wenn die neue Platte eingebaut wurde und funktioniert.
Hans H. schrieb: > Desweiteren liefert Clonezilla hier bei der Auswahl von Quell-und > Zielplatte folgende Informationen zur Platte: > > Speicherplatz - Hersteller - Modellnummer (MDL) - Seriennummer (S/N) Gleich die erste Anleitung, die Google im Netz zu Clonezilla findet, schreibt: „Um die Festplatten später eindeutig zuzuordnen, können Sie sich im Vorfeld die Seriennummern der Festplatten notieren. Diese finden Sie z.B. auf den Deckeln der Festplatten.“ Erfahrung kommt halt überall von erfahren. Oliver
Michael L. schrieb: > Die Reihenfolge ist aber nicht zufällig. Das ist wahr, nur sind die Faktoren für den User nicht in jedem Fall vorhersehbar, die die Reihenfolge kann sich durchaus von Boot zu Boot ändern. Zu Festplattenzeiten mit zwei Platten, die ähnlich schnell angelaufen sind, war’s fast schon als RNG zu gebrauchen, aber ich hab das Verhalten auch schon bei Flash-Datenträgern beobachtet. Ich würde daher zumindest diesbezüglich nichts unterstellen wollen.
:
Bearbeitet durch User
Norbert schrieb: > …und nur (im Sinne von ausschließlich) /dev/disk/by-id/ enthält von der > Hardware abgeleitete Namen, welche wie oben schon gelistet zB. auch > SERIAL beinhalten. /dev/disk/by-path kann auch zur eindeutigen Identifizierung heran gezogen werden. Nicht umsonst schrieb ich von verschieden Geschmacksrichtungen.
G. K. schrieb: > /dev/disk/by-path kann auch zur eindeutigen Identifizierung heran > gezogen werden. > > Nicht umsonst schrieb ich von verschieden Geschmacksrichtungen. So wie ich das sehe, identifizierst du damit aber den Anschluss, nicht jedoch das angeschlossene physikalische Gerät. Solange man nichts an- oder umsteckt, ist das in Ordnung. Allerdings hören sich ›Notebook‹ und ›zwei physische Harddisks‹ sowie etwas seltsam an.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.