Drum prüfe, wer Backups macht

Kein Backup, kein Mitleid ist ja auch eher so ein Machospruch aus der IT. Als ob User per se zu doof sind.

In unserem Alltag haben wir viel zu oft davon Kenntnis erlangt, dass ein Unternehmen zwar Backups erstellt, im Fall der Fälle dann aber feststellen musste, dass sie sich nicht wiederherstellen lassen. Mal waren die Backups auf demselben System, das gerade abgeraucht ist oder das Speichermedium war nicht mehr lesbar. In einem Fall haben sich alle auf die eingestellte Automatikverlassen, allerdings vergessen, diese auch zu aktivieren.

Backups sind individuell konfigurierbar und ermöglichen die Wiederherstellung auf App-Ebene und als vollständige Wiederherstellung. Gerade der zweite Verwendungszweck hilft ungemein, wenn das gesamte System auf eine neue Instanz umgezogen werden soll.

Backups haben zusätzlich die Möglichkeit, vollständig verschlüsselt zu werden. Damit sind die sensiblen Daten auf Speichersystemen auch vor einem Datenabfluss gesichert, sollte das Backupmedium in falsche Hände geraten. Relevant ist allerdings, dass das Verschlüsselungspasswort natürlich den üblichen Kriterien für sichere Passwörter entspricht und sicher für die spätere Verwendung abgelegt wird. Kein Encryption-Key, kein Mitleid könnte also der neuste Machospruch werden. Gewarnt: Es gibt tatsächlich keine Chance Backups wiederherzustellen, wenn der Encryption-Key nicht vorliegt.

Wenn initial eine Backupstrategie umgesetzt und scharfgeschaltet wurde, sollte sowieso jedes Mal ein vollständiger Restore durchgeführt werden, um sich der Strategie - auch im Sinne des Desaster-Recoverys - zu vergegenwärtigen. Ab und an erwischte ich mich, dass ich zwar der Recovery-Strategie vertraute, mir aber nicht in der Übernahme eines Encryption-Keys in das entsprechende Formularfeld. Zweifel des Neurotikers, nennt sich das in anderen Kontexten.

Um jetzt nicht ein vollständiges Recovery durchführen zu müssen, gibt es einen einfachen Trick, um das Encryption-Passwort zu überprüfen. (Zeit ist ja Geld).