Eine Sicherung schützt vor allem, dessen Schicksal sie nicht teilt. Auf derselben Platte übersteht sie eine gelöschte Datei, aber keinen Plattenausfall. Auf demselben Server übersteht sie einen Plattenausfall, aber kein übernommenes Konto. Die Frage lautet immer: welches Schicksal teilt diese Kopie?

Drei-zwei-eins, im Klartext

  • Drei Kopien — die laufende und zwei Sicherungen.
  • Zwei Arten von Speicher — nicht zwei Ordner auf einer Platte.
  • Eine woanders — eine andere Maschine, idealerweise ein anderer Anbieter.

„Woanders“, geordnet danach, wie viel es schützt

  • Eine andere Platte im selben Server — gegen einen Plattenausfall, und gegen nichts sonst.
  • Ein anderer Server beim selben Anbieter — gegen einen Serverausfall. Nicht gegen eine Kontosperre, nicht gegen einen Fehler mit anbieterweitem Zugriff.
  • Ein ganz anderer Anbieter — alles oben Genannte, plus den Tag, an dem das Konto selbst das Problem ist.
Wenn eine Übernahme Ihres Servers auch die Sicherungen löschen kann, sind sie keine Verteidigung gegen eine Übernahme. Das Sicherungsziel sollte vom Server aus nur beschreibbar sein: hinzufügen ja, entfernen nein.

Nur-Schreiben in der Praxis

# object storage with an append-only policy, or
# a pull model: the BACKUP server connects to the site and takes a copy,
# so the site never holds credentials that can delete anything

Das Pull-Modell ist das stärkste und das am seltensten benutzte: Nichts auf dem Webserver erreicht die Sicherungen überhaupt, also kann nichts, was dort geschieht, sie anrühren.

Verschlüsseln Sie sie und bewahren Sie den Schlüssel anderswo auf

gpg --symmetric --cipher-algo AES256 backup.tar.gz
Ein Schlüssel, der nur auf dem gestorbenen Server lag, ist kein Schlüssel. Schreiben Sie ihn auf und bewahren Sie ihn dort auf, wo er nichts mit dem Server zu tun hat.
Testen Sie ausdrücklich die auswärtige Kopie. Die lokale funktioniert meistens; die entfernte ist die, aus der noch nie jemand wiederhergestellt hat.