(gelöst) Systemsicherung

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
guennid

(gelöst) Systemsicherung

Beitrag von guennid » 18.12.2017 09:38:17

Ich will ein Jessie-System, das als Router fungiert, sichern. Einen Ausbau des Datenträgers will ich nicht (selbst wenn das bei einem eeepc 4G möglich wäre, was es meiner Kenntnis nach nicht ist). Nach der Sicherung soll ein Upgrade des Jessie-Systems auf stretch erfolgen, um, falls erfolgreich, das upgegradete Routersystem dann letztlich auf eine andere Maschine zu transferieren. Der laufende Eigenbaukern wird darauf nicht mehr funktioniern, habe ich schon getestet. Aber erstmal geht's um ein brauchbares Systembackup. Bei der Sicherung will ich so vorgehen:

Die Sicherungsplatte partitioniere ich ich vorab auf irgendeinem System mit dem genau gleichen Partitionsschema wie dem des laufenden Routersysems (ist nicht viel: swap,extended und / unter sda5).

Dann:

Code: Alles auswählen

# Eine beliebiges Rettungssystem/Live-System von einem USB-Stick/CD-Rom booten.
#
# Anmelden als root
cd /mnt
mkdir alt
mkdir neu
# altes und neue Root-FS mounten
mount /dev/sda5 /mnt/alt
mount /dev/sdb5 /mnt/neu
# alt nach neu kopieren, Rechte & Hardlinks in Takt halten
rsync -az -H --delete --numeric-ids /mnt/alt/ /mnt/neu/
Ist das so möglich und ist es so ausreichend?

Sollte ich die Sicherung wieder zurückspielen müssen, müsste ich:
- Zieldatenträger ( also den, der sich nach wie vor in der Maschine befindet) sicherheitshalber erneut partitonieren (mit altem Schema) oder genügte ein Löschen aller Dateien unter sda5?
- dann wiederholt sich das Spielchen von oben und danach, (voausgesetzt /mnt/neu ist das "neue"/alte System):

Code: Alles auswählen

mount --bind /proc /mnt/neu/proc
mount --bind /sys /mnt/neu/sys
mount --bind /dev /mnt/neu/dev

- chrooten und Bootloader (lilo) neu aktivieren

Alles in code-tags hier abgeguckt: (1)
(1) viewtopic.php?f=12&t=145507&p=957088#p957088
Zuletzt geändert von guennid am 18.12.2017 18:59:59, insgesamt 1-mal geändert.

Benutzeravatar
smutbert
Moderator
Beiträge: 8331
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Systemsicherung

Beitrag von smutbert » 18.12.2017 12:23:48

Sieht alles richtig aus. Die abschließenden / in den Pfadangaben haben bei rsync aber nicht immer auf den ersten Blick ersichtliche Folgen, die Kompression (-z) bringt beim lokalen Kopieren nix sondern nur über das Netzwerk und dasselbe gilt für die numeric-ids, mein rsync Befehl sähe also so aus

Code: Alles auswählen

rsync -a -H --delete /mnt/alt/ /mnt/neu
genauso gut sollte aber ein

Code: Alles auswählen

