Backup und Restore mit Linux

closeDieser Beitrag gehört zu der Artikelserie LPIC-2
closeDieser Beitrag wurde vor über 3 Monaten veröffentlicht. Die darin beschriebenen Informationen sind mit Vorsicht zu geniessen, da sie bereits veraltet oder nicht mehr gültig sein könnten. Solltest du von Neuerungen oder Verbesserungen wissen, so freue ich mich über einen klärenden Kommentar.

Von den bisher vorgestellten Themen in LPIC 201 ist das folgende eines der interessanteren: Backup und Archivierung!
Wie in den Artikeln vorher schon erwähnt, ersetzt RAID nicht wirklich ein Backup und LVM schon gar nicht! Es muss also trotzdem noch eine Lösung her – und um die kümmern wir uns jetzt!

Arten

Bevor man überhaupt mit einem Backup beginnt, muss man sich überlegen, was, wie und wie oft man etwas sichern möchte. Das was ist dabei relativ schnell gefunden, zum Beispiel das /home-Verzeichnis. Auch das wie oft ist ein kleineres Problem; jeden Abend sollte reichen.
Doch nun muss man sich überlegen wie! Denn wenn ich jedes mal alle Daten von neuem Kopiere und allen alten Backups behalte, so leide ich schnell an Platzmangel. Deshalb muss man zuerst wissen, wie alles gesichert werden kann:

Full

Zu aller erst muss man ein Full-Backup anlegen. Dabei werden alle Daten welche im zu sichernden Ordner /home sind, gesichert.

Inkrementell

Inkrementell empfiehlt es sich, wenn man wenige Daten haben, welche sich immer ändern. Denn beim inkrementellen Backup werden nicht alle Daten, sondern nur die gesichert, welche seit dem letzten Backup verändert wurden.

Differenziell

Differenziell ist ähnlich wie inkrementell, jedoch werden hier immer die gesicherten Daten seit dem letzten Full-Backup gesichert

Zeitplan

Nun kann man sich sagen: “Ich mach immer inkrementell, da brauch ich am wenigsten Platz”! Dazu muss ich sagen, das stimmt durchaus, jedoch ist es halt nicht die beste Lösung.
Gehen wir von der Situation aus, ich habe vor einem Monat ein Full-Backup angelegt und seither täglich inkrementelle Backups. Fällt mein System aus, so muss ich zuerst das Full und dann 30 inkrementelle Backups zurückspielen. Nicht nur aufwendig, sondern auch zeitraubend!

Ein gutes Mittelmass wäre also zum Beispiel einmal im Monat ein Full-Backup, einmal pro Woche ein differenzielles und dann Täglich ein Inkrementelles. Dies natürlich nur auf einem System mit sehr wertvollen Daten wie einem Server auf dem täglich gearbeitet wird, ansonsten könnte man die inkrementellen Backups weglassen.
Im schlimmsten Fall, also ein Ausfall ein Tag vor dem neuen Full-Backup, so müsste man nur das alte Full-Backup dann das differenzielle und bis zu 5 inkrementelle Backups zurückspielen. Klingt aufwendig – ist es auch! Aber besser als 30 inkrementelle Backups ist es garantiert…

Housekeeping

Um Speicherplatz zu sparen, sollte man auch an ein gut durchdachtes Housekeeping denken. Dabei wird festgelegt, welche Art von Backup wie lange behalten und wann gelöscht wird.
Um auf obiges Beispiel zurück zu kommen, so sollte man ein Housekeeping wie das folgende in Betracht ziehen:

  • die letzten beiden Full-Backups
  • die differenziellen Backups aus dem letzten und aktuellen Monat
  • die inkrementellen Backups der aktuellen Woche

Somit ist man im schlimmsten Fall in der Lage bis zu zwei Monate zurück zu gehen. In der Praxis wird sich aber zeigen, meist sind Restores von über einer Woche sehr sehr selten, also könnte man das Housekeeping noch optimieren.

Speicherort

Ganz entscheidend für die langfristige Verfügbarkeit und auch die Geschwindigkeit beim Sichern und Restoren ist das Medium, auf welches gesichert wird.
Die meisten werden dabei auf einfache Festplatten zurückgreifen. Sehr wenige noch auf DVDs und die allerwenigsten im privaten Bereich gar auf Tapes. Flash-Disks lasse ich hier auf Grund des hohen Preises mal aussen vor.
Doch muss man wissen, dass eine Festplatte sehr anfällig für Fehler ist. DVDs sind leider ein bisschen Begrenzt, was die Kapazität angeht und Tapes für eine Privatperson sehr teuer.
Auch hier gibt es wieder ein Abwägen des idealen Mittelmasses!

