So testen Sie einen Restore, nicht nur ein Backup

Jede Backup-Konsole der Welt kann Ihnen eine Spalte grüner Häkchen zeigen. Keine davon kann Ihnen sagen, ob Ihr Unternehmen nach einer schlechten Nacht bis zur Mittagspause wieder läuft. Das kann Ihnen nur ein Restore sagen, und der einzige Restore, dem Sie trauen können, ist einer, den Sie bereits gemacht haben. So testen Sie Restores, damit das Ergebnis etwas bedeutet.

Was ein grüner Job tatsächlich beweist

Ein erfolgreicher Backup-Job beweist, dass ein Job gelaufen ist, Daten gelesen und sie irgendwohin geschrieben hat, ohne einen Fehler, den die Software erkannt hat. Er beweist nicht, dass die Daten vollständig sind, dass die Maschine, auf die es Ihnen ankommt, im Job enthalten war, dass die Kopie zurückgelesen werden kann oder dass die Anwendung daraus startet.

Drei Dinge sind zu testen: Abdeckung (wird wirklich alles gesichert, was gesichert werden soll), Wiederherstellbarkeit (kann die Kopie gelesen und gestartet werden) und Zeit (wie lange eine Wiederherstellung wirklich dauert). Die meisten Organisationen testen keines davon nach Plan.

Schritt eins: Abdeckung gegen die Realität prüfen

Backup-Jobs werden zu einem Zeitpunkt definiert. Die Infrastruktur ändert sich weiter. Eine neue virtuelle Maschine neben den alten, eine Datenbank, die auf einen neuen Host umgezogen ist, ein umbenannter Server: jedes davon kann aus jedem Job herausfallen, ohne dass ein einziger Fehler gemeldet wird.

Vergleichen Sie also die Liste dessen, was existiert, mit der Liste dessen, was geschützt ist. Exportieren Sie das Inventar aus der Stelle, die weiß, was läuft, dem Hypervisor, der Cloud-Plattform oder dem DCIM, und die Liste der geschützten Objekte aus dem Backup-System, und vergleichen Sie beide:

sort -u running-inventory.txt > running.sorted
sort -u protected-objects.txt > protected.sorted
comm -23 running.sorted protected.sorted   # running, but not protected
comm -13 running.sorted protected.sorted   # protected, but no longer running

Die erste Liste ist die gefährliche. Die zweite ist Ballast, der sie verdeckt. Jeder Eintrag der ersten Liste braucht eine Entscheidung: in einen Job aufnehmen, oder schriftlich festhalten, dass er bewusst kein Backup hat und warum.

Schritt zwei: auf mehr als einer Ebene wiederherstellen

Wiederherstellbarkeit hat Ebenen, und jede Ebene fängt Probleme, die die darunter übersieht.

Dateiebene. Stellen Sie eine Stichprobe von Dateien an einem anderen Ort wieder her und vergleichen Sie sie per Checksumme mit der Quelle oder einer bekannt guten Kopie. Das fängt unlesbare Medien und unterbrochene Ketten inkrementeller Backups.

Maschinenebene. Starten Sie einen ganzen Server oder eine virtuelle Maschine aus dem Backup. Das fängt fehlende Boot-Volumes, Treiber und die Platte, die stillschweigend aus dem Job ausgeschlossen wurde. Die meisten Enterprise-Backup-Plattformen, darunter Veeam, können eine Maschine genau zu diesem Zweck direkt aus dem Backup-Repository in einem isolierten Lab starten.

Anwendungsebene. Beweisen Sie, dass die Anwendung aus der wiederhergestellten Kopie funktioniert. Für eine Datenbank heißt das: sie startet, besteht ihre eigene Konsistenzprüfung und enthält die neuesten Datensätze, die Sie für den Zeitpunkt des Backups erwarten:

# MySQL or MariaDB
mysqlcheck --all-databases --check
mysql -e "SELECT MAX(created_at) FROM orders;"

# PostgreSQL
pg_amcheck --all
psql -c "SELECT max(created_at) FROM orders;"

