Spinnt "mein" tar oder ist Komplettsicherung mit tar unmöglich?

[LX-Ben]

1. SuSE9.1-Prof - Produktivpartition ist auf hda10

2. Gestartet ist Testsystem auf hda11

3. konsole - init 1 - 'mount -t auto /dev/hda10 /mnt/hda10' und 'mount -t auto /dev/hda12 /mmnt/hda12'

4. cd /mnt/hda10
Sonne:/mnt/hda10 # tar -cz * -f /mnt/hda12/backup_0906.tgz
#Syntax absichtlich lang/sprechend

5. Nicht gesichert werden konnten laut Erroranzeige Bildschirm diese insgesamt 83 Dateien:

tar: Socket tmp/.ICE-unix/2777 ignoriert
... weitere 62 tmp/...-Dateien bis
tar: Socket tmp/gpg-LHNUXA/S.gpg-agent ignoriert

tar: Socket var/run/.resmgr_socket ignoriert
tar: Socket var/spool/postfix/public/cleanup ignoriert
... weitere 21 var/spool/...-Dateien bis
tar: Socket var/spool/postfix/private/anvil ignoriert

Da diese 83 ungesicherten Files ausschließlich aus ../tmp und ../var/spool herrühren und auch bei mehrmaligem tar-gzip auftraten, war ich zunächst nicht besonders irritiert. Merkwürdig ist aber, dass ALLE diese Dateien an der linkesten Stelle ein 's' als Attributkennzeichen besitzen, zB.
srw-rw-rw- 1 postfix postfix 0 2004-06-09 18:44 /mnt/hda10/var/spool/postfix/private/anvil

ANMERKUNG: Der -v(erbose)-Schalter ist also nicht immer von Vorteil, wahrscheinlich wären die Fehlermeldungen bei 110.000 Bildschirmanzeigezeilen untergegangen, falls nicht '.. 2> errorlog.txt' benutzt worden wäre.

6. Sonne:/mnt/hda10 # rm -rf /mnt/hda10
Sonne:/mnt/hda10 #tar -xzp * -f /mnt/hda12/backup_0906.tgz

7. Reboot - danach bleibt der PC mit schwarzem Bildschirm und Anzeige 'grub' einfach stehen – irgendetwas scheint also beim Sichern/Restaurieren verloren gegangen zu sein

8. Rückweg: Mit Win(Caldera-DOS)-DriveImage2002 auf CDRWs gezogene hda10-Partitionssicherungs-CDs gebootet und restauriert. Platten-reboot und grub-Auswahl hda10(ProduktivS.) / hda11(Testsystem) funktionieren wieder problemlos.

Frage:Habe ich bei der Sicherungssyntax (s.Ziffer 4) etwas übersehen oder ist tar für Vollsicherungen tatsächlich unbrauchbar? Wäre schon merkwürdig, da nach 'init 1' selbst mit 'cp -a * ..' eine restaurierbare Vollsicherung erzeugt werden kann.

[HackThor]

Ich habe meine Rechner schon mehrfach plattentechnisch komplett umgezogen (auf ne größere Festplatte, oder auf die gleiche mit veränderter Partitionierung). Und das ging alles mit "tar", völlig schmerzfrei. Nach dem Installieren des Bootloaders war kein Unterschied in der Funktion festzustellen, die Kisten liefen so wie vorher.

Die "s"-Dateien sind "sockets", also Verbindungen zwischen Programmen. Diese werden eigentlich beim Programmstart neu angelegt und müssen nicht extra gesichert werden. Eine "manuelle" Möglichkeit des Erstellens gibt es für Sockets meines Wissens nicht, für alles andere ist ja "mknod" da.

Bei mir ignoriert der "tar" die Dateien auch (Mandrake 9.2). Anscheinend ist es ihm nicht möglich diese Sorte Dateien zu sichern. Aber sie werden ja eh nicht in der Sicherung gebraucht (s.o.)

ciao

Michael

EDIT: Schreibst Du tatsächlich "tar -xzp * -f <datei>"? Das geht so nicht, der Stern muß da weg. Eventuell wird dadurch ja nichts zurückgesichert....

[LX-Ben]

Vielen Dank für die kompetenten Antworten - da werde ich heute abend was zu testen haben.

Schreibst Du tatsächlich "tar -xzp * -f <datei>"? Das geht so nicht, der Stern muß da weg. Eventuell wird dadurch ja nichts zurückgesichert..
1. "nichts zurückgesichert.." ist zu viel gesagt, es geht schon eine Menge herüber, aber offensichtlich nicht alles.
2. Falls die Angabe * sich als verkehrt erweist, ist die 'tar --help' nicht besonders aussagefähig, ebenso wenig wie die Bücher 'Kofler' und 'Linux in a nutshell!'
Zusatzfrage: Muss dann nicht auch bei 'Sonne:/mnt/hda10 # tar -cz * -f /mnt/hda12/backup_0906.tgz' der * weggelassen werden?