Software

Und auch bei der passenden Software wird es nicht einfacher! Die Qual der Wahl bleibt einem auch hier nicht erspart. LPIC beschränkt diese aber klar auf Amanda, Bacula und BackupPC, sowie die üblichen Verdächtigen wie tar, dd, rsync und mehr.

tar

tar ist ein Stück Softwar, das bestimmt schon mal jeder benutzt hat. Mir geht es auf jeden Fall so; jedes mal wenn ich es benütze, muss ich wieder nach den passenden Parametern zum (ent-)packen studieren.
Alles was tar macht, ist alle Daten mitsamt deren Zusatzinformationen wie Owner, Rechte o.ä. in ein Archiv zu packen und, falls gewünscht, noch zu komprimieren:

tar -cfv backup.tar Verzeichnis1 Verzeichnis2 Datei1 Verzeichnis3

Die Komprimierung aktiviert man über den Parameter z:

tar -cfvz backup.tar.gz Verzeichnis1 Verzeichnis2 Datei1 Verzeichnis3

Zum Entpacken dann:

tar -xfv backup.tar

Oder auch wieder mit Komprimierung:

tar -xfvz backup.tar.gz

Und auch in tar steckt noch ein bisschen Logik. So kann über den Parameter -u verlangt werden, dass falls eine ältere Version innerhalb des Archives schon besteht, diese durch die neue ersetzt wird. Somit hat man auch ein sauberes Backup mit den neusten Daten und nicht noch alle veralteten Version der Datei mit drauf.

cpio

Auch Bestandteil von LPIC ist das Tool cpio. Doch grosse Neuerungen zu tar bringt es nicht, also ist es hier auch nicht erwähnenswert!

Wegkopieren

Wenn man nun sein Archiv erstellt hat, muss das natürlich auch noch an einen anderen Ort wie zum Beispiel ein Fileserver oder Tapelaufwerk.
Für ersteres kann man ganz gut rsync verwenden:

rsync -a backup.tar.gz fileserver:/backup/master/

Image-Kopie

Eine Image-Kopie gibt es, wenn man von seiner Maschine ein Image erstellt. Dies bedeutet eine 1:1 Kopie seiner Festplatte, jedoch nicht auf Datei, sondern auf Byte-Ebene.
Somit hat man nicht nur alle Dateien, sondern man hat die ganze Festplatte. Sollte die Maschine also im schlimmsten Fall mal formatiert werden, so sind nicht nur Daten sondern auch das System selbst verloren. Bei einem Server ist dies weniger ärgerlich, da ist neu aufsetzen eh die bessere Lösung. Bei einem Client aber könnte man hier ein Image zurückspielen. Dabei werden dann nicht nur die Daten sondern auch das ganze Dateisystem mit Partitionstabelle und MBR zurückgeschrieben.
Erstellen kann man dies zum Beispiel mit dd. Jedoch sollte man beachten, das Image wird genau so gross, wie die Festplatte. Auch wenn diese nur zu 10% mit Daten beschrieben ist!

sudo dd if=/dev/sda of=/backup/backup.img

Weitere Lösungen

LPIC verlangt, dass der Kandidat weiss, dass es noch andere Lösungen wie Amanda, Bacula oder BackupPC gibt. Diese spezifisch einzurichten wird dabei bewusst aussen vor gelassen. Also wollen wir auch nur ein paar Worte dazu verlieren.

Natürlich sind tar und cpio keine Lösungen für ein Backup von mehr als einem kleinen PC. Der Aufwand zu jedem Server und Client in einem 1000 Personen Unternehmen zu gehen, da ein tar vom /home-Verzeichnis zu erstellen und an den Backup-Server zu schicken wäre kaum auszumalen!

Also gibt es Softwarelösungen wie zum Beispiel Bacula. Dieses basiert auf einem Kontrollserver, welcher programmiert und eingestellt wurde und dann über seine Agents auf den jeweiligen Maschinen im passenden Moment das Backup startet. Weiter leitet der Kontrollserver, welcher von Bacula übrigens liebevoll “Director” getauft wurde, die Daten von den Agents an den Storage-Deamon auf z.B. dem Tapelaufwerk weiter.
Nebenbei bieten solche Lösungen auch noch weitere Features wie zum Beispiel Wiederherstellung-DVDs.

