LX-Ben
06.12.05, 16:52
Linux mit Boardmitteln sichern und wiederherstellen, das ist doch was!
Da der Hintergrund sehr ausführlich erläutert wird, damit Anwendungsmotivation und -sicherheit erreicht wird, ist der Bericht in drei überschaubare Teile gegliedert. Datensicherung ist eine Grundfunktion der ordentlichen Datenverarbeitung, oder kennt jemand ein seriöses Rechenzentrum, das nach Desaster mit Stunde NULL anfängt?
Teil1
1. Zwingende Gründe für Datensicherungen und
„tar-gzip macht müde Platten munter“ - Testzeiten
2. Und so geht es - Sichern
Teil2
3. Und so geht es – Prüfen nach Schreiben
4. Und so geht es – (Gesamt-)Sicherung restaurieren
sowie die reine Befehlsliste als 'Kurz-Fahrplan'
Teil3
5. Noch mehr Möglichkeiten – nicht alles auf einmal erforschen
-Nur ein Verzeichnis einer Partition sichern
-Nur ein Unterverzeichnis einer Sicherung wiederherstellen
-Nur eine oder mehrere bestimmte Dateien wiederherstellen
1. Vorbemerkungen
a) Allgemein
„Eigentlich nichts Neues?“ - stimmt. Aber da noch immer viel zu viele vor der Datensicherung zurückschrecken, wird es hier nochmal geschlossen und ausgetestet dargestellt, zumal es wirklich ganz einfach ist. Ohne Datensicherung traut man sich entweder kaum etwas am System zu machen, oder es wird am System gewerkelt bzw. ein Tippfehler aus Übermüdung - und schon ist das Chaos da, das dann in stundenlangen Reparaturversuchen behoben werden soll – dabei ist das 100%-ige System-Wiederherstellen in einer guten halben Stunde erledigt: Es lebt sich ruhiger mit existierender Datensicherung, die natürlich bei noch intaktem System erstellt werden muss! Und nicht nur einmal. Also Datensicherung sofort vormerken! :)
Manchmal passieren 'damages' schneller als einem lieb ist; unlängst startete ich mein Testsystem und landete -ohne dass ich bewusst etwas Wichtiges verändert hatte- nach dem Starten in der root-console. Das 'init 5' für kde-GUI funktionierte zwar, aber es waren keinerlei andere Partitionen mehr gemountet und ähnliche 'Unwuchten', obwohl die /etc/fstab noch voll intakt war: Also nach drei Jahren und zwei Monaten OHNE PROBLEME außer Nacharbeiten zu den halbjährlichen großen SuSE-Updates plötzlich der Schuss aus dem Dunklen. Klar, dass das Restaurieren der letzten Datensicherung in einer guten halben Stunde für mich einfacher war als ggf. stundenlang Fehler zu suchen, und außerdem ist Fehlersuche keine Garantie für den Erfolg.. :D
b) „tar-gzip macht müde Platten munter“
tar – das ist der „GNU Tape Archiver“, ein in der Unix- und Linuxwelt lange bewährtes und sicheres Standardwerkzeug, das heute neben Tapes/Bändern auch für andere Laufwerke eingesetzt werden kann. Aber warum wechseln, wenn ich einmal wöchentlich aus Servicegründen für Bekannte sowieso Win98SE starte und Win-DriveImage 2002 die mit 4GB belegte ext3-Partition problemlos und schnell in einer halben Stunde auf CDRWs sichert?
-Seit dem Update auf SuSE10.0 verweigert DriveImage 2002 die Sicherung der SuSE10.0-Gesamtpartition, wahrscheinlich weil 'der reservierte Systembereich' von 33 auf 129 MB angewachsen ist. Mit Umkopieren unter Linux auf eine freie Partion und dann mit DriveImage 2002 sichern gab es zwar eine Problem-Umgehung, doch weder stilecht noch zeitlich günstig.
-Das Handling mit drei Datensicherungs-CDRWs war mit insgesamt neun Datenträgerwechseln verbunden (dreimal löschen, dreimal schreiben, dreimal prüflesen) und soll durch Umstieg auf eine schnelle usb2.0-Festplatte abgelöst werden. Eine Stückelung auf 650 MB und einzeln auf CDR(W)s brennen geht auch mit nachfolgend beschriebener Linux-tar-Lösung sowie zusätzlichem split-Befehl und späterem cat für das Wieder-Zusammenfügen, jedoch hat man ziemlichen zusätzlichen Zeitbedarf für das exakte Handling: Externe leise usb-80GB-Festplatten kosten nur noch so um die 75 Euro; außerdem fällt einem nach und nach noch viel mehr ein, was man mit Plattenplatz alles anfangen kann.
Im Praxistest stellte sich allerdings heraus, dass die usb-Festplatte nur einen Durchsatz von 45 MB/Min. erreicht (hotplug-automount – auch Win98SE hat keine viel besseren Werte), während die IDE-Festplatte mit 267 MB/Min. die sechsfache Schreibgeschwindigkeit erreicht. Zwar konnte ich den Schreibdurchsatz der usb-Festplatte auf 62 MB verbessern*), aber das ist immer noch 4-fach langsamer als die IDE-Festplatte. Also führte das zu der Idee, das Schreibvolumen und damit den Zeitbedarf durch Komprimieren des 4GB-Datenvolumens zu reduzieren. Das Ergebnis ist beeindruckend
b1) 108 Minuten mit gebootetem SuSE10.0-automount ('cp -a * /zielverzeichnis')
b2) 62 Minuten mit gebootetem SuSE10.0, /dev/sdc5 selbst gemountet **) ('cp -a * /zielverzeichnis')
b3) 31 Minuten mit gebooteter Knoppix-CD/-DVD sowie tar mit gzip-komprimiert! Der Optimierungsversuch mit '-b 128' brachte keinen Zeitgewinn, ebenso wenig wie die Nutzung des Komprimierungs-Algorithmusses bzip2 statt gzip – die Archivgröße schrumpfte zwar von 1551 MB auf 1436 MB, aber der Zeitbedarf wuchs auf 56 Minuten! Alle genannten Zeiten wurden auf einem 0815-PC mit Athlon 2000+ und einer drei Jahre alten IDE-Festplatte ermittelt.
Geduld, die praxisrelevanten Details folgen sofort.
**) dazugehörige Ergänzung der /etc/fstab
...
/dev/sdc5 /mmnt/sdc5 ext3 users,gid=users,umask=0002,utf8=true 0 0
...
und dann meine usb-ext3-Festplatten-Partition /dev/sdc5 selber gemountet mit einem eigenen mount-Verzeichnisnamen, dh. zusätzlich zum automount; async statt sync bringt bei großem Datenvolumen NICHTS, da das cache'n (gepuffertes Schreiben) schnell ausgeschöpft ist.
2. Und so geht es - Sichern
a) Vorlauf
Knoppix-CD/-DVD booten, 'knoppix 1' als Start-Auswahl eingeben.
[Grundsätzlich kann man eine Linux-Partition mit tar auch von einer 'anderen gestarteten Linux-Partition' aus sichern. Aufgrund eigener zweifelhafter Erfahrungen unter SuSE-kde rate ich aber dazu, die GUI zu verlassen, dh. zum Beispiel in der kde-konsole 'su' einzugeben, root-Kennwort eingeben und dann 'init 1', der Rest wie folgt. ACHTUNG: Dass der PC VORHER im Ruhezustand sein muss/Schreibvorgänge beendet sind, muss strikt beachtet werden! Der Restart der kde-Oberfläche ist mit dem Befehl 'init 5' möglich.]
'ls -l /mnt/*' - aha, usb-ext3-Partition ist auch bei Knoppix als /mnt/sdc5 mountbar. Gesichert werden soll das Datenvolumen der Partition /mnt/hda10 [SuSE10.0-Produktionssystem]
'mount -t auto /dev/hda10 /mnt/hda10'
'mount -t auto /dev/sdc5 /mnt/sdc5'
b) Die Sicherung läuft
'cd /mnt/hda10'
'ls -l' und 'pwd' #wo bin ich?
#ok, auf der richtigen Partition. Der Verzeichniswechsel auf die Quellpartition bewirkt außerdem, dass die Archiv-Filenames ohne vorlaufendes '/mnt/hda10' gesichert werden.
Und dann ein schlichtes
'tar czf /mnt/sdc5/hda10_29.11.2005.tar.gz ./ >& ignored.log'
#Huch? – ok, nun die detaillierte Auflösung
czf #create_archiv mit gZip, f=zielFile-Name folgt
# 02.01.2005: Syntax-sprachlicher Patzer dank geronet korrigiert
/mnt/sdc5/hda10_29.11.2005.tar.gz
#Ein sprechender zielFile-Name sollte es schon sein
./
#gesichert wird das aktuelle [Quell-]Verzeichnis mit allen Unterverzeichnissen
>& ignored.log
#das ist wahrscheinlich am schwersten zu akzeptieren, sorgt aber für stressfreies Sichern: tar hat offenbar intern eine Tabelle für Unterverzeichnisse in /tmp und /var, deren temporäre files NICHT gesichert werden (müssen); diese nicht gesicherten files werden zwangsweise am Bildschirm (fprintf) ausgegeben. Mit dieser Syntaxergänzung werden die ignored-filenames nicht in den Bildschirm geschrieben, sondern landen in der Datei ignored.log, die man sich dann mit 'less ignored.log' ansehen kann (bei mir zwei Bildschirmseiten, verlassen mit 'q'uitt).
ODER '>& ignored.log &'
#was denn, noch ein '&'? JA, damit wird dann der GESAMTE JOB vollständig im background/Hintergrund ausgeführt, und durch wiederholtes 'df -m' kann man sich das Anwachsen der Datensicherungsschreibmenge auf dem Ziellaufwerk summarisch ansehen. Oder direkt das Dateiwachstum mit 'ls -l /mnt/sdc5'.
Variationen
- - - - - -
Es gibt eine Fülle von Sicherungs-Varianten zB. das Kommando 'u'pdate für Ergänzungssicherungen, Sichern von Netzwerken usw.: Weitere Informationen überlasse ich lieber praxis-gehärteten Fachleuten*), meine Infos habe ich aus dem 320seitigen! Buch „Datensicherung unter Linux. Grundlagen – Werkzeuge – Konzepte“ von Wolfgang Barth, open source Press entnommen, Preis nach meiner Erinnerung ca. 20 Euro.
*) [quote=Der Autor schreibt zum Beispiel..
Vorsicht bei Access Control Lists
Die hier vorgestellten Programme berücksichtigen allesamt keine erweiterten Zugriffsrechte, so genannte Access Control Lists nach dem POSIX Draft 1003.e. Da Access Control Lists nur dann verwendet werden können, wenn Filesystem und Kernel dies unterstützen (bei Kernel 2.4 sind in der Regel noch Patches erforderlich), und der Administrator sie bei Filesystemen wie ext2/ext3 auch erst explizit einschalten muss, sind Access Control Lists derzeit noch wenig verbreitet. Falls welche vorhanden sind .. (sinngemäß) müssen vorher Zusatztools zur Anwendung kommen..[/quote]
-Kommandos 'czvf' statt 'czf' bewirken, dass durch 'v'=verbose alle 100.000 filenames auf den Bildschirm ausgegeben werden – sinnvoll?
-Kommandos 'uzf' statt 'czf' bewirken, dass durch 'u'=updates nur neue bzw. geänderte files in das vorhandene Archiv geschrieben werden, genauer werden am Ende des Archivs hinzugefügt. Doch ich bevorzuge wöchentliche Gesamtsicherungen mit sechs Sicherungsgerationen sowie einer vierteljährlichen Langzeitsicherung, für eine Workstation mehr als ausreichend. Oder nach vielen Systemänderungen.
GRUNDSÄTZLICH kann das ..tar.gz-Archiv auch auf vfat-Partitionen geschrieben werden, da ..tar.gz sämtliche Rechte und Attribute im Archiv mitspeichert (nicht getestet; evtl. hat jemand/jefrau Erfahrungen damit).
Auch auf die zu sichernde Partition kann das ..tar.gz mit ziemlicher Wahrscheinlichkeit erstmal geschrieben, dann von dort zB. auf eine DVD gebrannt und danach natürlich gelöscht werden: Diese Lösung ist nicht getestet, aber zB. unter WinRAR läuft es genauso ab, dass von WinRAR erstmal die zu sichernden filenames ermittelt werden, so dass es nicht zu einer redundanten Sicherungs-Speicherung kommt.
Da der Hintergrund sehr ausführlich erläutert wird, damit Anwendungsmotivation und -sicherheit erreicht wird, ist der Bericht in drei überschaubare Teile gegliedert. Datensicherung ist eine Grundfunktion der ordentlichen Datenverarbeitung, oder kennt jemand ein seriöses Rechenzentrum, das nach Desaster mit Stunde NULL anfängt?
Teil1
1. Zwingende Gründe für Datensicherungen und
„tar-gzip macht müde Platten munter“ - Testzeiten
2. Und so geht es - Sichern
Teil2
3. Und so geht es – Prüfen nach Schreiben
4. Und so geht es – (Gesamt-)Sicherung restaurieren
sowie die reine Befehlsliste als 'Kurz-Fahrplan'
Teil3
5. Noch mehr Möglichkeiten – nicht alles auf einmal erforschen
-Nur ein Verzeichnis einer Partition sichern
-Nur ein Unterverzeichnis einer Sicherung wiederherstellen
-Nur eine oder mehrere bestimmte Dateien wiederherstellen
1. Vorbemerkungen
a) Allgemein
„Eigentlich nichts Neues?“ - stimmt. Aber da noch immer viel zu viele vor der Datensicherung zurückschrecken, wird es hier nochmal geschlossen und ausgetestet dargestellt, zumal es wirklich ganz einfach ist. Ohne Datensicherung traut man sich entweder kaum etwas am System zu machen, oder es wird am System gewerkelt bzw. ein Tippfehler aus Übermüdung - und schon ist das Chaos da, das dann in stundenlangen Reparaturversuchen behoben werden soll – dabei ist das 100%-ige System-Wiederherstellen in einer guten halben Stunde erledigt: Es lebt sich ruhiger mit existierender Datensicherung, die natürlich bei noch intaktem System erstellt werden muss! Und nicht nur einmal. Also Datensicherung sofort vormerken! :)
Manchmal passieren 'damages' schneller als einem lieb ist; unlängst startete ich mein Testsystem und landete -ohne dass ich bewusst etwas Wichtiges verändert hatte- nach dem Starten in der root-console. Das 'init 5' für kde-GUI funktionierte zwar, aber es waren keinerlei andere Partitionen mehr gemountet und ähnliche 'Unwuchten', obwohl die /etc/fstab noch voll intakt war: Also nach drei Jahren und zwei Monaten OHNE PROBLEME außer Nacharbeiten zu den halbjährlichen großen SuSE-Updates plötzlich der Schuss aus dem Dunklen. Klar, dass das Restaurieren der letzten Datensicherung in einer guten halben Stunde für mich einfacher war als ggf. stundenlang Fehler zu suchen, und außerdem ist Fehlersuche keine Garantie für den Erfolg.. :D
b) „tar-gzip macht müde Platten munter“
tar – das ist der „GNU Tape Archiver“, ein in der Unix- und Linuxwelt lange bewährtes und sicheres Standardwerkzeug, das heute neben Tapes/Bändern auch für andere Laufwerke eingesetzt werden kann. Aber warum wechseln, wenn ich einmal wöchentlich aus Servicegründen für Bekannte sowieso Win98SE starte und Win-DriveImage 2002 die mit 4GB belegte ext3-Partition problemlos und schnell in einer halben Stunde auf CDRWs sichert?
-Seit dem Update auf SuSE10.0 verweigert DriveImage 2002 die Sicherung der SuSE10.0-Gesamtpartition, wahrscheinlich weil 'der reservierte Systembereich' von 33 auf 129 MB angewachsen ist. Mit Umkopieren unter Linux auf eine freie Partion und dann mit DriveImage 2002 sichern gab es zwar eine Problem-Umgehung, doch weder stilecht noch zeitlich günstig.
-Das Handling mit drei Datensicherungs-CDRWs war mit insgesamt neun Datenträgerwechseln verbunden (dreimal löschen, dreimal schreiben, dreimal prüflesen) und soll durch Umstieg auf eine schnelle usb2.0-Festplatte abgelöst werden. Eine Stückelung auf 650 MB und einzeln auf CDR(W)s brennen geht auch mit nachfolgend beschriebener Linux-tar-Lösung sowie zusätzlichem split-Befehl und späterem cat für das Wieder-Zusammenfügen, jedoch hat man ziemlichen zusätzlichen Zeitbedarf für das exakte Handling: Externe leise usb-80GB-Festplatten kosten nur noch so um die 75 Euro; außerdem fällt einem nach und nach noch viel mehr ein, was man mit Plattenplatz alles anfangen kann.
Im Praxistest stellte sich allerdings heraus, dass die usb-Festplatte nur einen Durchsatz von 45 MB/Min. erreicht (hotplug-automount – auch Win98SE hat keine viel besseren Werte), während die IDE-Festplatte mit 267 MB/Min. die sechsfache Schreibgeschwindigkeit erreicht. Zwar konnte ich den Schreibdurchsatz der usb-Festplatte auf 62 MB verbessern*), aber das ist immer noch 4-fach langsamer als die IDE-Festplatte. Also führte das zu der Idee, das Schreibvolumen und damit den Zeitbedarf durch Komprimieren des 4GB-Datenvolumens zu reduzieren. Das Ergebnis ist beeindruckend
b1) 108 Minuten mit gebootetem SuSE10.0-automount ('cp -a * /zielverzeichnis')
b2) 62 Minuten mit gebootetem SuSE10.0, /dev/sdc5 selbst gemountet **) ('cp -a * /zielverzeichnis')
b3) 31 Minuten mit gebooteter Knoppix-CD/-DVD sowie tar mit gzip-komprimiert! Der Optimierungsversuch mit '-b 128' brachte keinen Zeitgewinn, ebenso wenig wie die Nutzung des Komprimierungs-Algorithmusses bzip2 statt gzip – die Archivgröße schrumpfte zwar von 1551 MB auf 1436 MB, aber der Zeitbedarf wuchs auf 56 Minuten! Alle genannten Zeiten wurden auf einem 0815-PC mit Athlon 2000+ und einer drei Jahre alten IDE-Festplatte ermittelt.
Geduld, die praxisrelevanten Details folgen sofort.
**) dazugehörige Ergänzung der /etc/fstab
...
/dev/sdc5 /mmnt/sdc5 ext3 users,gid=users,umask=0002,utf8=true 0 0
...
und dann meine usb-ext3-Festplatten-Partition /dev/sdc5 selber gemountet mit einem eigenen mount-Verzeichnisnamen, dh. zusätzlich zum automount; async statt sync bringt bei großem Datenvolumen NICHTS, da das cache'n (gepuffertes Schreiben) schnell ausgeschöpft ist.
2. Und so geht es - Sichern
a) Vorlauf
Knoppix-CD/-DVD booten, 'knoppix 1' als Start-Auswahl eingeben.
[Grundsätzlich kann man eine Linux-Partition mit tar auch von einer 'anderen gestarteten Linux-Partition' aus sichern. Aufgrund eigener zweifelhafter Erfahrungen unter SuSE-kde rate ich aber dazu, die GUI zu verlassen, dh. zum Beispiel in der kde-konsole 'su' einzugeben, root-Kennwort eingeben und dann 'init 1', der Rest wie folgt. ACHTUNG: Dass der PC VORHER im Ruhezustand sein muss/Schreibvorgänge beendet sind, muss strikt beachtet werden! Der Restart der kde-Oberfläche ist mit dem Befehl 'init 5' möglich.]
'ls -l /mnt/*' - aha, usb-ext3-Partition ist auch bei Knoppix als /mnt/sdc5 mountbar. Gesichert werden soll das Datenvolumen der Partition /mnt/hda10 [SuSE10.0-Produktionssystem]
'mount -t auto /dev/hda10 /mnt/hda10'
'mount -t auto /dev/sdc5 /mnt/sdc5'
b) Die Sicherung läuft
'cd /mnt/hda10'
'ls -l' und 'pwd' #wo bin ich?
#ok, auf der richtigen Partition. Der Verzeichniswechsel auf die Quellpartition bewirkt außerdem, dass die Archiv-Filenames ohne vorlaufendes '/mnt/hda10' gesichert werden.
Und dann ein schlichtes
'tar czf /mnt/sdc5/hda10_29.11.2005.tar.gz ./ >& ignored.log'
#Huch? – ok, nun die detaillierte Auflösung
czf #create_archiv mit gZip, f=zielFile-Name folgt
# 02.01.2005: Syntax-sprachlicher Patzer dank geronet korrigiert
/mnt/sdc5/hda10_29.11.2005.tar.gz
#Ein sprechender zielFile-Name sollte es schon sein
./
#gesichert wird das aktuelle [Quell-]Verzeichnis mit allen Unterverzeichnissen
>& ignored.log
#das ist wahrscheinlich am schwersten zu akzeptieren, sorgt aber für stressfreies Sichern: tar hat offenbar intern eine Tabelle für Unterverzeichnisse in /tmp und /var, deren temporäre files NICHT gesichert werden (müssen); diese nicht gesicherten files werden zwangsweise am Bildschirm (fprintf) ausgegeben. Mit dieser Syntaxergänzung werden die ignored-filenames nicht in den Bildschirm geschrieben, sondern landen in der Datei ignored.log, die man sich dann mit 'less ignored.log' ansehen kann (bei mir zwei Bildschirmseiten, verlassen mit 'q'uitt).
ODER '>& ignored.log &'
#was denn, noch ein '&'? JA, damit wird dann der GESAMTE JOB vollständig im background/Hintergrund ausgeführt, und durch wiederholtes 'df -m' kann man sich das Anwachsen der Datensicherungsschreibmenge auf dem Ziellaufwerk summarisch ansehen. Oder direkt das Dateiwachstum mit 'ls -l /mnt/sdc5'.
Variationen
- - - - - -
Es gibt eine Fülle von Sicherungs-Varianten zB. das Kommando 'u'pdate für Ergänzungssicherungen, Sichern von Netzwerken usw.: Weitere Informationen überlasse ich lieber praxis-gehärteten Fachleuten*), meine Infos habe ich aus dem 320seitigen! Buch „Datensicherung unter Linux. Grundlagen – Werkzeuge – Konzepte“ von Wolfgang Barth, open source Press entnommen, Preis nach meiner Erinnerung ca. 20 Euro.
*) [quote=Der Autor schreibt zum Beispiel..
Vorsicht bei Access Control Lists
Die hier vorgestellten Programme berücksichtigen allesamt keine erweiterten Zugriffsrechte, so genannte Access Control Lists nach dem POSIX Draft 1003.e. Da Access Control Lists nur dann verwendet werden können, wenn Filesystem und Kernel dies unterstützen (bei Kernel 2.4 sind in der Regel noch Patches erforderlich), und der Administrator sie bei Filesystemen wie ext2/ext3 auch erst explizit einschalten muss, sind Access Control Lists derzeit noch wenig verbreitet. Falls welche vorhanden sind .. (sinngemäß) müssen vorher Zusatztools zur Anwendung kommen..[/quote]
-Kommandos 'czvf' statt 'czf' bewirken, dass durch 'v'=verbose alle 100.000 filenames auf den Bildschirm ausgegeben werden – sinnvoll?
-Kommandos 'uzf' statt 'czf' bewirken, dass durch 'u'=updates nur neue bzw. geänderte files in das vorhandene Archiv geschrieben werden, genauer werden am Ende des Archivs hinzugefügt. Doch ich bevorzuge wöchentliche Gesamtsicherungen mit sechs Sicherungsgerationen sowie einer vierteljährlichen Langzeitsicherung, für eine Workstation mehr als ausreichend. Oder nach vielen Systemänderungen.
GRUNDSÄTZLICH kann das ..tar.gz-Archiv auch auf vfat-Partitionen geschrieben werden, da ..tar.gz sämtliche Rechte und Attribute im Archiv mitspeichert (nicht getestet; evtl. hat jemand/jefrau Erfahrungen damit).
Auch auf die zu sichernde Partition kann das ..tar.gz mit ziemlicher Wahrscheinlichkeit erstmal geschrieben, dann von dort zB. auf eine DVD gebrannt und danach natürlich gelöscht werden: Diese Lösung ist nicht getestet, aber zB. unter WinRAR läuft es genauso ab, dass von WinRAR erstmal die zu sichernden filenames ermittelt werden, so dass es nicht zu einer redundanten Sicherungs-Speicherung kommt.