Laptop-Rettung aus unvollständiger Sicherheitskopie

[Christoph Franzen]

Hallo zusammen,

so direkt paßt mein Problem leider in kein Unterfoum; es geht um eine Neuinstallation mit der „Randbedingung“, daß ein alter Zustand möglichst gut wiederhergestellt werden soll, daher schildere ich das hier.

Ausgangslage:

• Laptop-SSD versehentlich gelöscht, nichts direkt vom Datenträger wiederherstellbar (testdisk/…).
• Ältere Sicherheitskopie des Root-Dateisystems wegen kaputter externer Festplatte verloren.
• Vorhanden sind Sicherheitskopien von /root, /home und /var.

Der Plan:

1. Von USB GRML starten.
2. Partitionstabelle machen.
3. Swap und / anlegen.
4. Einhängen von / irgendwo unter /media/ im GRML.
5. Mit debootstrap dorthin ein Minimalsystem installieren, das dem alten vom Versionsstand her möglichst gut entspricht.
6. Kopieren der vorhandenen Sicherheitskopien in Ordner unterhalb von /tmp der soeben mit debootstrap erzeugten Verzeichnisstruktur, damit sie später innerhalb der Chroot-Umgebung liegen.
7. Kopieren von selbstgebastelten Hilfs-Skripten nach /usr/local/(s)bin der neu angelegten Struktur.
8. mount -o bind für /proc, /sys, /dev und /dev/pts von GRML ins künftige System.
9. Chroot darein.
10. Benutzer und deren Gruppenzuordnung mit einem der oben genannten Hilfs-Skripte genauso einrichten, wie sie auf meinen anderen Rechnern sind (ID-Gleicheit ist besser bei Datei-Kopien per NFS/Samba/Rsysnc/Datenträger).
11. Grub installieren.
12. /etc/apt/sources.list(.d) und /etc/apt/apt.conf(.d) prüfen/ergänzen.
13. mount -o bind von der Sicherheitskopie in /tmp über das neue, minimalistische /var. (Annahme: dpkg/apt/dselect „glauben“ nunmehr, das System wäre im alten Paket-Zustand, den ich wiederherstellen möchte.)
14. dpkg --get-selections > /tmp/Paketliste.txt
15. umount /var
16. /tmp/Paketliste.txt nochmal prüfen, gegebenenfalls bearbeiten.
17. apt-get update
18. Apt nun veranlassen, die Pakete aus /tmp/Paketliste.txt nachzuinstallieren.
19. Das Hilfs-Skript aus Schritt 10 nochmal starten, für den Fall, daß im Schritt 18 Systemgruppen hinzugekommen sind, in denen Benutzer drin sein sollen.
20. /root und /home aus deren Kopien in /tmp zurückkopieren.
21. /var zurückkopieren.
22. Unter /etc die Konfigurationen von Samba/NFS/Rsync und Crontabs prüfen/erstellen, so daß automatisierte Sicherheitskopien und dergleichen wieder gehen.
23. Neustart (ohne GRML)
24. apt-get update
25. Gegebenenfalls dist-upgrade, je nachdem wie aktuell der Laptop zur Zeit der alten Kopien war.

Fragen:

1. Fällt jemandem eine bessere Vorgehensweise ein?
2. Wenn nicht: geht das so im Prinzip oder habe ich was übersehen/falsch eingeschätzt?
3. Fehlen in der Liste Einzelschritte?
4. Sollte man die Reihenfolge obiger Schritte ändern?
5. Wie genau wäre die empfohlene Vorgehensweise bei Schritt 18?
6. Worauf ist bei Schritt 21 zu achten? Also: was darf nicht (dpkg/apt), was sollte (nicht), was kann gefahrlos übernommen werden?
7. Ratschläge, worauf ich sonst noch achten sollte?

Der Fragenkatalog ist nicht abschließend gemeint, jegliche Kommentare sind willkommen. Bis Schritt 3 ist erledigt, weil jene ersten ohnehin gemacht werden müssen, im Rahmen einer anderen Installations-Methode als debootstrap könnte man diese Schritte dort überspringen.

Danke schonmal im voraus, Christoph

[GregorS]

... jegliche Kommentare sind willkommen.