cp -a /mnt/alt/* /mnt/neu/
funktionieren (vorausgesetzt es gibt keine versteckten Dateien/Verzeichnisse in / was aber ohnehin unüblich und schlecht wäre).

Neu Partitionieren ist keinesfalls notwendig, neu formatieren ist auch nicht notwendig (löschen genügt), aber keine schlechte Idee. Nur musst du dann die UUIDs in der fstab und gegebenenfalls weiteren Konfigurationsdateien anpassen.

guennid

Re: Systemsicherung

Beitrag von guennid » 18.12.2017 12:38:59

Danke sehr!

Beruhigt mich, wenn du das sagst.

Mal schauen, wie's läuft.

Grüße, Günther

guennid

Re: Systemsicherung

Beitrag von guennid » 18.12.2017 18:02:08

Ich hab's dann doch etwas anders gemacht und eine dritte Platte als Zwischenlager benutzt. Dadurch entfiel das Risiko, des Zurückspielen-Müssens.

die Kopie vom Zwischenlager auf die neue Maschine, war zunächst fehlerhaft/unvollständig. Fiel mir erst auf, als die Kernelinstallation im chroot des Zielsystems nicht funktionieren wollte.

Hätte man vielleicht vermeiden können mit 'ner md5Summe für die Kopie. Aber wie erstellt man die von einem kompletten System?

Benutzeravatar
smutbert
Moderator
Beiträge: 8331
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: (gelöst) Systemsicherung

Beitrag von smutbert » 18.12.2017 21:32:09

Wenn es mit rechten Dingen zugeht und die Datenmengen nicht exorbitant groß sind, ist es schon recht unwahrscheinlich, dass beim Kopieren Fehler auftreten ohne, dass die sich in entsprechenden Meldungen (I/O-Fehler, Fehler im Dateisystem,...) niederschlagen.
Trotzdem gibt es mehrere Möglichkeiten das ganze zu überprüfen.

Ein Ansatzpunkt wären Dateisysteme mit Prüfsummen. Wenn zum Beispiel nur dein Sicherungsmedium etwa mit btrfs formatiert wäre, könntest du beim Zurückkopieren einigermaßen sicher sein, dass die gelesenen Daten stimmen (oder es eine Meldung gibt). Wenn alle beteiligten Dateisysteme btrfs wären, könntest du jederzeit einfach überprüfen ob sich die Daten auf dem Speichermedium nicht ungewollt geändert haben.
Aber wie gesagt, aus dieser Richtung sind nur sehr sehr sehr sehr selten Fehler zu erwarten (die sich nicht auch als Hardwarefehler im Log zeigen).

Was das Kopieren selbst angeht, so könnte man den eigentlichen Kopiervorgang mit "cp -a ..." machen und nach dessen Vollendung ein "rsync -c ..." hinterherschicken, das die Daten bei den richtigen Optionen noch einmal mithilfe von Prüfsummen vergleicht.
Mit Debianhashdeep oder anderen Tools kann man ebenfalls Dateien oder Verzeichnisbäume vergleichen (das ist aber mit Stolperfallen verbunden soweit ich mich erinnere).

Wenn du sowieso ein lauffähiges System kopierst, dann kann auch "dpkg --verify" zum Prüfen der von der Paketverwaltung verwalteten Dateien helfen, das wird aber auch bei jeder Konfigurationsdatei anschlagen, die du selbst geändert hast. Mehr oder weniger denselben Zweck erfüllt Debiandebsums.


In den meisten Fällen wird es schon genügen nach dem Kopiervorgang und sicherheitshalber einem darauffolgenden sync, die letzten Zeilen der Ausgabe von dmesg zu überprüfen. Dort würden zum Beispiel USB-Fehler aufscheinen, die nach meiner Erfahrung noch vergleichsweise häufig Ursache von Problemen sind (da würde dann aber auch btrfs oder ein anderes Dateisystem mir Prüfsummen helfen, das eventuell den Lesevorgang wiederholt und so die Fehler ausbügelt oder sie zumindest erkennt, was schon viel wert ist).

guennid

Re: (gelöst) Systemsicherung

Beitrag von guennid » 18.12.2017 22:07:45

Eine Fehlermeldung habe ich keine gesehen. Dateisystem ist ext4. Es fehlten Dateien in /var/lib/dpkg oder das gesamte Verzeichnis dpkg, genauer erinnere ich nicht mehr. Da fiel's mir dann auf, weil dpkg -i nicht mehr funktionierte. Ob das Ganze auch mit dem über ein optisches Laufwerk laufenden live-System (grml 2014) zusammenhängen kann?

Benutzeravatar
smutbert
Moderator
Beiträge: 8331
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: (gelöst) Systemsicherung

Beitrag von smutbert » 18.12.2017 23:28:29

Für fehlende Dateien ohne Fehlermeldung habe ich keine brauchbare Theorie parat und ich wüsste auch nicht, auf welche Art grml etwas damit zu tun haben könnte.

(Ich kann nur sagen, dass ich bei solchen Aktionen nach dem Kopiervorgang sicherheitshalber sync ausführe und die Dateisysteme selbst unmounte. Ich habe den Verdacht, dass unter gewissen Umständen bei Neustarts oder beim Herunterfahren die Datenträger ausgeschaltet werden können, als die Daten fertig geschrieben sind – das ist aber nur eine sehr vage Theorie von mir.)

Antworten