Datensicherung von Servern
Willemers Informatik-Ecke
Diese Seite entstand aus meinen Veranstaltungen »Serveradministration« und »Netzwerkadministration« an der Hochschule Flensburg.

Auf dieser Seite geht es vor allem um die Datensicherung von Servern. Es gibt eine weitere Seite für die Datensicherung persönlicher Benutzerdaten.

Bedeutung und Konzept

Wenn die Daten plötzlich weg sind, ist es gut, wenn eine Datensicherung vorhanden ist.

Ursachen für den Datenverlust

Datenverluste können durch verschiedene Ursachen entstehen. Je nach Ursache werden unterschiedliche Strategien interessant. Ein Datenverlust kann unter anderem durch eine der folgenden Ursachen entstehen: Daraus wird deutlich, dass redundante Systeme, wie etwa RAID 5 nur bei einem Geräteausfall schützen.

Daten, die zu sichern sind

Die Art der Datensicherung und die Auswahl des Tools wird auch dadurch beeinflusst, welche Daten müssen gesichert werden sollen:
  1. Benutzerdateien sind besonders kritisch, weil man sie nicht einfach neu kaufen kann.

    Auf einem Linux-System liegen diese unterhalb des Verzeichnisses /home

  2. Server-Daten: Das sind meist Geschäftsdaten. Auch diese kann man nicht wiederbeschaffen, wenn sie erst verloren sind

    Server legen standardmäßig ihre Daten unterhalb des Verzeichnisses /var ab.

    Vorsicht: Datenbankendateien können nicht einfach per Kopie gesichert werden. Jede Datenbank stellt einen Befehl zur Verfügung, um die Datensicherung als Transaktion laufen zu lassen.

  3. Konfigurationsdateien sind oft an den eigenen Bedarf genau angepasst. Eine Wiederherstellung ist mühsam. Darum kann eine Sicherung sinnvoll sein. Da sich Konfigurationen selten ändern, müssen sie nicht regelmäßig gesichert werden.

    Konfigurationsdateien liegen bei Linux in der Regel unterhalb des Verzeichnisses /etc.

  4. Die Server-Software und des Betriebssystems können im Schadensfall natürlich einfach neu installiert werden. Das hat dann vielleicht sogar den Charme, dass versäumte Updates so aktualisiert werden. Eine Neuinstallation kostet aber Zeit. Muss das System schnell wieder laufen, kann eine Ersatzplatte im Schrank hilfreich sein.

Ziel der Datensicherung

In den guten alten Zeiten wurden Datensicherungen auf Magnetband durchgeführt. Bänder waren groß, billig und schnell. Nur die Bandgeräte waren nicht günstig. Datenbänder gibt es immer noch, aber manchmal sind andere Optionen interessanter. Idealerweise befindet sich das aktuellste Sicherungsmedium nicht im Gebäude. Der Administrator nimmt die Datensicherungsplatte der letzten Nacht immer mit nach Hause und bringt die der vorigen Nacht wieder zurück.

Wie nützlich ist im Ernstfall ein Sicherungsmedium? Gibt es dafür auch nach dem Brand noch ein Laufwerk im Handel? Wenn nicht, sollte ein Ersatzlaufwerk an sicherer Stelle hinterlegt werden.

Datensicherungs-Software

Linux und der Vorgänger UNIX sind von Haus aus mit sehr vielen unterschiedlichen Datensicherungstools ausgestattet, die unterschiedliche Strategien verwenden. Darüber hinaus gibt es weitere Tools und natürlich auch kommerzielle. In allen Fällen muss überlegt und vielleicht sogar praktisch erprobt werden, wie schnell man den Server ersetzen kann, wenn man nur noch die Medien besitzt, weil der Rechner mitsamt des Gebäudes abgebrannt ist.

Das Programm tar

Immer an Bord einer POSIX-Maschine. Optionen: Eine der Optionen cxt muss immer angegeben sein. Die Optionen müssen nicht unbedingt mit einem Minus versehen werden. Ursprünglich Tape-Archivierung. Ohne Option -f wird auf /dev/tape gesichert. Nach Konvention erhalten Tarball-Dateien die Extension .tar, wenn sie komprimiert sind .tgz oder .tar.gz Besondere Fähigkeiten: Sichert die POSIX-Eigenschaften. Kann so auch ein nicht POSIX-fähiges Medium als Sicherungsmedium verwenden. Wird bei der Option f als Zieladresse eine Netzwerkadresse angegeben, verwendet tar das SSH-Protokoll und sichert verschlüsselt über das Netzwerk. 
$ tar cfz server:dasi/montag.tgz .