Für Backup-Werkzeuge auf Dateiebene gibt es Integritätsprüfungen, die die gespeicherten Daten zurücklesen, zum Beispiel borg check --verify-data auf einem Borg-Repository.

Schritt drei: in ein Lab wiederherstellen, nicht in die Produktion

Eine wiederhergestellte Maschine ist eine Kopie der Produktion, mit den Adressen, Zugangsdaten, geplanten Jobs und dem ausgehenden Mailverkehr der Produktion. Bringen Sie sie im echten Netzwerk hoch, und sie kann Anfragen beantworten, die für den Live-Server bestimmt waren, Kunden einen Schwung doppelter E-Mails schicken oder den Abrechnungslauf von gestern Nacht ein zweites Mal ausführen.

Restore-Tests gehören deshalb in ein isoliertes Netzwerk ohne Route zur Produktion und ohne Route ins Internet. Bevor Sie in diesem Lab eine Anwendung starten, deaktivieren Sie den Scheduler und den Mailversand auf der wiederhergestellten Kopie. Machen Sie daraus einen schriftlichen Schritt des Tests, damit niemand daran denken muss.

Schritt vier: die Zeit messen

Die Wiederherstellungszeit auf dem Papier ist eine Schätzung. Die, die zählt, ist gemessen: von dem Moment, in dem jemand den Restore beschließt, über das Finden des richtigen Wiederherstellungspunkts, das Bewegen der Daten, das Starten der Dienste und die Prüfung der Anwendung bis zur ersten erfolgreichen echten Transaktion. Große Restores werden oft durch einen Durchsatz begrenzt, den niemand gemessen hat, oder durch einen Schritt, den nur eine Person beherrscht. Wer die ganze Abfolge stoppt, findet beides.

Schritt fünf: aufschreiben

Führen Sie zu jedem Test einen kurzen Eintrag:

• Datum, und wer ihn durchgeführt hat.
• Was wiederhergestellt wurde, aus welchem Wiederherstellungspunkt.
• Welche Ebene getestet wurde: Datei, Maschine oder Anwendung.
• Benötigte Zeit, von Anfang bis Ende.
• Alles, was fehlgeschlagen ist, Sie überrascht hat oder Wissen erforderte, das nirgends aufgeschrieben ist.
• Was daraufhin geändert wurde.

Auch das Design darunter zählt

Tests beweisen, dass die Backups heute existieren und funktionieren. Das Design entscheidet, ob sie nach einem schlechten Tag noch existieren. Die wichtigste Regel: Backups werden gezogen. Das Backup-System greift in die Produktion hinein und holt sich, was es braucht. Die Produktion hat keinen Netzwerkpfad zum Backup-System und keine Zugangsdaten dafür. Dann kann ein Eindringling, der einen Produktionsserver kontrolliert, die Backups dieses Servers nicht erreichen, um sie zu löschen. Append-only-Zugriff für Werkzeuge auf Dateiebene ist ein zweites Schloss, und die Historie im Repository bedeutet, dass eine Kopie von vor dem Problem weiterhin existiert.

Wie wir es machen

Unsere Backups sind von Grund auf pull-only und werden auf den Firewall-Appliances durchgesetzt; nur das Management-Netzwerk kann Backup- und Wiederherstellungssysteme erreichen. Wir verwenden Veeam für virtuelle Maschinen, physische Server und SQL-Server, dazu einen deduplizierenden Backup-Hub, der Datei- und Datenbankdaten von Linux-Systemen mit eingeschränkten Append-only-Schlüsseln zieht. Die Abdeckung wird gegen das Live-Inventar geprüft, Zeitpläne werden aus gemessenen Laufzeiten festgelegt, und vollständige Restores laufen bis zu wöchentlich.

Wenn Sie noch nie einen vollständigen Restore Ihres wichtigsten Systems gestoppt haben, fangen Sie damit an, und wir helfen Ihnen gern bei der Planung.

CTA

Mit einem Ingenieur sprechen

Related

Verwandt: Disaster Recovery und standortübergreifende Replikate · Storage-Replikation zwischen Athen und Amsterdam · NAS-Dateidienste, NFS und SMB