Ein Backup-Plan für Ihren Server

Modul 8: Backups und Überwachung · Lesezeit: 11 Minuten

Lernziel: Nach dieser Lektion können Sie für Ihren eigenen Server einen Backup-Plan erstellen: was Sie sichern, wo, wie oft und wie lange, und wie Sie sicher wissen, dass die Wiederherstellung funktioniert.

Kernbegriffe: 3-2-1-Regel, Snapshot, Backup des Anbieters, eigenes Backup außerhalb des Anbieters, RPO, RTO, Datenbank-Dump (mariadb-dump, pg_dump), Konfiguration in /etc, Docker-Volumes, Verschlüsselung, Ransomware, append-only, Wiederherstellungstest

Warum ein Plan und nicht einfach "es gibt doch ein Backup"?

Fast jeder, der einen Server verloren hat, dachte, es gäbe ein Backup. Dann stellt sich heraus, dass es nur das Betriebssystem enthält und nicht die Datenbank, oder es liegt auf demselben Server, der jetzt weg ist, oder es wurde von derselben Ransomware verschlüsselt, oder niemand kennt das Passwort. Ein Backup ist erst dann etwas wert, wenn Sie es wiederherstellen können. Deshalb beginnen Sie mit einem Plan und enden mit einem Test.

Ein Plan beantwortet fünf Fragen:

1. Was muss wiederhergestellt werden können?
2. Wie viele Daten dürfen Sie verlieren? (RPO)
3. Wie schnell muss alles wieder funktionieren? (RTO)
4. Wo liegen die Kopien, und wie viele gibt es?
5. Wie wissen Sie, dass es funktioniert?

Was muss wiederhergestellt werden können?

Ein Server besteht aus Schichten. Nicht jede Schicht muss ins Backup:

Achten Sie besonders auf Datenbanken. Eine laufende Datenbank schreibt ständig. Wenn Sie die Dateien einer laufenden MariaDB oder PostgreSQL kopieren, kann eine beschädigte Kopie entstehen. Erstellen Sie deshalb zuerst einen Dump: eine konsistente Momentaufnahme als Datei, die Sie anschließend ins Backup aufnehmen.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump hieß früher mysqldump; dieser Befehl funktioniert meistens auch noch.) Läuft die Datenbank in einem Container, gehen Sie genauso mit docker compose exec vor (Lektion 9.4).

RPO und RTO: Wie viel dürfen Sie verlieren?

Zwei Begriffe aus der Berufspraxis helfen bei der Entscheidung:

• RPO (Recovery Point Objective): Wie viel Zeit an Daten dürfen Sie höchstens verlieren? Ein tägliches Backup um 03:00 bedeutet: Stürzt der Server um 22:00 ab, verlieren Sie fast einen ganzen Tag. Für einen Onlineshop mit Bestellungen ist das zu viel; für einen Blog, der sich einmal pro Woche ändert, völlig in Ordnung.
• RTO (Recovery Time Objective): Wie lange darf es dauern, bis alles wieder funktioniert? Ein vollständiges Backup des Anbieters ist in Minuten zurückgespielt; einen neuen Server aufzubauen und alles von Hand wiederherzustellen, kann Stunden dauern.

Notieren Sie beide Werte für Ihren eigenen Server. Sie bestimmen, wie oft Sie ein Backup erstellen und wie Sie es aufbewahren.

Snapshot, Backup des Anbieters, eigenes Backup

Bei einem VPS haben Sie meist drei Arten von Sicherheitsnetz. Sie ähneln sich, schützen aber vor unterschiedlichen Dingen.

1. Der Snapshot. Eine Momentaufnahme der gesamten virtuellen Festplatte, erstellt im Panel Ihres Anbieters. Schnell erstellt, schnell zurückgespielt. Ideal direkt vor einem Upgrade (Lektion 4.3). Aber: Ein Snapshot liegt bei den meisten Anbietern auf demselben Speicher wie Ihr Server. Geht dieser Speicher kaputt oder verlieren Sie Ihr Konto, ist auch der Snapshot weg. Außerdem bewahren Sie einen Snapshot nicht lange auf: Er wächst mit allen späteren Änderungen mit. Ein Snapshot ist kein Backup.

2. Das Backup des Anbieters. Viele Anbieter erstellen (gegebenenfalls als Option) automatisch jeden Tag eine Kopie Ihres gesamten Servers auf einem anderen Speicher. Bei WebOké ist das zum Beispiel ein tägliches Backup des gesamten VPS, das sieben Tage aufbewahrt wird; bei anderen Anbietern funktioniert es ähnlich, mit eigenen Fristen. Das ist eine gute zweite Schicht gegen defekte Hardware und gegen Ihre eigenen Fehler von gestern. Es bleibt aber ein einziger Anbieter: Ihr Konto, Ihre Zahlung, deren Störung. Und die Wiederherstellung betrifft meist den ganzen Server auf einmal.

3. Ihr eigenes Backup, außerhalb des Anbieters. Eine Kopie Ihrer Daten bei einem anderen Anbieter oder an einem anderen Ort, die Sie selbst erstellen und verwalten (Lektion 8.2). Das ist die Schicht, die übrig bleibt, wenn alles andere schiefgeht.

Die 3-2-1-Regel

Eine verbreitete Faustregel:

• 3 Kopien Ihrer Daten (das Original plus zwei Backups);
• auf 2 verschiedenen Arten von Speicher oder Systemen;
• davon 1 an einem anderen Standort.