Das Programm rsync

Nicht standardmäßig verfügbar, muss installiert werden: 
# apt install rsync
Sichern des lokale Verzeichniss data unter dem Benutzer user auf dem Host 192.168.109.199 im Verzeichnis /media/dasi: 
$ rsync -a data user@192.168.109.199:/media/dasi/data
Wird dieser Befehl wiederholt, wird der Ablauf deutlich schneller, weil nur die Dateien und Dateiteile, die sich geändert haben, gesichert werden. Auf dem Zielrechner entsteht im Verzeichnis /media/dasi/data die gleiche Dateistruktur wie auf dem lokalen Rechner unter data. Es gibt Fehlermeldungen oder sogar Abbrüche, falls POSIX-Eigenschaften auf dem Zielmedium nicht umsetzbar sind. rsync verwendet das SSH-Protokoll beim Sichern über das Netzwerk.

Die Programme dump und restore

Das Programm dump ist dafür geschaffen, komplette Dateisysteme auf ein Band zu sichern. Das ist zwar auch mit Datenpartitionen möglich, zielt aber natürlich vor allem auf das Dateisystem mit der Betriebssysteminstallation und -konfiguration. Ziel ist es, im Falle eines Rechnerausfalls möglichst schnell wieder den ursprünlichen Server wieder ins Rennen zu schicken.

dump beherrscht die inkrementelle Sicherung.

In der heutigen Zeit wird dump vermutlich eher seltener eingesetzt. Wenn es darum geht, einen Betriebssystemzustand zu sichern und schnell wieder herzustellen, wird man vermutlich eher eine virtuelle Maschine anlegen und diesen auf einer Linux-Plattform laufen lassen. Für den Fall eines Ausfalls wird dann die Datei der virtuellen Maschine gesichert und kann dann auf einem anderen Rechner schnell wieder in Betrieb gehen.

Inkrementelle Sicherung

Das Konzept der inkrementellen Sicherung sieht vor, dass beispielsweise einmal pro Woche am Wochenende eine vollständige Datensicherung erzeugt wird. Das dauert natürlich seine Zeit. An den Werktagen ist die Zeit knapper. So wird am Montag nur gesichert, was sich seit dem Wochenende geändert hat. Am Dientag werden nur die Unterschiede zu Montag gesichert und so fort.

Im Falle einer Wiederherstellung muss dann zunächst die Wochenendsicherung zurückgeholt werden. Darüber wird dann die Montagssicherung geladen und dann weiter jede inkrementelle Sicherung bis zum aktuellen Tag.

Natürlich müssen die Datensicherungstools eine inkrementelle Sicherung unterstützen. Der Vorgang verzögert die Rekonstruktion, ermöglicht aber die Beschleunigung der einzelnen Datensicherungen.

Zeitgesteuert mit cron