Bei meinem letzten Computerwechsel hatte ich zunächst vor, das System vom alten Rechner 1-zu-1 zu übernehmen und dann von Debian 10 zu 11 zu upgraden. Einfacher und vermutlich wesentlich unkomplizierter war dann aber, einfach eine normale Installation vorzunehmen und /home vom alten Rechner zu kopieren.
Nach dem Login erhielt ich halt ein XFCE mit ziemlich vielen „X“-Icons zu sehen. Die habe ich dann „untersucht“, um die dazu fehlenden Programme nachzuinstallieren.

Da Du /home noch hast, könntest Du vergleichbar vorgehen. Vorteil: Du hättest als Basis eine frische Neuinstallation, die vermutlich wesentlich schlanker ausfällt als Dein jetzt fehlendes System aus dem Backup.

Es könnte schlimmer sein - und die Sonne scheint immer

Gruß

Gregor

[juribel]

Ich kann mich nur meinem Vorredner anschliessen

Vor einem Monat habe ich mein System komplett neu installiert und bin dabei sogar von xubuntu auf debian 12 umgestiegen. Dabei bin ich exakt so vorgegangen wie mein Vorredner beschreibt. Da du deinen /home-Ordner ja gesichert hast, hast du schon alles, was du brauchst.

Mach eine einfache Neu-Installation, kopiere deinen Home-Ordner aus der Sicherung (dafür kannst du dir einen zweiten Benutzer anlegen und ihm root-Rechte geben). Kann dann höchstens sein, dass du rekursiv für den Home-Ordner Eigentümer und Berechtigungen richtig stellen musst.

Auch ich hatte jede Menge fehlender Icons in meiner Starter-Leiste und hab die fehlenden Programme einfach nachinstalliert. Ihre Einstellungen finden sie ja in deinem /home. Darüber hinaus installiere ich Programme grundsätzlich mit "sudo apt get..." in der Kommandozeile und schreibe die Befehle in einem Installationsskript mit. Es gibt ja Vieles, was man nicht sofort sieht, wie fehlende Perl-Module und dergleichen.

Ich habe unter debian jetzt exakt dasselbe (Programme, Einstellungen, Aussehen), was ich unter xubuntu hatte. Nur das Firefox-Profil zu übernehmen erforderte ein bisschen Recherche, weil die LTS-Version von debian älter ist als die von xubuntu. Aber am Ende waren da nur ein paar Dateien zu kopieren.

Also alles in allem kein Hexenwerk, keine Raketentechnik. Simpel, narrensicher, und FUNKTIONIERT.

[Christoph Franzen]

Hallo,

danke schonmal für die erste Antwort, hierzu zur weiteren Erklärung:

Um einige von den Punkten aus meiner Beschreibung komme ich nicht drumrum, so die Sache mit den IDs aus /etc/passwd / group / shadow / gshadow, sonst käme ich mit bestehenden Kopier-Skripten in Teufels Küche. (Ja, NFS kann man wohl IDs aus den Namen „übersetzen“ lassen, aber lokal eingehängte Datenträger haben nur IDs, keine Namen im Dateisystem.) Weiterhin verwende ich vielfach eben nicht das, was bei einer Auswahl „Desktop-System“ vorgewählt ist und habe auch mehr als einen Normal-Benutzer (müßte also mindestens 5 Nutzerkonten einer „Nachprüfung durch Ausprobieren“ unterziehen, beim Rest wäre es nicht so wichtig). Ich wollte eben gerade vermeiden, umfangreiche händische Nachinstallationen vorzunehmen. Man vergißt ja doch immer was und das ist der Ersatz-Laptop, der wieder ins Ferienhaus soll, kein Gerät, mit dem ich dann dauernd arbeiten täte, wo ich schlimmstenfalls dann und wann merkte, daß doch noch was fehlte und das dann nachinstallierte. Der soll halt in einwandfrei laufendem Zustand „eingelagert“ werden und nach dem Auspacken dann sofort losrennen, ohne daß man noch „nacharbeiten“ muß. Mein Bruder vor Ort ist ein DAU, wenn sein Gerät auf die Nase fällt, muß auf dem Ersatzteil alles rundlaufen. Lieber ein Altlasten-Paket zu viel drauf, als daß was auf die Nase fällt, das zu testen ich vergessen hatte. Mir fällt schon wieder was ein: Drucker einrichten fehlt schonmal in der Liste. In /etc habe ich kaum was verändert, aber das fehlt eben auch, so daß solche Sachen nachgearbeitet werden müssen. Als ich meinr Mutter Rechner auf AMD64 umgebaut hatte, hatte ich es mir „einfacher“ gemacht und dabei vergessen, vor der Installation das alte /etc einzuspielen – gab dann Ärger mit den automatisch gewürfelten System-IDs.

