True IT Stories

Das Backup war frisch, die Daten nicht

TL;DR

  1. Die gerettete Sicherung war vom Vorabend, die Daten darin sechs Wochen alt. Der Nextcloud-Client war verbunden, hat aber nichts mehr hochgeladen.
  2. Ein grünes Backup sagt nichts über den Datenstand. Es sichert auch einen verwaisten Server jede Nacht zuverlässig.
  3. Den letzten echten Schreibvorgang prüfen: jüngste Änderungszeit im Dateisystem und PUT/MOVE pro Tag im Webserver-Log.

Nach einem Ransomware-Angriff haben wir einen weiteren Server aus einer Kette getroffener Sicherungen wiederhergestellt. Die ganze Geschichte steht in Der Decryptor läuft, und die großen VMs bleiben zu . Die Sicherung war vom Abend vor dem Angriff, Veeam meldete Success, die VM bootete. Ein guter Moment.

Dann haben wir nachgesehen, was drin ist. Die jüngste Datei war sechs Wochen alt.

Was passiert war

Auf dem Server lief eine Nextcloud, die Dateien kamen per Desktop-Client. Irgendwann wurde nicht mehr dort gearbeitet, sondern auf einem anderen Server. Abgeschaltet hat das niemand. Der Client blieb verbunden und fragte jeden Tag Dutzende Male nach Änderungen. Hochgeladen hat er seit Wochen nichts mehr.

Das Backup lief jede Nacht und war jede Nacht grün. Es hat jede Nacht denselben alten Stand gesichert.

Die Bruchstelle

Ein Backup-Job prüft, dass gesichert wurde. Nicht, ob sich seit gestern etwas geändert hat. Ein verwaister Server erzeugt also perfekte Sicherungen von veralteten Daten. Wer im Ernstfall „Backup von gestern“ sagt, verspricht einen Datenstand, den es nicht gibt.

In unserem Fall hat das nichts Schlimmeres angerichtet, die aktuellen Daten lagen ohnehin woanders. Aber genau das muss man vor dem Satz „Die Daten sind gerettet“ wissen.

Wie man den letzten echten Schreibvorgang findet

Im Dateisystem. Die jüngsten Änderungszeiten zeigen, wann zuletzt geschrieben wurde:

find /daten -type f -printf '%T+ %p\n' | sort | tail -5

Unter Windows:

Get-ChildItem D:\Daten -Recurse -File |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 5 LastWriteTime, FullName

Vorsicht: Die Änderungszeit (mtime) kann der Client beim Hochladen auf die des Originals setzen. Die ctime unter Linux zeigt, wann die Datei auf diesem Server angefasst wurde (%C+ statt %T+). Weichen beide stark ab, gilt die ctime.

Im Webserver-Log. Abfragen beweisen nichts, der Client fragt auch, wenn er nichts schreibt. Hochladen sind schreibende Anfragen, bei Nextcloud und anderen WebDAV-Ablagen PUT und MOVE. Pro Tag gezählt:

grep -hE '"(PUT|MOVE) ' access.log* | awk '{print substr($4,2,11)}' | sort | uniq -c

Der jüngste Tag in dieser Liste ist der Datenstand. Achtung, sort sortiert hier nach Text, nicht nach Datum, also das jüngste Datum selbst heraussuchen. Bei uns lag er sechs Wochen vor dem Angriff, während die Abfragen bis wenige Tage davor weiterliefen.

Was wir prüfen würden

  • Nach jeder Wiederherstellung zuerst den Datenstand, dann die Erfolgsmeldung. Die jüngste Datei nennen, nicht das Datum der Sicherung.
  • Datenablagen überwachen, nicht nur Backup-Jobs. Eine Warnung, wenn in einer aktiven Ablage tagelang nichts Neues entsteht, kostet wenig.
  • Umzüge zu Ende bringen. Wird anderswo gearbeitet, die alte Ablage bewusst stilllegen oder als Archiv kennzeichnen. Sonst hält jeder sie für aktuell.

Ein grünes Backup sagt, dass die Sicherung funktioniert hat. Was gesichert wurde, sagt es nicht.