Datei in /etc/cron.d im crontab-Format erstellen. 
# Minute Stunde Tag(Monat) Monat  Tag(Woche)   User Kommando
# (0-59) (0-23) (1-31)     (1-12) (1-7; 1=Mo) 
0         4      *          *      *           root jedentag4uhr
0         9      1,15       *      *           root jeden1.und15.um9
0         2      *          *      1,2,3,4,5   root werktagsum2
Umgebung nicht vorhanden, weder PATH noch Home-Verzeichnis. Die Kommandos müssen also mit Pfad angegeben werden. Sicherungen über das Netzwerk können keine Passwörter abfragen. Lösung: Zertifikate (siehe später SSH) Fehler erscheinen zwar in der syslog. Was aber, wenn niemand hineinschaut? Lösung: Mail an das Konto des Administrator (siehe später Mailserver) \url{http://willemer.de/informatik/unix/unixcron.htm}

Datensicherung mit Datum im Dateiname

Die Datensicherung sollte nicht immer die Datensicherung des Vortages überschreiben. Dazu sollte der Dateiname das aktuelle Datum oder den Wochentag enthalten. 
date +"%U-%a-%Y_%m_%d-%H:%M"
Liefert die Wochennummer, den Wochentag, Jahr, Monat, Tag, Stunde und Minute. (siehe man date oder date --help) Um diese Ausgabe in einen Dateinamen zu bekommen, umschließt man sie mit Dollar und einer Klammer: 
$ touch dasi-$(date +"%U-%a-%Y_%m_%d-%H_%M").tgz
$ ls -l
... 0 Okt 17 10:14 dasi-42-Di-2023_10_17-10_14.tgz
Vorsicht bei /. Sie werden als Verzeichnis interpretiert. Löschen alter Datensicherungen, hier 7 Tage (siehe man find): 
$ find . -mtime +7 -name "*backup.tar" -exec rm {} \;

Aufräumen der Alt-Datensicherungen

Alte Datensicherungen werden irgendwann überflüssig, belegen aber wertvollen Speicherplatz auf dem Sicherungsmedium. Wenn das Medium erst einmal überfüllt ist, werden dort keine neuen Datensicherungen mehr gespeichert und das ist fatal.

Der folgende sehr einfache Ansatz schaut zunächst, ob es Datensicherungen gibt, die jünger als sieben Tage sind. Nur dann werden alle Datensicherungen gelöscht, die älter als sieben Tage sind.

Um Befehle auf Dateien anzuwenden, die ein gewisses Alter erreicht haben, bietet sich der Befehl find mit den Optionen mtime und exec an.

Im folgenden Beispiel befinden sich die Backups in einem Verzeichnis dasi und enden auf backup.tar. 

cd dasi
# Pruefe, ob es ein neues Backup gibt
BACKUP=$(find . -mtime -7 -name "*backup.tar")
# Nur wenn ein aktuelles Backup existiert, loesche alle alten
if [ $BACKUP ]
then
    find . -mtime +7 -name "*backup.tar" -exec rm {} \;
else
    echo "Es gibt kein neues Backup auf 193.175.188.253" | mutt -s "Backup-Rotate" -- root@zuhause.de
fi

Szenarien

Datenverluste trotz Datensicherung haben oft etwas mit menschlichem Versagen zu tun. Hier sind ein paar Szenarien aus der Praxis aufgeführt.

Szenario: Externes Medium

In einem Notariat wurde die Datensicherung des Servers auf externen USB-Laufwerken durchgeführt, die erst beim Wechsel des Mediums vom Server abgetrennt wurden. Auf Nachfrage stellte sich heraus, dass sich niemand wußte, wer eigentlich für den Wechsel des Mediums zuständig ist.

Der Server stand in der Küche, in der alle Mitarbeiter frühstückten. Die USB-Medien lagen offen neben dem Server.

Damit waren vermutlich die herumliegenden USB-Laufwerke nutzlos, weil die Datenbestände vermutlich veraltet waren.

Die angeschlossene USB-Festplatte würde bei einem Ransom-Virenausbruch verschlüsselt, weil sie durch das Virus als Laufwerk direkt erreichbar ist.

Darüber hinaus bestand das Risiko, dass jeder, der in die Küche gelangt, einfach die USB-Festplatte abziehen und in die Tasche stecken konnte und damit alle Daten des Notariats besaß.

Szenario: Samba-Laufwerke

In einem Softwarehaus waren alle Daten auf Netzwerklaufwerken verteilt und für jeden Mitarbeiter zugänglich abgelegt. Selbst der Git-Server arbeitete auf einer solchen Netzwerkfreigabe.

Die Sekretärin erhielt eine Mail mit einem Ransom-Virus im Anhang. Obwohl die Sekretärin sofort merkte, dass etwas faul ist, gelang es dem Virus schnell die Netzwerkplatten zu verschlüsseln.

Zum Glück wurden regelmäßig zeitnah Datensicherungen gemacht. Diese konnten sofort vom Netzwerk getrennt wurden.

Dennoch wurden die Mitarbeiter für zwei Tage nach Hause geschickt bis alle PCs neu installiert und die Datenbestände wiederhergestellt werden konnten.

Szenario: Cloud

Eine Elektromontagefirma sicherte alle Datenbestände unverschlüsselt in der Cloud. Damit sind die Daten aus dem Haus und gegen Brand und Geräteausfall gut gesichert.

Allerdings wurden die Daten unverschlüsselt abgelegt. Das amerikanische Recht schützt nur die Daten von US-Staatsbürgern. US-amerikanische Unternehmen sind verpflichtet, mit den Geheimsiensten zusammenzuarbeiten und dürfen dies nicht bekannt geben.

Man darf also annehmen, dass die NSA die Datensicherung bereits an interessierte US-Unternehmen weitergegeben haben.

Ein ähnliches Problem besteht bei allen Daten von Smartphones, die in der Cloud von Apple oder Google gesichert werden. Das ist standardmäßig der Fall und ist sehr angenehm beim Wechsel des Smartphones oder bei dessen plötzlichem Verlust. Die Daten des Smartphones sind allerdings für Apple und Google gewinnbringende Ware.