Viele Grüße

[GregorS]

... hierzu zur weiteren Erklärung: ...

Ja, das ist dann wohl doch etwas mehr Arbeit.

Spontan fällt mir dazu erst mal nur ein: Shit happens.

Es bleibt Dir wohl nichts Anderes übrig, als abzuschätzen, was weniger Arbeit macht. Ein fehlendes oder zerschossenes Backup ist nunmal eine echt, echt blöde Sache. Ich musste das vor rund 20 Jahren lernen.

Gruß

Gregor

[hikaru]

Vorwort:
Ich mache seit jeher bei jedem Releasewechsel eine Neuinstallation auf eine andere Partition. Seit einiger Zeit mache ich das per debootstrap aus dem alten System heraus. Als Grundlage für die Paketliste nehme ich die Ausgabe von apt-mark showmanual des alten Systems, die ich aber händisch bearbeite (Libs fliegen raus, Pakete mit Versionsnummern im Namen ändern sich, wine ist jedes mal anders).
Ich habe nur zwei Benutzer: Meinen Hauptnutzer und einen User für den "Schmuddelbrowser", wo z.B. Youtube und falls nötig Google-Suchen laufen.

Zu deiner Liste, die im Wesentlichen sinnvoll aussieht:
10.: Nicht vergessen, ein root-Passwort zu vergeben! Sonst drehst du eine Ehrenrunde im chroot.

Ich vermute, 13. & 14. wird so nicht funktionieren, kann das aber nicht belegen. Falls du eine Sicherung von /var/log/apt/history.log hast, dann sollte sich daraus der Paketstand rekonstruieren lassen, aber das wird wahrscheinlich Einiges an Aufwand bedeuten.
Für einfacher hielte ich es, wenn du die zu installierenden Pakete "freihändig" zusammenstellst. $HOME/.config (und parallele Konfigurationsverzeichnisse) aus deiner Sicherung kann dafür als Spickzettel dienen.

Wenn du 19. machst, solltest du dir 10. eigentlich sparen können.

21. sollte unnötig bis schädlich sein. Du hast einen Bind-Mount von /var deines Host-Systems. Mehr braucht das neue System im chroot nicht, und der Rest wird beim ersten echten Boot ohnehin ergänzt. Wenn du hingegen im /var des chroot herumfuhrwerkst, während der Bind-Mount besteht, kommt das jenseits des chroots nicht im neuen System an und du fummelst damit auch am Host-System rum, was zu "lustigen" (aber vermutlich nicht tragischen) Effekten führen kann. Vermutlicher Worst Case: Zufällige Programme des Hosts verhalten sich in dieser Session abnormal und der Shutdown funktioniert nicht sauber.

Die ganzen Hilfskopieraktionen über /tmp kannst du dir vermutlich sparen. Vom Host aus kannst du direkt aus der Sicherung in das chroot kopieren.

[Christoph Franzen]

Danke, hikaru, für Deine ausführliche Antwort.

Als Grundlage für die Paketliste nehme ich die Ausgabe von apt-mark showmanual des alten Systems, die ich aber händisch bearbeite (Libs fliegen raus, Pakete mit Versionsnummern im Namen ändern sich, wine ist jedes mal anders).

Scheint interessant, aber die bekäme ich ja auch nur über die Krücke, dem Apt meine alte als aktuelle Paketdatenbank „vorzugaukeln“, ersetzt also meinen Schritt 14, nicht aber 13 & 15–18.

Zu deiner Liste, die im Wesentlichen sinnvoll aussieht:
10.: Nicht vergessen, ein root-Passwort zu vergeben! Sonst drehst du eine Ehrenrunde im chroot.

Sehr guter Hinweis, das macht mein Skript nämlich nicht, weil es davon ausgeht, daß root schon vollständig da ist.

Ich vermute, 13. & 14. wird so nicht funktionieren, kann das aber nicht belegen.