Mein Rückkehr-Testscenario für heute abend ist allerdings einfacher (ohne DriveImage2002) - ich habe nach 'init 1' mit 'cp -a * ..' eine identische/überprüfte Kopie von hda10 auf hda12 erzeugt, die ich simpel zurück kopieren kann.

[LX-Ben]

ZWISCHENINFORMATION: Mein Schreibtisch ist voller Zettel, und getestet habe ich bis zum frühen morgen (jede tar-Syntaxvariante dauert bei 3 GB/110.000 Quelldateien ca. 25 Minuten mit der Kette tar -cz .., rm -rf .., tar -xz ..). Die Ergebnisfeststellungen sind zwar noch nicht ganz eindeutig, aber das Dunkel beginnt sich zu lichten.

-die von mir genutzte tar-Syntax zum Erstellen incl. Angabe mit '*' an der angegebenen Stelle funktioniert korrekt; wird * weggelassen, erfolgt Fehlermeldung "tar: Cowardly refusing to create an empty archive".

-auch die von mir genutzte tar-Syntax zum Restaurieren incl. Angabe mit '*' an der angegebenen Stelle funktioniert korrekt; wird '*' an anderer Stelle platziert oder weggelassen, führt das zu folgenden Fehlermeldungen:
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers..
und nach ca. 10 Sekunden Abbruch.

-Um ganz sicher zu gehen, hier nicht auf eine SuSE9.1-Eigenwilligkeit hereinzufallen, wurde die zweite Testreihe mit c't-knoppix-3.4-BootCD und tar Version 1.13.25 durchgeführt. Ergebnis war das gleiche - PC bleibt mit schwarzem Bildschirm und Anzeige GRUB stehen.

-Die Rücksicherung der hda10-Dateienkopien auf hda12 mit 'cp -a * ..' nach hda10 führt dagegen zu einem bootenden SuSE9.1! Als Test steht noch aus, die hda10-Dateienkopien auf hda12 per diff mit dem tar-Restaurieren nach hda10 zu vergleichen: Da df -m identische Mengen für hda10 und hda12 anzeigt (*.tgz vorher entfernt), vermute ich mal stark, dass KEINE Differenzen vorhanden sind.

-Angeregt durch die Hinweise auf einen 'Partitionstabellen-Bug' - siehe nachstehender Exkurs - habe ich als letztes die SuSE9.1-CD1 gebootet - Installation - vorhandene Installation starten - hda10 - yast2 - System - 'grub neu in den MBR schreiben ..' durchgeführt, und anschließend konnten beide SuSE9.1-Linuxpartitionen hda10 bzw. hda11 problemlos wieder per Festplatten-Boot gestartet werden.

-Da tar eine reine DateienSicherung ist, dürfte eigentlich kein sachlicher Zusammenhang zur evtl. Beschädigung der Partitionstabelle /MBR durch tar-Restaurieren bestehen, doch die Tatsachen aus meinen Tests 'sprechen bisher eine andere Sprache'. Merkwürdig ist auch, dass dieser Bug nicht alle PC-Systeme betrifft: Während nach dem SuSE9.1-Update mein XP nicht mehr startbar war, gab es bei einem Bekannten überhaupt keine Probleme.

Meine kurzfristig folgenden abschließenden Tests werden zeigen, ob diese Mutmaßungen zutreffen. Auf jeden Fall ist bei Nutzung von tar als Vollsicherung mit den neuesten Distributionen erhöhte Aufmerksamkeit angesagt incl. Konzept für das Wieder-Herstellen des MBR!
--------------

Exkurs Partitionstabellen-Bug

es war der bekannte Bug, dass nach der SuSE-Installation die Partitionstabelle von Win nicht mehr richtig gelesen werden kann --> http://www.heise.de/newsticker/meldung/47847
aus: http://www.linuxforen.de/forums/showthread.php?p=855736&highlight=partitionstabelle#post855736

Linux-Distributionen können Partitionstabelle beschädigen

Offenbar ist nicht nur Fedora Core 2 von dem gemeldeten Problem betroffen, dass die Installation die Partitionstabelle so beschädigen kann, dass Windows nicht mehr startet. Auch Suse 9.1 und Mandrakelinux 10 scheinen mit dem Problem zu kämpfen.

