Komplettabbild von Ubuntu-Installation, Wiederherstellung auf andere SSD/HDD?
- Ersteller Wischmop
- Erstellt am
Tach,
ich habe hier eine 500GB-HDD mit einer speziell eingerichteten HDD. Die komplette HDD soll als Image gesichert und auf einer anderen HDD/SSD wiederhergestellt werden.
Bisher probierte Tools:
Acronis 2018, Boot-DVD: Sicherung dauert relativ lange da Acronis das Dateisystem als beschädigt meldet und deshalb eine Sektor-für-Sektor-Sicherung macht.
Redo Rescue erledigt diese Aufgabe deutlich schneller
Clonezilla habe ich vor längerer Zeit mal probiert.
Bei allen Tools habe ich festgestellt dass man zwar eine Wiederherstellung machen kann, aber nur auf Datenträgern gleicher oder höherer Kapazität des Ursprungsmediums. Wäre also bei 10GB belegten Speicherplatz so dass ich immer mind. 500GB bräuchte, selbst wenn eine 64GB-SSD reichen würde.
Gibt es ein Programm dass ein Image auf kleinere HDD/SSD herstellen kann?
ich habe hier eine 500GB-HDD mit einer speziell eingerichteten HDD. Die komplette HDD soll als Image gesichert und auf einer anderen HDD/SSD wiederhergestellt werden.
Bisher probierte Tools:
Acronis 2018, Boot-DVD: Sicherung dauert relativ lange da Acronis das Dateisystem als beschädigt meldet und deshalb eine Sektor-für-Sektor-Sicherung macht.
Redo Rescue erledigt diese Aufgabe deutlich schneller
Clonezilla habe ich vor längerer Zeit mal probiert.
Bei allen Tools habe ich festgestellt dass man zwar eine Wiederherstellung machen kann, aber nur auf Datenträgern gleicher oder höherer Kapazität des Ursprungsmediums. Wäre also bei 10GB belegten Speicherplatz so dass ich immer mind. 500GB bräuchte, selbst wenn eine 64GB-SSD reichen würde.
Gibt es ein Programm dass ein Image auf kleinere HDD/SSD herstellen kann?
Berniyh
Grand Admiral Special
- Mitglied seit
- 29.11.2005
- Beiträge
- 5.214
- Renomée
- 223
Im Prinzip kannst du bei Linux auch einfach alle Daten mit rsync auf eine neue Partition kopieren (am Besten mit dem gleichen Dateisystem, wenn es ein anderes ist wird es ggf. noch etwas aufwendiger).
Danach müssen noch in der fstab und der grub.cfg entsprechend die UUIDs angepasst werden, sowie grub neu installiert werden und man kann das System auf der neuen HDD starten.
Ist nicht gerade die "for Dummies" Variante, aber geht eigentlich ganz gut.
Danach müssen noch in der fstab und der grub.cfg entsprechend die UUIDs angepasst werden, sowie grub neu installiert werden und man kann das System auf der neuen HDD starten.
Ist nicht gerade die "for Dummies" Variante, aber geht eigentlich ganz gut.
MagicEye04
Grand Admiral Special
Was ist denn da überhaupt wie "speziell eingerichtet" ?
Wenn ein Tool auf eine kleinere SSD clonen soll, muss es ja irgendwie entscheiden, welche Bereiche nicht kopiert werden sollen. Und es muss die Partitionsstruktur anpassen/ändern. Das sind 2 ideale Voraussetzungen, dass danach nichts mehr funktioniert.
Wenn ein Tool auf eine kleinere SSD clonen soll, muss es ja irgendwie entscheiden, welche Bereiche nicht kopiert werden sollen. Und es muss die Partitionsstruktur anpassen/ändern. Das sind 2 ideale Voraussetzungen, dass danach nichts mehr funktioniert.
Berniyh
Grand Admiral Special
- Mitglied seit
- 29.11.2005
- Beiträge
- 5.214
- Renomée
- 223
Ein gutes Backuptool braucht nur so viel Speicherplatz wie für die Speicherung der eigentlichen Daten notwendig ist.
Und nicht nur das, sondern ein Backuptool sollte auch inkrementelle Backups unterstützen, d.h. wenn ich z.B. ein Backup von Mai 2021 habe und das z.B. 50GB Speicherplatz braucht und dann eins von Juni 2021 mache, das dann nur noch 5GB zusätzlich braucht, weil es auf dem vom Mai 2021 aufbaut und nur das speichert was sich seitdem geändert hat.
Gerade wegen sowas ist auch btrfs als Dateisystem für die Systempartition echt cool. Da hat man das nämlich alles integriert und braucht keine externen Tools.
Ähnlich ist es auch mit zfs, allerdings wird das bei Distributionen nicht immer standardmäßig ausgeliefert und generell schlechter (bzw. weniger) unterstützt.
Auch btrfs hat sich ja leider nicht breitflächig durchgesetzt. Bei mir kommt es aber schon seit bald 10 Jahren zum Einsatz und ich bin absolut happy damit.
btrfs ist da vor allem gut, da man mit extrem wenig Aufwand subvolumes (also "quasi-Partitionen") sowie snapshots (als Backups) erstellen und ggf. auch wieder löschen kann.
Bei mir sieht das z.B. so aus:
Code:
btrfs subvolume list /
ID 269 gen 4643792 top level 5 path home/berniyh-ressources
ID 306 gen 4643792 top level 5 path home/berniyh-dotfiles
ID 540 gen 4515901 top level 5 path srv
ID 541 gen 3475708 top level 5 path var/lib/machines
ID 569 gen 4593060 top level 5 path var/paludis/distfiles
ID 607 gen 3475708 top level 5 path var/lib/portables
ID 1059 gen 4233423 top level 5 path snapshots/root-201128
ID 1060 gen 4233424 top level 5 path snapshots/resources-201128
ID 1062 gen 4643792 top level 5 path home/berniyh-cache
ID 1063 gen 4236146 top level 5 path snapshots/dotfiles-201129
ID 1064 gen 4365436 top level 5 path snapshots/root-210130
ID 1065 gen 4383028 top level 5 path snapshots/root-210206
ID 1066 gen 4383028 top level 5 path snapshots/resources-210206
ID 1067 gen 4383030 top level 5 path snapshots/dotfiles-210206
ID 1089 gen 4433197 top level 5 path snapshots/root-210228Die kann man dann ggf. per btrfs send auf einen anderen Datenträger kopieren, komplett oder inkrementell.
Die subvolumes haben hier auch noch eine praktische Nebenfunktion. z.B. liegen in home/berniyh-cache oder var/paludis/distfiles Dateien die einfach nicht gesichert werden müssen, aber ggf. recht viel Platz einnehmen.
Dadurch, dass diese sich in einem subvolume befinden werden die im snapshot nicht mitgesichert und das Backup wird signifikant kleiner.
Ein root Backup, damit ist das eigentliche Linux System gemeint, ohne persönliche Daten, braucht daher bei mir so ca. 40 GB an Speicher, wenn es als komplettes Backup auf einer externen Zielfestplatte abgespeichert wird.
Die eigentliche Partition ist aber ein Vielfaches größer.
Da ist ein Test-Tool für Geräte der Industrieautomation drauf, nach Vorgaben einer Prüfkommission eingerichtet, wird für Zertifizierungen benutzt.
Ist auch nur gültig mit einer bestimmten LTS-Version.
Das Tool ist nicht so einfach zu konfigurieren.
Acronis hat das für Windows im Griff, da kann ich eine 1TB-HDD bei der 50GB belegt sind sichern und das auf eine 64GB-SSD wiederherstellen. Mit Linux-Dateisystemen kann Acronis das aber nicht. Und alle anderen Tools die ich bisher probiert habe scheitern auch daran. Zielmediem muß entweder gleiche Größe haben oder größer sein, kleiner geht nicht.
Ist auch nur gültig mit einer bestimmten LTS-Version.
Das Tool ist nicht so einfach zu konfigurieren.
Acronis hat das für Windows im Griff, da kann ich eine 1TB-HDD bei der 50GB belegt sind sichern und das auf eine 64GB-SSD wiederherstellen. Mit Linux-Dateisystemen kann Acronis das aber nicht. Und alle anderen Tools die ich bisher probiert habe scheitern auch daran. Zielmediem muß entweder gleiche Größe haben oder größer sein, kleiner geht nicht.
Dalai
Grand Admiral Special
Wenn dir es nichts ausmacht, auf Kommandozeilentools zurückzugreifen, kannst du dir mal fsarchiver anschauen. Da dieses Tool - wie der Name schon sagt - nur das Dateisystem sichert bzw. die Dateien in diesem, ist es völlig egal, auf welchem Medium und Dateisystem die Wiederherstellung erfolgt. Eine (ggf. wichtige) Einschränkung gibt es: Die Bootfähigkeit eines Systems bleibt unbeachtet, d.h. wenn das Laufwerk, auf dem wiederhergestellt wird, nicht bootfähig ist, muss man an der Stelle nacharbeiten.
Grüße
Dalai
Grüße
Dalai
Dalai
Grand Admiral Special
Die Bootfähigkeit kann man z.B. mit der Super Grub Disk (bzw. Super Grub2 Disk) erzeugen. Pro Medium/Partition/Laufwerk muss das eh nur einmalig gemacht werden.
Grüße
Dalai
Grüße
Dalai
Dalai
Grand Admiral Special
Wenn man mit GParted Partitionen bearbeitet, wird in jedem Fall bei den unter Linux üblichen Dateisystemen pro Aktion mindestens einmal automatisch eine Dateisystemprüfung mit fsck gemacht, bevor die eigentliche Größenänderung durchgeführt wird. Ich meine mich sogar zu erinnern, dass nach der Größenänderung nochmal ein fsck läuft, denn eine Größenänderung einer Partition sind immer zwei Schritte: Änderung der Partitionsgröße und anschließend die Änderung der Größe des darin enthaltenen Dateisystems. Und das Tool will/soll ja sicherstellen, dass die Größe des Dateisystems zur Partitionsgröße passt. Wenn man die Ausgaben im GParted-Verlaufsfenster ausklappt, sieht man das auch.
Grüße
Dalai
Grüße
Dalai
Berniyh
Grand Admiral Special
- Mitglied seit
- 29.11.2005
- Beiträge
- 5.214
- Renomée
- 223
Ja, nennt sich dateisystem.fsck, wobei 'dateisystem' eins ausIch danke für die Tipps, aber ob ich das alles durchprobiere weiß ich noch nicht
Hat Ubuntu eigentlich eine Art Checkdisk? Nicht dass Gparted wegen einem Filesystemfehler abbricht
Code:
ls -1 /usr/bin/fsck.*
/usr/bin/fsck.btrfs
/usr/bin/fsck.cramfs
/usr/bin/fsck.exfat
/usr/bin/fsck.ext2
/usr/bin/fsck.ext3
/usr/bin/fsck.ext4
/usr/bin/fsck.fat
/usr/bin/fsck.minix
/usr/bin/fsck.msdos
/usr/bin/fsck.vfatDie gelisteten dürften aber die gängigsten sein.
Wird aber – wie erwähnt – eigentlich automatisch ausgeführt.
Ausnahme ist dabei btrfs. Da gibt es zwar auch ein fsck, wie man in der Liste sehen kann, aber das wird eigentlich nicht wirklich verwendet.
Das repariert sich im Normalfall online und transparent, soweit es möglich ist.
Welches Dateisystem zum Einsatz kommt kann man z.B. mit
Code:
findmnt --mountpoint /MagicEye04
Grand Admiral Special
Da würde ich mir doch keine weitere Mühe machen und einfach ein mindestens gleich großes Medium nehmen.
Das sind ab 50€ für ne 500GB SSD.
thorsam
Grand Admiral Special
- Mitglied seit
- 05.04.2003
- Beiträge
- 2.729
- Renomée
- 944
Zeige doch mal bitte einen Screenshot von Gparted.
Bei mir war es, dass ich eine 1:1 Kopie von einer 500GB Platte auf eine 480 GB Platte, oder 1TB zu 960 GB machen mußte.
Solange keine Daten auf dem letzten fehlenden Platz waren, hat der der gute alte dd-Shell-Befehl tadellos seine Arbeit gemacht.
Er beendet den Vorgang zwar mit einer Fehlermeldung, aber die Kopie funktioniert einwandfrei.
Bei mir war es, dass ich eine 1:1 Kopie von einer 500GB Platte auf eine 480 GB Platte, oder 1TB zu 960 GB machen mußte.
Solange keine Daten auf dem letzten fehlenden Platz waren, hat der der gute alte dd-Shell-Befehl tadellos seine Arbeit gemacht.
Er beendet den Vorgang zwar mit einer Fehlermeldung, aber die Kopie funktioniert einwandfrei.
z.T. Macrium: RTFM würde ich empfehlen....
= Wenn der Ziel Datenträger kleiner als der Quell Datenträger ist, muss man die Partitionsgrößen anpassen.
Das geht natürlich nur so weit, bis man die Grenze an vorhandenen Daten erreicht.
Wenn z.B. schon 100GB Daten in der Quell Partition vorhanden sind, kann die Größe der Ziel-Partition natürlich nicht 80GB betragen.
Ich denke aber, dass dies wohl logisch sein dürfte.
Gruß Ralf
= Wenn der Ziel Datenträger kleiner als der Quell Datenträger ist, muss man die Partitionsgrößen anpassen.
Das geht natürlich nur so weit, bis man die Grenze an vorhandenen Daten erreicht.
Wenn z.B. schon 100GB Daten in der Quell Partition vorhanden sind, kann die Größe der Ziel-Partition natürlich nicht 80GB betragen.
Ich denke aber, dass dies wohl logisch sein dürfte.
Gruß Ralf
Berniyh
Grand Admiral Special
- Mitglied seit
- 29.11.2005
- Beiträge
- 5.214
- Renomée
- 223
Man kann ja im Zweifelsfall immer noch Daten die nicht mitgesichert werden müssen in eine separate Partition auslagern.
Ist eh generell sinnvoll um das Backup möglichst klein zu halten.
Gerade wenn es um ein mehrfaches Rollout geht, dann gibt es sicher einige Daten die auf den neuen Geräten nichts zu suchen hat (und natürlich auch welche die man mitnehmen möchte).
Wenn man da intelligent vorgeht kann man sich später viel Arbeit sparen.
Auch da kann ich nur wieder btrfs empfehlen oder als Alternative lvm. Letzteres ist halt etwas weniger bequem, aber trotzdem auch sehr verbreitet.
Das reine Betriebssystem (also ohne Nutzerdaten) sollte eigentlich ziemlich klein sein. Je nach Installation evtl. 3-10 GB.
Ist eh generell sinnvoll um das Backup möglichst klein zu halten.
Gerade wenn es um ein mehrfaches Rollout geht, dann gibt es sicher einige Daten die auf den neuen Geräten nichts zu suchen hat (und natürlich auch welche die man mitnehmen möchte).
Wenn man da intelligent vorgeht kann man sich später viel Arbeit sparen.
Auch da kann ich nur wieder btrfs empfehlen oder als Alternative lvm. Letzteres ist halt etwas weniger bequem, aber trotzdem auch sehr verbreitet.
Das reine Betriebssystem (also ohne Nutzerdaten) sollte eigentlich ziemlich klein sein. Je nach Installation evtl. 3-10 GB.
Das habe ich probiert, Gparted konnte es aber nicht.
Ist Acronis wirklich der einzige Hersteller der das, zumindest bei Windows-Partitionen, hinbekommt?
Ich habe es gerade noch einmal mit Macrium probiert.
Keine Probleme. Die erforderliche Verkleinerung der Partition wird sogar automatisch erkannt und vorgeschlagen.
-
Ich habe eine virtuelle Maschine mit einer HDD von 80GB als Full Image mit Macrium Reflect Free 7.3 Build 5925 gesichert.
Datenbestand auf dieser 80GB HDD rund 20GB.
Sicherungsdatei und Notfall Boot Medium auf ein Netzlaufwerk (aber das dürfte wohl egal sein)
-
Dann eine neue (leere) virtuelle Maschine mit einer 60GB HDD erzeugt und diese vom Macrium ICE Image gebootet.
Netzlaufwerk verbunden - Backup Image ausgewählt - Wiederherstellen ausgewählt - Zieldatenträger = die neue leere 60GB HDD ausgewählt ---- unten in der Leiste wird angezeigt "Schrinking last Partition required......." dies bestätigt und Wiederherstellung laufen lassen - funktioniert wie gewohnt, wiederhergestelltes System läuft.
Die geschrumpfte Partition ist rund 60GB groß und enthält die 20GB Daten.
GParted brauch ich dafür nicht - Macrium hat alles, was man benötigt und arbeitet fast automatisch (wenn man mal von der Bestätigung absieht)
Irgendwas machst Du wohl falsch.
Gruß Ralf
Keine Probleme. Die erforderliche Verkleinerung der Partition wird sogar automatisch erkannt und vorgeschlagen.
-
Ich habe eine virtuelle Maschine mit einer HDD von 80GB als Full Image mit Macrium Reflect Free 7.3 Build 5925 gesichert.
Datenbestand auf dieser 80GB HDD rund 20GB.
Sicherungsdatei und Notfall Boot Medium auf ein Netzlaufwerk (aber das dürfte wohl egal sein)
-
Dann eine neue (leere) virtuelle Maschine mit einer 60GB HDD erzeugt und diese vom Macrium ICE Image gebootet.
Netzlaufwerk verbunden - Backup Image ausgewählt - Wiederherstellen ausgewählt - Zieldatenträger = die neue leere 60GB HDD ausgewählt ---- unten in der Leiste wird angezeigt "Schrinking last Partition required......." dies bestätigt und Wiederherstellung laufen lassen - funktioniert wie gewohnt, wiederhergestelltes System läuft.
Die geschrumpfte Partition ist rund 60GB groß und enthält die 20GB Daten.
GParted brauch ich dafür nicht - Macrium hat alles, was man benötigt und arbeitet fast automatisch (wenn man mal von der Bestätigung absieht)
Irgendwas machst Du wohl falsch.
Gruß Ralf
Danke für deine Mühe.
Habe diesselbe Macrium-Version.
Ob das was mit der VM zu tun hat? Oder hast du ein Systemabbild von Windows gezogen? Da kann zumindest Acronis an kleinere Partitionen anpassen, aber nicht bei Linux
So sieht meins aus:
Die Fehlermeldung kommt sofort wenn ich das Recovery starten will, Optionen habe ich sonst keine. Es ändert sich auch nix wenn ich die Partition auf dem Ziel lösche
Habe diesselbe Macrium-Version.
Ob das was mit der VM zu tun hat? Oder hast du ein Systemabbild von Windows gezogen? Da kann zumindest Acronis an kleinere Partitionen anpassen, aber nicht bei Linux
So sieht meins aus:
Die Fehlermeldung kommt sofort wenn ich das Recovery starten will, Optionen habe ich sonst keine. Es ändert sich auch nix wenn ich die Partition auf dem Ziel lösche
Ähnliche Themen