Woher kommt denn die Vermutung? Meines Erachtens sollte alles notwendige unterhalb von /var/lib/ sein.

Falls du eine Sicherung von /var/log/apt/history.log hast,

Ja, habe ich.

dann sollte sich daraus der Paketstand rekonstruieren lassen, aber das wird wahrscheinlich Einiges an Aufwand bedeuten.
Für einfacher hielte ich es, wenn du die zu installierenden Pakete "freihändig" zusammenstellst. $HOME/.config (und parallele Konfigurationsverzeichnisse) aus deiner Sicherung kann dafür als Spickzettel dienen.

Ich denke, ich probiere es einfach mal mit einem der halb-automatischen Verfahren, von Hand nacharbeiten kann man immer noch oder wenn das ganz schlimm fehlschlägt, nochmal von vorne.

Wenn du 19. machst, solltest du dir 10. eigentlich sparen können.

Grund für doppelt: Es gibt hier „normale“ IDs noch aus der Zeit, als Systwem-IDs noch nicht bis 999 gingen. Die fingen damals zwar erst bei 500 an, ich will aber sichergehen, daß sich auch unter ungünstigen Umständen kein Paket eine von den belegten krallt. Der 1. Aufruf fragt nach den ganzen Paßwörtern und legt Benutzer und deren „private“ Gruppen an. Sekundäre Gruppen werden hinzugefügt, soweit vorehanden. Beim frühen Aufruf sind vielleicht noch nicht alle da. Das Skript macht keine selbst, die einem Paket „gehören“ könnten, damit dessen Installationsroutine nicht fehlschlägt, weil es nicht damit rechnet, daß die Gruppe vor der „Erstinstallation“ schon da ist.

21. sollte unnötig bis schädlich sein. Du hast einen Bind-Mount von /var deines Host-Systems. Mehr braucht das neue System im chroot nicht, und der Rest wird beim ersten echten Boot ohnehin ergänzt. Wenn du hingegen im /var des chroot herumfuhrwerkst, während der Bind-Mount besteht, kommt das jenseits des chroots nicht im neuen System an und du fummelst damit auch am Host-System rum, was zu "lustigen" (aber vermutlich nicht tragischen) Effekten führen kann. Vermutlicher Worst Case: Zufällige Programme des Hosts verhalten sich in dieser Session abnormal und der Shutdown funktioniert nicht sauber.

Das sieht mir jetzt nach einem Mißverständnis aus, den Bind-Mount wollte ich sofort nach der Erzeugung der Paketliste wieder aufheben (Schritte 13–15):

• mount -o bind von der Sicherheitskopie in /tmp über das neue, minimalistische /var. (Annahme: dpkg/apt/dselect „glauben“ nunmehr, das System wäre im alten Paket-Zustand, den ich wiederherstellen möchte.)
• dpkg --get-selections > /tmp/Paketliste.txt
• umount /var

Beim „Mitnehmen“ dachte ich an Dinge wie Crontabs.

Die ganzen Hilfskopieraktionen über /tmp kannst du dir vermutlich sparen. Vom Host aus kannst du direkt aus der Sicherung in das chroot kopieren.

Mache ich, weil da ein GRML von USB/RAM läuft und die extern etwas „wackelig“ an USB hängen, eine der Kopien (vom anderen Standort, wo die alte Platte des Gerätes in einem Router steckt) ist heute Abend nach >22h Kopierzeit endlich per scp über ADSL eingetroffen. Leider hatte ich darauf Platz gespart, war also kein vollständiger Verzeichnisbaum mehr. Angekommen bin ich jetzt bei Schritt 7; der unkritische Teil ist also fast vorüber.

[Christoph Franzen]

Als Grundlage für die Paketliste nehme ich die Ausgabe von apt-mark showmanual des alten Systems, die ich aber händisch bearbeite (Libs fliegen raus, Pakete mit Versionsnummern im Namen ändern sich, wine ist jedes mal anders).

Scheint interessant, aber die bekäme ich ja auch nur über die Krücke, dem Apt meine alte als aktuelle Paketdatenbank „vorzugaukeln“, ersetzt also meinen Schritt 14, nicht aber 13 & 15–18.

Ich vermute, 13. & 14. wird so nicht funktionieren, kann das aber nicht belegen.