close
Immer informiert sein dank meines RSS Feeds.Oder folge mir via Twitter!

20 Gedanken zu „Backup und Restore mit Linux

  1. Voku

    … kann wirklich jedem der in seinem Netzwerk (Linux- / Windows-PCs) mit einer freien Backup-Lösung sichern möchte (und schon ein wenig Erfahrung mit Linux hat) -> “Bacula” <- empfehlen, hatte das System bei mir zuhause für verschiedene echte und virtuelle PCs im Einsatz und es hat wunderbar funktioniert… :) wenn es einmal eingerichtet ist läuft es einfach und gut, besser als irgendwelche Shell-Skripte die per cron ausgeführt werden! ;)

    Mfg
    Lars

    Antworten
  2. Uwe

    Wenn man schon auf Platten sichert sollte man sich die Frage stellen wozu überhaupt noch tar-Archive erzeugen? rsync ist hier das ideale Werkzeug um eine Kopie der Daten zu erzeugen und auch synchron zu halten. Im Gegensatz zu der tar-Lösung hat das noch den Vorteil das im Archiv der gelöschte Kram auch verschwindet.

    Dabei kann man das Ganze auch sehr schön mehrstufig aufbauen: Eine Komplettsicherung meines Systems mache ich eigentlich nur noch nach großen Distributionsupdates. Sonst werden nur die Datenpfade gesichert, da mir die Softwarestände nicht so wichtig sind bzw. diese ja bei Bedarf relativ schnell via Onlineupdate wieder aktualisiert werden können. Dadurch sind die Sicherungen der Datenpfade auch sehr schnell erledigt.

    Man sollte dabei natürlich tunlichst darauf achten wenigstens 2 Backupsätze zu haben, um hier durch Redundanz eine hohe Sicherheit gegen Hardwareausfälle zu haben. Bei heutigen Plattenpreisen ist das aber definitiv kein Thema mehr.

    Antworten
    1. Patrick Artikelautor

      Wenn du auf Shares oder bestimmte Dateisysteme sichern willst. Ein Fullbackup via rsync auf einen Windows-Share vertreibt dir alle Dateiberechtigungen. Da wird ein Restore sehr aufwendig, weshalb tar helfen kann.

      Antworten
  3. Tim

    Hallo!

    Ich empfehle rsnapshot.
    Damit hat man Fullbackup und inkrementelles Backup in einem.
    Wenn man also eine Datei vor einer Woche gelöscht hat und sie wieder benötigt kann man sie einfach wieder finden.
    Es verwendet rsync und ist schnell.

    Gruß
    Tim

    Antworten
  4. winky

    @patrick

    deine restore-erklärung bzgl incremental backup mag für datenbanken richtich sein (erst das full und dann die 30 incrementals), aber für filesysteme is das nich relevant. da mach ich initial ein full (also eigentlich auch ein incremental, aber weil auf “tape” ja noch nix is, wird da halt n full draus) und anschließend incremental for ever da mich im havarie-fall eh nur das aktive backup interessiert. für den fall das ich mal versehentlich was lösche heb ich noch 2 passive versionen auf und fertig is die laube. damit geht auch super ein point-in-time-restore. diffenential’s haben im bereich von FS-backup somit nich sonderlich viel bedeutung und fulls nur da, wo es tatsächlich auf furchtbar schnelle restore-zeiten ankommt, was zu hause quasi nie der fall ist. zumal man da ohnehin nur im unteren TB-bereich daten verwaltet.

    Antworten
    1. Patrick Artikelautor

      Ich kann deiner Begründung leider nicht ganz folgen. Aber im Falle, dass nach dem Ausfall keine Daten mehr auf der Platte vorhanden sind, musst du das Full- und danach die Inkremental-Backups zurückspielen… Da gibt es kein Weg drum herum.

      Antworten
  5. lightonflux

    Kennt ihr ein Tool mit dem man sein Backup-Verhalten analysieren kann, um danach das Housekeeping zu optimieren?

    Antworten
  6. Schneida

    Ich verwende für mich privat Unison. Dabei habe ich eine Kopie auf dem Desktop, eine auf einem Server und eine auf meinem Laptop. So ist alles immer schön synchron und auch gleich gesichert.

    Unison arbeitet dabei mithilfe von rsync und kopiert somit nur die veränderten Dateien, hat aber den Vorteil, dass Änderungen auf beiden Seiten durchgeführt werden können.

    Zusätzlich hab ich noch BackInTime am auf dem Server am laufen. Dort wird pro Backupvorgang ein neues Verzeichnis mit Hardlinks auf die alten Daten angelegt. So kann man große Datenmengen (80 Gb bei mir) relativ einfach inkrementell sichern und hat auf eine Art History Zugriff.

    Antworten
  7. Dominik

    Mein Lieblingsansatz ist rsync in Kombination mit “cp -al”. Inkrementelle Backups die im Dateisystem dank Hardlinks jeweils als Vollbackup verfügbar sind. Selbstverständlich hat auch dieser Ansatz so seine Nachteile…

    (Der Link auf meine Website geht auf einen Wiki-Eintrag, der die Vorgehensweise für remote-backups beschreibt – ist aber auch lokal anwendbar.)

    Antworten
  8. Jens

    Bei den tar-Beispielen ist aber ein Fehler drin. Nach dem -f-Schalter muss die Backupdatei folgen, dieser sollte folglich der letzte sein.

    Antworten
  9. Norbert

    Seid Jahren verwende ich begeistert rsnapshot.
    Inkrementelles Backups werden täglich, wöchentlich, monatlich per anacron durchgeführt. Läuft nahezu unbemerkt und zuverlässig im Hintergrund.

    Antworten
  10. Norbert

    “Fällt mein System aus, so muss ich zuerst das Full und dann 30 inkrementelle Backups zurückspielen. Nicht nur aufwendig, sondern auch zeitraubend!”

    Das verstehe ich nicht ganz. Ich habe auf meiner Sicherungsplate z.B. Bilder von 8 Jahre in dem Ordner “Bilder”. Gestern lief die letzte Sicherung wobei 3 Bilder dazu gekommen sind. Fällt das System aus, so gehe ich in den Ordner “daily.0″, das ist das inkrementelle Backup von gestern und kopiere mir den Order Bilder in mein neues System. Schwups, sind 8 Jahre Fotos gerettet :-)

    Antworten
    1. Patrick Artikelautor

      Fällt dein System komplett aus, sprich es sind keine Daten mehr drauf, und du tust das letzte inkrementelle Backup zurück spielen, so hast du 3 Bilder drauf…

      Antworten
  11. Norbert

    Das Backup wird nicht auf der System-Festplatte geschrieben. Fällt die System-Festplatte aus, das ist bei mir eine kleine aber sau schnelle SSD, dann habe ich erst mal noch eine weitere Festplatte auf der sich /home mit meinen Daten befindet. Nehmen wir mal an die Home-Festplatte verabschiedet sich, dann habe ich noch eine Backup-Festplatte auf der rsnapshot regelmäßig sichert. Warum sollten da dann nur noch 3 Bilder drauf sein?

    Antworten
    1. Patrick Artikelautor

      Du schreibst am Tag 1 ein Fullbackup mit 100 Fotos. Am 2. kommen 2 dazu, am 3. 4 neue. Das heisst in den inkrementellem von Tag 2 und 3 sind jeweils nur 2 respektive 4 neue dazu. Wenn du also gar nichts mehr auf der Platte hast und nur das letzte inkrementelle vom 3. Tag zurück spielst so hast du 4 Fotos drauf.
      Das gilt natürlich nur wenn du die Backups getrennt von einander ausführst, also nicht via rsync…

      Antworten
  12. Norbert

    Sorry, vermutlich hatte ich dich falsch verstanden? Du gehst davon aus das auf der Backup-Festplatte ,aufgrund irgend eines Ereignisses, nichts mehr drauf ist, außer die letzte Sicherung. So ist es dann. Es sind nur noch die Daten der letzten noch vorhandenen Sicherungen vorhanden.
    Wirklich verloren sind die Daten aber erst, wenn auch noch die zu sichernde Festplatte ausgefallen ist.

    Ansonsten arbeitet rsnapshot so, dass das letzte Backup immer auch die Daten aller vorhergehenden Daten enthält, wenn auch als Verknüpfung zu den Daten der vorherigen Backups (außer der zum Zeitpunkt des letzten Backups gelöschten Daten, diese Verknüpfungen fehlen).

    Beim zurückspielen der Daten muß also nicht erst mühsam jedes einzelne Backup zurück kopiert werden :-).

    Antworten

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <b> <blockquote cite=""> <cite> <del datetime=""> <em> <i> <pre lang="" line="" escaped=""> <strong>