Inhaltsverzeichnis
Datensicherung
Eine Datensicherung, auch Backup genannt, ist eine notwendige und zugleich komplexe Angelegenheit.
Deswegen sollte man sich vorher klar machen, was man erreichen möchte. Zusätzlich sollte man allen Beteiligten (Auftraggeber bzw. Benutzern und Vorgesetzten) gelegentlich erklären, was das Backup leistet - und was eben nicht.
Ein Wiederherstellen des letzten gesicherten Standes des Rechners ist ein klassisches Backup. Aus Sicherheitsgründen sollte man immer mehrere Generationen des Backups besitzen. Auch Backup-Medien können Defekte aufweisen.
Vom Backup zu unterscheiden ist die Offlinelagerung und die Verfügbarkeit der Daten.
Richtige Datenbanken brauchen besondere Beachtung beim Backup. Meist bringt die Datenbank ein spezielles Tool mit.
- Simples MySQL Backup-Script:
mysqldump datenbankname -uusername -ppasswort > /backup/datenbank-backup-$(date +"%Y-%m-%d").sql
Anmerkung: Dies ist ein sehr schlechte Idee da dies ein großes Sicherheitsrisiko ist. So können alle angemeldeten Benutzer aus der für jeden zugänglichen Prozesstabelle(etwa mit ps aux das Passwort auslesen. Besser ist es das Benutzername und Passwort in .my.cnf zu speichern und diese Datei read-only (-r-------; 0400) für den Backup-User zugänglich zu machen.
mysqldump ersetzt das password durch *. Probier es aus. U. u. kann man es aber mit Tricks noch auslesen, bevor es ersetzt wurde. -- HenrykGerlach
Teilweise Sicherung
Normalerweise reicht es, folgendes zu sichern:
- /home: Die gesamten Benutzerdaten, incl Anwendungs-spezifische Einstellungen.
- /data : die erstellten Dokumente, oft auch direkt unter /home/data angemeldet
- /etc: Die gesamte Konfiguration.
- /usr/local: Alles, was außerhalb der Distribution selbst kompiliert/installiert wurde.
- /opt: Falls es existiert und Du hier selbst distributionsfremde Software installiert hast, dito.
/(boot/)zImage: Deinen Kernel. Ggf. auch zusammen mit LOADLIN auf einer BootDiskette.
packages.list: Eine Liste sämtlicher installierter Pakete, generiert mit rpm -qa > packages.list oder dpkg (oder dem PaketManager deiner LinuxDistribution):
dpkg --get-selections "*" > selections-all
Kann dann später wiedereingelesen werden ( Habe ich noch nicht getestet):
dpkg --set-selections < selections-all
dpkg --yet-to-unpack
- zeigt dann die Pakete an, die noch installiert werden müssen.
- ABER WIE INSTALLIERT MAN SIE?
http://debiananwenderhandbuch.de/dpkg.html#dpkggetss
- apt-get dselect-upgrade
- /usr/src/linux/.config (oder /boot/*config): Deine Kernel-Konfiguration.
- /var ist teilweise auch wichtig, z.B. email-Spools, Datenbanken usw.
Das setzt aber voraus, dass wirklich sämtliche Konfigurationsdateien in und unterhalb von /etc liegen (wie bei Debian), dass alle Installationen von selbst kompilierter Software und nicht in Paketform gelieferter Software in und unterhalb von /usr/local und /opt liegen (da mußt Du selbst aufpassen), und natürlich, dass es eine Möglichkeit gibt, die Paketliste wieder automatisiert zurück zu installieren, und zwar möglichst schnell und einfach (ist bei Debian der Fall, mittels dpkg --get-selections und dpkg --set-selections und anschließendem apt-get dselect-upgrade).
Klassischerweise werden Backups mit Programmen wie tar auf Bänder gemacht (Tape/Streamer)
Wenn man kein Band benutzen will ... Automatische Sicherungen
Auch wenn Bandlaufwerke Vorteile bieten sind sie doch teuer, langsam und benötigen fast immer manuelles zutun. Deshalb kann es gerechtfertigt sein sie z.B nur für bestimmte Zwecke ergänzend zu Backupservern mit Festplatten zu verwenden.
Für Ideen schaue man sich die Seite rsync/SnapshotBackups sowie die Links auf der Originalseite an. Oder auch das Tool dar.
Vollständige Sicherung
Ansonsten kann man natürlich, genug Platz vorausgesetzt, auch einfach das gesamte System sichern. Außer einer Möglichkeit zu booten, die Platten ggf. neu zu partitionieren und auf das Backup-Gerät zuzugreifen (nicht lachen: so selbstverständlich scheint das gar nicht zu sein), braucht man nichts weiter zu beachten. Linux besitzt keine versteckten Systemdateien oder so etwas ähnliches. Und diese Features bietet meistens die Distributions-CD, wenn nicht, bastelt man sich eine BootDiskette mit der Bootdisk-HOWTO.
Man kann für solche Aktivitäten tar benutzen. Ein Komplettbackup des gesamten Systems auf DAT-Tape geht mit
cd / ; tar cvf /dev/st0 --exclude=./proc --exclude=./tmp .
Man hüte sich davor, dabei Kompression mit gzip ("z") oder bzip2 ("j") zu verwenden, denn:
- Streamer haben heutzutage Kompression in Hardware eingebaut und komprimieren die Daten blockweise
- gzip und bzip2 komprimieren den kompletten Stream - dies würde bei einem fehlerhaften Block auf dem Band zum Verlust aller nachfolgenden Daten führen!
Man sollte aber vorher u.U. ein init S machen, d.h. auf Singleuser-Modus ohne Netzwerk runterfahren, damit so wenig wie möglich Dienste während des Backups laufen. Dann muss man sich noch Gedanken machen, wie man ein Linux wieder booten kann, wenn der Plattencrash passiert ist - oft reicht die Boot-CD der jeweiligen Distribution, aber nicht immer ist dort auch der passende Code für das gerade benutzte Tape dabei.
Am besten einmal ein Backup fahren, von der CD booten und mittels (st0 = SCSI-Tape-Device 0)
tar tvf /dev/st0
gucken, ob man auf das Tape Zugriff hat. Ansonsten kann man auch folgendes benutzen, um z.B. auf irgendein Medium (ZIP, MOD, JAZ, etc.) zu sichern:
mount /mod; cd / ; tar cvjf /mod/backup.tar.bz2 --exclude=./mod . # weitere excludes s.o.!
das Restore geht dann analog:
cd / ; tar xvjf /mod/backup.tar.bz2 .
aber vorher natürlich sicherstellen, dass tar und bzip2 auf einem bootfähigen Rettungsmedium zur Verfügung stehen. Und natürlich die Partitionen entsprechend anordnen. Man kann auch innerhalb des Rettungssystems die zukünftige root-Partition z.B. unter /mnt mounten, alle anderen Partitionen dann, wie gewünscht, darunter. Die Partitionierung ist im Prinzip beliebig (sie muss nicht unbedingt mit der vorherigen übereinstimmen), man sollte aber darauf achten, dass auf den neu erstellten Partitionen genug Platz ist für die jeweiligen geplanten Mountpoints (z.B. ein /var von 10 MB ist selten sinnvoll).
Der Parameter "j" beim tar-Aufruf komprimiert den Datenstrom mit bzip2, siehe dazu auch Anmerkungen bei der Bandsicherung. Bei Sicherung auf Festplatte / Wechselmedium kann das sinnvoll sein, denn die komprimieren i.d.R. nicht selbst - es bleibt aber gefährlich bei Medienfehlern!
Links
http://www.linux-magazin.de/Artikel/ausgabe/2001/05/backup/backup.html
KarlhannsSpiegel/DatenBackup - Sicherung der eigenen Dokumente und Benutzer-Einstellungen am Beispiel OpenOffice/StarOffice
Fragen und Antworten
Frage: Wie kann man unter Linux bestimmte Files und die ganze Partition so sichern, dass man nachher einzelne Files aus einem Backup wieder herstellen kann? Geht das mit tar? Und wie kann man dann auf dem Band (SCSI-Dat) sehen, welche Files dort schon angelegt wurden? Wieso kann man nicht mit xtar auf das Band zugreifen? Fragen über Fragen...
Antwort:
Versuche es mit dump. Alle Zugriffsrechte, Zeiten, Links und sonst alles Notwendige werden gesichert.
dump 0f /dev/st0 /mountpoint # sichert eine Partition dump 0f /dev/st0 # sichert einzelne Files cd /mnt ; restore rf /dev/st0 # stellt eine Partition wieder her cd /mnt ; restore if /dev/st0 # stellt einzelne Files per interaktivem Eingriff wieder her
Zu weiteren Optionen siehe man dump und man restore (ggfs. vorher installieren).
Anmerkung: dump & restore gehen nur auf ext2/ext3 Dateisystemen (und einigen anderen Dateisystemen, die dump/restore implementiert haben).
Wenn man eine Liste von Dateien haben will, die gesichert wurden, und mittels dieser Liste dann schnell einzelne Dateien restaurieren will (d.h. aus 2GB innerhalb von 1-2 Minuten, nicht einer Stunde), sollte man sich einmal dds2tar anschauen. Das ist eine Erweiterung für tar, welche eine Indexdatei erzeugt und beim Restore das Band schnell an die richtige(n) Stelle(n) spulen kann. tar selbst kann das von Haus aus normalerweise nicht.
Ist es richtig, dass dds2tar nicht bei DLT Laufwerken funktioniert (der Programmname deutet ja auch eigentlich auf dds Streamer) ? Beim Erstellen der index-Datei mit dds2index scheint noch Alles zu klappen aber beim Zurücksichern bekomme ich die Meldung "ioctl SEEK input/output ERROR". Ursprünglich war ich auf der Suche, die Rücksicherung einer einzelnen Datei aus einem 5 GB tar-Archiv vom DLT Band zu beschleunigen... -- IngoSchnieders 2003-06-23 09:41:51
Wer eine hübsche, simple GUI für das Tape-Backup haben will und ein DAT-Tape hat, kann sich ruhig mal kdat angucken. Das Programm für KDE erzeugt Standard-tar-Archive auf dem Tape, diese lassen sich also auch ohne ein laufendes KDE wieder restaurieren - und es erlaubt ein Restore von einzelnen Dateien, erzeugt Index-Dateien und ist nett zu bedienen.
Frage: Ich möchte einmal wöchentlich eine Vollsicherung durchführen und die restlichen (6) Tage nur eine Differential-/Zuwachssicherung. Sollte man nun als Referenz die letzte Sicherung nehmen oder doch lieber die letzte Vollsicherung? Der Vorteil, wenn ich die letzte Sicherung nehme düfte sein, dass die Backups kleiner sind, da sich ja von Samstag auf Sonntag weniger ändert als von Montag auf Sonntag (Wenn Sonntag auf Montag die Vollsicherung stattfindet). Allerdings werd ich im Falle einer Rücksicherung alle Differentialsicherungen seit der letzten Vollsicherung benötigen, was sicherlich auch suboptimal ist (Eine defekte Datei/Datenträger unter 7 Stück und schon kann man Sonntags keine vollständige Rücksicherung mehr machen) Wie macht Ihr eure Differentialsicherungen?
ganz klar immer auf das letzte Vollbackup beziehen. Als Grund hast du die defekten Datenträger bereits richtig identifiziert. Ausserdem ist das Rückspielen von Daten so schneller und der erhöhte Speicherverbrauch dürfte bei normalem Bürobetrieb wohl noch einige Zehnerpotenzen unter einem Prozent liegen. Du sprichtst hier von einem zweistufigen Backup. Beim dreistufigen Backup geht man bespielsweise so vor, dass man nur einmal im Monat ein Vollbackup macht, dann jede Woche ein differenzielles Backup welches sich auf das Vollbackup bezieht und dann täglich ein diferenzielles oder inkrementelles Backup bezogen auf das letzte Wochenende. -- JanRoehrich 2004-04-20 11:02:13
Erfahrungen aus dem Alltag
- Ausgerechnet das Band, das als einziges wichtige Daten enhält, lässt sich nicht mehr korrekt einlesen. Man sollte mindestens 2 Medien an getrennten Orten aufbewahren.
- Man sollte immer mehrere Bänder rotieren lassen und zyklisch auch auf Bänder sichern, die man für längere Zeit aufbewahrt. Beispiel: Mo, Di, Mi, Do jeweils ein Tagesband, das rotiert. Fr1, Fr2, Fr3 3 rotierende Wochenbänder. Jeden Fr4 ein Monatsband, was man nicht rotiert sondern für 5 Jahre aufbewahrt. Das macht dann 12 Bänder pro Jahr, die vewahrt werden.
- Während des Backups auf ein einziges, immer wieder genutztes Band stürzte die Maschine ab, das Band enthielt keine komplette Sicherung und auch die Platte des Systems war defekt. Alle Daten waren im Nirvana.
- Backup-Medien immer gut lagern, keine Sonne, keine hohen oder tiefen Temperaturen, keine Chemikalien, keine mechanischen Belastungen, keine Magnete usw.
- Apropos Magnete: Manche Leute haben die Angewohnheit, ihre Backups auf Lautsprecherboxen abzulegen. Oder auf die Hutablage im Auto. Es gibt viele Orte, wo Magnete versteckt sind.
- Grundsatz: Vertraue niemals einem Backup, was du nicht selber wieder zurückgespielt und getestet hast. Es ist ganz häufig so, dass man dachte, es wäre alles gesichert, um dann festzustellen, dass Wichtiges fehlt. Man sollte regelmäßig testen.
- Backups, deren Erstellung irgendwie lästig ist, schlafen gerne und schnell ein. Deshalb: Backups so einfach und weitgehend automatisiert wie möglich.
- Benutzer sollten darüber aufgeklärt sein, was wann wie gesichert wird und vor allem, was nicht gesichert wird. Nach Möglichkeit schriftlich, damit man später nicht der böse Admin ist.
- Bemühungen für gute Backups schlafen gerne ein, weil man ja nicht direkt was von hat. Erst bei einem Störfall, der gerade nochmal gut ging, wird man wieder wachgerüttelt. Also öfters mal Phantasien entwickeln, was kein Backup nach sich ziehen kann.
- Backup braucht eindeutige und klare Konzepte, die wohl durchdacht und schriftlich fixiert sind. Zufällig gewachsene Strukturen in dieser Art taugen nicht: "Manchmal schieben wir diesen Dateibaum auf jenen Rechner. Und Peter macht dann ab und zu mal eine Sicherung auf CD. Und wenn ich dran denke, mache ich das auch ab und an mal auf meinem Rechner." Im Ernstfall haben alle zufällig ihren Job vergessen. Und erst dann merkt man, dass viele wichtige Daten noch nie gesichert wurden.
- Backup braucht einen Verantwortlichen, der für alles gerade steht.
- Backup braucht eine gute Dokumentation, eine Art Buchführung, was wann wo auf welches Medium gesichert wurde und wo diese Medien lagern. Solche Dokumentation sollte sich nicht auf dem System befinden, welches man sichert, weil man in einem Störfall nicht dran kommt.
- Für Backups sollte man Werkzeuge benutzen, die es schon lange gibt, die leicht zu installieren sind, die evtl. auch auf mehreren Plattformen verfügbar sind. Nach Möglichkeit keine proprietäre und undokumentierte Formate verwenden.
Software
Zur Durchführung von Backups gibt es einiges an Software. Als erstes wäre hier natürlich tar zu nennen. Eine etwas neuere Abwandlung von tar zum Backup auf Fesplatten nennt sich dar. Und dann gibt es noch höherwertige Komplettlösungen für Backups:
- Flexbackup - liegt im Umfang mehr zwischen Tar und Bacula, wobei man sehr schnell ein differentielles Backup aufgesetzt hat
rsync-backup Script um inkrementelle Backups einfach zu erledigen.
mondo/mindi Backup auf verschiedene Medien (Band, CD/DVD). Besonders interessant ist die Desaster-Recovery Option (Booten von CD, automatisches Partionieren, Restore etc.)
BackupPC - einen Blick wert!!
Enthalten auf der Live-CD: http://www.sysresccd.org
- Ein statisch gelinkte Programm mit 1.7 MByte. Einfach auf das Sicherungsmedium kopieren, und das Zurückspielen ist gesichert.
- Restauriert auch in Partitionen mit anderer Größe.
- Kompression auf Dateibasis: Bei Lesefehlern ist nur die entsprechende Datei defekt.