Woher kommt denn die Vermutung? Meines Erachtens sollte alles notwendige unterhalb von /var/lib/ sein.den Bind-Mount wollte ich sofort nach der Erzeugung der Paketliste wieder aufheben (Schritte 13–15):

• mount -o bind von der Sicherheitskopie in /tmp über das neue, minimalistische /var. (Annahme: dpkg/apt/dselect „glauben“ nunmehr, das System wäre im alten Paket-Zustand, den ich wiederherstellen möchte.)
• dpkg --get-selections > /tmp/Paketliste.txt
• umount /var

Das HAT funktioniert:

1. mount -o bind /tmp/AYL-0.VAR.tmp /var
2. dpkg --get-selections > /tmp/Paketliste.txt
3. apt-mark showmanual >tmp/Paketliste.manuell.txt
4. umount /var

Ach ja - auch deswegen wollte ich die Kopien innerhalb vom Chroot haben: sonst hätte ich das wieder von draußen drüberhängen müssen. Schiefgegangen war es zunächst, weil meine Sicherheitskopie keine leeren Ordner enthielt, was sich durch Erzeugen des angemeckerten /var/lib/dpkg/updates beheben ließ. Die Idee ist nun, Apt die nochmal von Hand überarbeiteten Paketlisten zum Installieren vorzuwerfen, nachdem das „drübergehängte“ alte /var wieder weg ist und das aktuelle daher den tatsächlichen Stand nach dem debootstrap widerspiegelt.

[hikaru]

Ich vermute, 13. & 14. wird so nicht funktionieren, kann das aber nicht belegen.

Woher kommt denn die Vermutung? Meines Erachtens sollte alles notwendige unterhalb von /var/lib/ sein.

Das dürfte Unkenntnis meinerseits sein. Insofern:

Das HAT funktioniert:

1. mount -o bind /tmp/AYL-0.VAR.tmp /var
2. dpkg --get-selections > /tmp/Paketliste.txt
3. apt-mark showmanual >tmp/Paketliste.manuell.txt
4. umount /var

Danke für die Rückmeldung! Mich würde wirklich interessieren, warum das funktioniert hat. Weißt du, wo hier tatsächlich die Information über die installierten Pakete liegt?

Das sieht mir jetzt nach einem Mißverständnis aus, den Bind-Mount wollte ich sofort nach der Erzeugung der Paketliste wieder aufheben (Schritte 13–15):

Ja, das war ein Missverständnis. Mir war nicht ganz klar, welche deiner Aussagen sich auf das chroot, und welche sich auf den Host bezogen.

[Christoph Franzen]

Es installiert nunmehr stundenlang vor sich hin und stellt nur dann und wann doofe Fragen. Ich dokumentiere hier mal, wie das so läuft, damit andere mit ähnlichem Problem die Fallstricke vermeiden können, denen ich begegne. Die Reihenfolge habe ich ein wenig abgeändert und die Dinge, wo ich mir nicht sicher war, waren etwas „unausführlich“ in meiner Liste dargestellt, da bin ich momentan teilweise weiter. Gleichwohl bitte ich um Kommentare, sofern wem was einfällt, das hilfrecih sein könnte.

Aufgetretene Probleme & angewandte Vorsichtsmaßnahmen & hilfreiche Erkenntnisse:

1. Benutzer-Informationen
2. /etc/apt/sources.list(.d)
3. debootstrap ↔ netinstall

1. Beim Kopieren von „/home“ über das Netzwerk mit „scp -pr $QUELLE $ZIEL“ hätten eigentlich die Benutzer-Informationen erhalten bleiben sollen, also wem welche Dateien gehören. $QUELLE ist hier ein Router, der naturgemäß nur Systembenutzer hat; auf dessen Dateisystem ist dennoch alles richtig, da werden von „ls“ und dergleichen halt Zahlen statt Namen angezeigt. „$ZIEL“ ist ein GRML-Rettungs-USB-System, das neben dem Benutzer „grml“ (ID 1000) auch nur System-„Benutzer“ hat. Zu spät bemerkt hatte ich, daß nach der Kopier-Aktion alles „root:root“ gehörte. Warum das so ist, ist mir derzeit ein Rätsel, aber es half:

   Code: Alles auswählen

   cd /home ; for NAME in * ; do chown -hR $NAME: $NAME ; done

   Mit den USB-Platten-Kopien hatte ich das gleiche Problem, hier wohl darauf zurückzuführen, daß „große“ externe Platten gerne mit NTFS-Dateisystem ausgeliefert werden, was ich wegen des Windows meines DAU-Bruders nicht geändert habe, stattdessen für NTFS-3G eine .NTFS-3G/UserMapping gebastelt, weil NTFS im Prinzip POSIX-kompatibel ist. Die „Übersetzung“ funktioniert aber über Linux-Namen und Windows-SIDs, blöd, wenn das GRML die Namen nicht kennt. Was es deswegen nicht zuordnen kann, gehört sicherheitshalber „root“.