Für einen VPS kann das so aussehen: die Daten auf dem Server, das tägliche Backup des Anbieters und ein verschlüsseltes eigenes Backup mit restic auf Speicher bei einem anderen Anbieter. Eine moderne Ergänzung lautet: Mindestens eine Kopie darf von jemandem, der den Server übernimmt, nicht gelöscht werden können (offline oder append-only, Lektion 8.2). Ransomware auf einem Server sucht aktiv nach Backups, um auch diese zu verschlüsseln oder zu löschen. Ein Backup, das der Server selbst löschen darf, bietet dagegen keinen Schutz.

Verschlüsselung und das Passwort Ihres Backups

Ein Backup bei einem anderen Anbieter muss verschlüsselt sein: Es enthält Kundendaten, Passwörter und Schlüssel. restic (Lektion 8.2) verschlüsselt standardmäßig. Damit entsteht jedoch ein neues Risiko: das Passwort Ihres Backups. Haben Sie es verloren, ist das Backup unbrauchbar. Und liegt es nur auf dem Server, den Sie verloren haben, ebenso.

Bewahren Sie das Passwort deshalb auch außerhalb des Servers auf: in Ihrem Passwortmanager und gegebenenfalls auf Papier in einem Tresor. Dasselbe gilt für die Zugangsdaten des Speichers, auf dem Ihr Backup liegt.

Die Wiederherstellung testen

Der wichtigste Teil des Plans. Ein Wiederherstellungstest bedeutet: Sie spielen ein Backup tatsächlich zurück, an einem Ort, an dem es nichts beschädigt, und prüfen, ob das Ergebnis funktioniert.

• Klein und häufig: eine Datei oder einen Ordner nach /tmp/terug wiederherstellen und vergleichen (diff). Zum Beispiel monatlich.
• Groß und gelegentlich: einen kompletten neuen Testserver aus dem Backup aufbauen, die Datenbank importieren, die Website starten. Zum Beispiel einmal im Jahr oder bei jeder größeren Änderung. Das ist zugleich die Übung für den Ernstfall (Lektion 10.3).

Notieren Sie, wie lange es gedauert hat: Das ist Ihre tatsächliche RTO.

Aufbewahrungsfristen

Bewahren Sie nicht nur das letzte Backup auf. Bemerken Sie erst nach zwei Wochen, dass eine Datei beschädigt oder gelöscht wurde, brauchen Sie ein Backup von vor drei Wochen. Ein verbreitetes Schema: sieben tägliche, vier wöchentliche und sechs monatliche Versionen. restic regelt das mit forget (Lektion 8.2). Denken Sie auch an die DSGVO: Personenbezogene Daten bewahren Sie nicht länger auf als nötig, auch nicht in Backups. Legen Sie Ihre Aufbewahrungsfristen schriftlich fest.

In der Praxis

Nutzen Sie den Snapshot Ihres Anbieters direkt vor riskanten Änderungen und löschen Sie ihn danach; lassen Sie das tägliche Backup des Anbieters aktiviert, falls es eines gibt; und erstellen Sie zusätzlich Ihr eigenes verschlüsseltes Backup von Daten und Konfiguration bei einem anderen Anbieter. Bei WebOké heißt das im VPS-Bildschirm Snapshots und Backups; bei anderen Anbietern sind Namen und Fristen anders, das Prinzip ist aber dasselbe. Ein Hostingpaket oder ein verwalteter Dienst hat oft andere Vereinbarungen: Prüfen Sie, was in Ihrem Fall geregelt ist.

Zusammenfassung

• Ein Backup ist erst etwas wert, wenn die Wiederherstellung funktioniert; beginnen Sie mit einem Plan und enden Sie mit einem Test.
• Sichern Sie vor allem Daten und Konfiguration: Datenbanken als Dump, /etc, Websites, Docker-Volumes, Compose-Dateien.
• Legen Sie RPO (wie viel dürfen Sie verlieren) und RTO (wie schnell muss es funktionieren) fest.
• Snapshot (derselbe Speicher, kurz), Backup des Anbieters (anderer Speicher, derselbe Anbieter) und ein eigenes Backup außerhalb des Anbieters sind drei verschiedene Schichten; folgen Sie der 3-2-1-Regel mit mindestens einer Kopie, die der Server selbst nicht löschen kann.
• Verschlüsseln Sie, bewahren Sie das Backup-Passwort außerhalb des Servers auf und testen Sie die Wiederherstellung klein und häufig, groß und gelegentlich.

Quiz

Aufgabe

Aufgabe O8.1: Ihr Backup-Plan. Erstellen Sie für Ihren eigenen Server einen Backup-Plan auf einer Seite: was wiederhergestellt werden muss (pro Schicht), Ihre RPO und RTO, welche Kopien Sie haben (Snapshot, Anbieter, eigenes Backup) und wo, Ihre Aufbewahrungsfristen, wo das Backup-Passwort liegt und wann Sie einen Wiederherstellungstest durchführen. Füllen Sie das Formular aus; nach dem Absenden sehen Sie einen Beispielplan, mit dem Sie Ihren eigenen Plan vergleichen können.

Weiterführende Informationen

• Snapshots und Backups Ihres VPS
• Backup-Strategie: Die 3-2-1-Regel für Ihr eigenes Unternehmen
• Hoe maak ik een back-up van mijn MySQL-database?
• Im Kurs „Sicher online“: die Lektionen über die 3-2-1-Regel und Backups, die Ransomware überstehen.
• MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html