Nach Auskunft der Distributoren soll ein Bug im Zusammenspiel des Kernel 2.6 mit dem Partitionierwerkzeug Parted dafür sorgen, dass ein fehlerhafter Eintrag für die Anzahl der Köpfe in der Partitionstabelle zu einer fehlerhaften CHS-Adressierung (Cylinder, Head, Sector) führt. Als Folge verweigert Windows dann den Start; auch andere Betriebssysteme, die über den Chainloader-Mechanismus im Bootmanager Grub gestartet werden, können betroffen sein.

Das Problem lässt sich jedoch vergleichweise einfach beheben, indem man die Zahl der Festplattenköpfe mit dem Programm sfdisk auf einen sinnvollen Wert (normalerweise 255) setzt. Dazu startet man das installierte Linux-System oder ein Rettungssystem wie Knoppix. Die Vorgehensweise beschreibt ein Posting auf der Fedora-Developer-Mailingliste [Link bei Heise auf http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html]. Hier finden sich auch Hinweise, wie man bei der Installation verhindern kann, dass das Problem überhaupt auftritt. (odi/c't)

[LX-Ben]

Aus Zeitgründen muss ich jetzt ziemlich gewaltsam zum Schluss kommen, um das Problem endlich abzuhaken. Und die Schlussfolgerungen werde ich vorziehen (den Nachweis erst am Ende erbringen), da sie wichtig für alle Linux-Nutzer mit grub-Bootmanager im MBR sein dürften.

1. Entgegen landläufiger Meinung gibt es 'nicht nur einen grub im MBR', sondern offenbar einen init-UR-grub, der sich durch Systemstatus-Speicherungen verändern kann! Unter OS/2 gab es das übrigens auch schon mal.

2. Zwischen 'grub im MBR' und den gespeicherten Daten gibt es Abhängigkeiten, dh. wenn bestimmte Dateien nicht mitgesichert werden, kann es in besonderen Fehlerfällen dazu kommen, dass auch nach Wieder-Herstellen aus einer Datensicherung per tar, dh. ohne die genannten socket-Dateien, grub (zunächst) nicht mehr startbar ist!

3. Obwohl dieser Fehlerfall unter SuSE9.1 aufgetreten ist, dürfte er auf alle vergleichbaren Desktop-Distributionen übertragbar sein. Ziffer 2 ist allerdings nicht ganz so kritisch, wie es auf den ersten Blick aussieht - wird ein UR-grub in den MBR zurück geschrieben, ist der Fehler damit behoben: Bei SuSE9.1 wie beschrieben über Boot-CD1 - Installation - vorhandene Installation starten - yast - System - Bootloader grub konfigurieren - Code neu in den MBR schreiben.

4. Die Abweichungen zwischen UR-grub im MBR betrugen mal drei Bytes, manchmal zwei Bytes, so dass ein Zusammenhang mit dem berüchtigten Fehler 'Kernel 2.6 und parted' (ein falsches Byte, nämlich die Anzahl der Schreiblese-Köpfe, was WinXP am Starten hindert) ziemlich ausgeschlossen werden kann.

FAZIT: Wer also tar zur Vollsicherung benutzt, muss mit seiner Distribution im MBR-grub-Loader-Fehlerfall (schwarzer Bildschirm beim Starten und 'GRUB-Hänger') auch in der Lage sein, den grub neu in den MBR schreiben zu können!

Details
1. Wenn im Fehlerfall der grub-Loader mit schwarzem Bildschirm und der Meldung 'GRUB' oder auch 'GRUB GRUB GRUB GRUB GRUB ...' hängenbleibt, ist kein "logischer Zugriff" mehr auf die Festplatte möglich, sondern nur ein physikalischer Zugriff mit Direktadressierung von Track, Head und Sektor. Der MBR, in den sich grub neben dem Festplatten-Urlader und der Partionierung schreibt sowie den Festplattenkenndaten wie Anzahl Tracks, Heads und Sektoren, befindet sich in Track 0, Head 0 und Sektor 1, dh. dem allerersten Sektor, so dass der Zugriff ziemlich einfach zu adressieren war. Nach einem grub-Hänger habe ich mal per Disk Win98(=DOS 7.1) gebootet und meinen (in C und Assembler geschriebenen) Diskmonitor gestartet - und siehe nachfolgender Bildschirmabdruck - ES GAB ABWEICHUNGEN!

Selbstüberprüfung von A:\PDISKMON.EXE: erfolgreich.
[ DRIVE C: - HEAD: 0 TRACK: 0 SECTOR: 1 _Status INT 13h - 00h. 1 ]
COMPARE DRIVE C: - HEAD: 0 TRACK: 0 SECTOR: 1 mit Datei C0_0.1S:

An Byteadresse 45h = 16h (DRIVE C) D6h (Datei C0_0.1S)
An Byteadresse 46h = CFh (DRIVE C) 5Bh (Datei C0_0.1S)
An Byteadresse 47h = 01h (DRIVE C) 02h (Datei C0_0.1S)
- 3 UNTERSCHIED(E) gefunden!!! - PDISKMON endet mit ERRORLEVEL 1 !
Zurückschreiben der Daten mit `PDISKMON C: 0 0 1 C0_0.1S' möglich!!!
Bitte eine Taste drücken.Meine Bildschirmausgabe 'DRIVE C' ist übrigens falsch, bei physikalischer Adressierung wird die erste reale Festplatte mit hex80 (dh. vergleichbar mit hda, die zweite mit hex81 usw.) angesprochen, aber die Kernaussage zu den Abweichungen ist maßgebend (grub im MBR ist also nicht gleich grub :) ).

2. Die Abhängigkeiten zwischen dem grub-Speicherungszustand im MBR und den restaurierten Dateien habe ich wie folgt ermittelt:

a) tar sichert NICHT die SOCKET-Dateien aus /tmp und /var; im Fehlerfall führt das alleinige tar-Restaurieren zu einem dauerhaften GRUB-Hänger!
b) Werden nach tar-Restaurierung zusätzlich per cp auch die (vorher gesicherten) Verzeichnisse /tmp und /var zurückgeschrieben, so gibt es KEINEN GRUB-Hänger!
c) Wird nur /var zusätzlich zurückgeschrieben, so gibt es ebenfalls KEINEN GRUB-Hänger!
# Gegen eine solche separate /var-Sicherung spricht allerdings, dass sie zur Konservierung der Rechte nur dateiweise auf ein entsprechendes Linux-Dateisystem geschrieben werden kann.
d) In weiteren Tests zur Einengung des Fehlerfalls konnte ich ermitteln, dass bereits nur das zusätzliche Zurückkopieren des Unterverzeichnisses /var/run genügt, damit keine KEINE GRUB-Hänger mehr auftreten!
e) An dieser Stelle der Tests habe ich dann abgebrochen, da auch in /var/run noch zu viele SOCKETS-Dateien einzeln mit dem kompletten Test-Szenario auszutesten gewesen wären - und das können je nach PC-Nutzung auch ganz unterschiedliche sein.

Ein erfahrener Linux-Nutzer 'gab mir eine Erklärungs-Möglichkeit': In /var/run würden sich in den SOCKET-Dateien die pid-Nummern der beim PC-Neustart wieder aufzunehmenden Prozesse finden, und tatsächlich fanden sich in derartigen Dateien lediglich vierstellige Ziffern zB. 2562. Es könnte also gut sein, dass im grub-MBR abgespeichert wird, welche Prozesse beim Booten wieder aufzunehmen sind.

Tatsächlich gibt es bei meinem SuSE9.1-Boot eine Besonderheit, nämlich die Meldung 'resource manager ......... failed' (also Prozess nicht abgeschlossen). Und in /var/run befindet sich auch tatsächlich eine Datei resmgr.pid, die eine vierstellige Ziffer beinhaltet - also würde die Erklärung logisch zusammenpassen. Von praktischer Bedeutung ist diese Erklärung allerdings kaum, da zu kompliziert zu lösen und jeder Fehlerfall anders liegen kann. Deshalb nochmal:

FAZIT: Wer also tar zur Vollsicherung benutzt, muss mit seiner Distribution im MBR-grub-Loader-Fehlerfall (schwarzer Bildschirm beim Starten und 'GRUB-Hänger') auch in der Lage sein, den grub neu in den MBR schreiben zu können!

Also nicht resignieren, mit genügender Analyse gibt es bei Linux scheint's fast immer Lösungsmöglichkeiten. Ansonsten klappt eine Vollsicherung/Restaurieren mit tar unter 'init 1 bzw. 2' perfekt.

[Schärple]

Hey LX-Ben, suchst Du n' Job? :D

[LX-Ben]

Hey LX-Ben, suchst Du n' Job? :DJa könnte man meinen - aber ich liebe es, den Dingen auf den Grund zu gehen, und meist ist man hinterher wieder schlauer. In diesem Fall ging es mir allerdings nur darum, mit 'init 1 - tar -cz ..' in knapp 12 Minuten mal schnell eine Voll-Zwischensicherung zu ziehen und nicht jedesmal Win98+DriveImage2002 anzuwerfen. Und das gleichschnelle 'cp -a * ..' verbraucht 3GB Plattenplatz statt 1,07GB mit tar.

[Blackhawk]

wobei nicht tar den Platz spart, sondern der gzip, den du mit tar -z aufrufst...