2. Zu den Paketquellen ist anzumerken, daß debootstrap nur die Haupt-URL des Spiegel-Servers und dann halt sowas wie „jessie main“ hernimmt; was da gegebenenfalls noch fehlt, muß man nachher in der sources.list angeben und in einem weiteren Schritt nachinstallieren. In meinem Fall haben die Log-Dateien ergeben, daß der Rechner ursprünglich als „jessie“ aufgesetzt worden und inzwischen so ungefähr bei „bullseye“ „angekommen“ war. Da ist mir der Gedanke gekommen, daß wahrscheinlich in der Paketliste „Altlasten“ stehen und noch installiert waren, die es in „bullseye“ womöglich nicht mehr gibt. Also nimmt man nicht letzteres für debootstrap, sondern den Anfang, „jessie“. Wenn man danach schrittweise aktualisiert, hat das den Vorteil, daß es keine Versionskonflikte gibt; denn solche „Altlasten“ werden erst dann zwangs-weggemacht, wenn man was dazu inkompatibles installieren will – fängt man indes gleich mit „bullseye“ an, ist es sehr wahrscheinlich, daß diese „Altlasten“ von vorneherein nicht mehr installierbar sind.
3. debootstrap hat meines Erachtens in einem Fall wie meinem einen Vorteil gegenüber einer Normal-Installation: /home bleibt komplett leer und es wird kein Standard-Erstbenutzer mit ID 1000 erzeugt. Man kann also – das habe ich gemacht – das Einspielen eines sicherheitskopierten /home „zeitlich vorziehen“. Zusammen mit den Dateien passwd, shadow, group, gshadow unter /etc sind dann schonmal alle Benutzer-Informationen vorhanden, ohne daß es Konflikte geben könnte, weil der bei einer Normal-Installation angelegte Benutzer womöglich nicht ganz gleich zu dem „ursprünglichen“ war.

[Christoph Franzen]

Mich würde wirklich interessieren, warum das funktioniert hat. Weißt du, wo hier tatsächlich die Information über die installierten Pakete liegt

/var/lib/dpkg, /var/lib/apt, var/lib/aptitude und dergleichen mehr: alle „Paketverwaltungshelfer“ haben da ihr Verzeichnis, wo alles drin ist, was die brauchen. Ob das Dateisystem mit den dort eingetragenen Informationen übereinstimmt, wird nicht überprüft, wenn man nur einfache Abfragen macht. Man kann also folgendermaßen vorgehen: das neue, minimalistische /var/lib sozusagen „wegschieben“ und durch das ursprüngliche ersetzen, auch wenn die eigentlichen Dateien alle fehlen. Hauptsache, man hat die „Datenbank“ an dem Ort, wo sie erwartet wird. Man kann es auch mit „mv“ machen, aber seit Verzeichnisse, in die man was per mount einhängen will, nicht mehr leer zu sein brauchen und es „-o bind“ gibt, kann man es einfach „drüberblenden“. Sobald man die Infornationen ausgelesen hat, macht man es rückgängig und die Programme greifen wieder auf den wahren „Paketzustand“ zu. Die extrahierten Listen kann man dann verwenden, um den gewünschten Zustand wiederherzustellen.

[hikaru]

In /var/lib/dpkg/status und in /var/lib/apt/extended_states gibt es Paketlisten, die man zur Installation heranziehen könnte.
Letztere hat sogar ein Feld "Auto-Installed:", das aber bei allen Paketen auf "1" steht. Die Information über automatisch und manuell installierte Pakete kriegt man so leider nicht.