S3-Versionierung ist kein Backup: Buckets mit Object Lock richtig sichern

Freitag, 17:40 Uhr. Ein Aufräum-Job soll alte Exporte löschen, aber die Variable für das Präfix ist leer, und aus aws s3 rm s3://shop-media/$PREFIX --recursive wird ein Befehl für den ganzen Bucket. 180.000 Produktbilder sind weg. Die Versionierung ist an, nach zwei Stunden ist alles zurück. Das Team hatte Glück: Zurückholen hieß 180.000 Delete-Marker entfernen – mit genau dem Löschrecht, das ein Angreifer mit demselben Schlüssel auch gehabt hätte.

S3-Versionierung ist eine Bucket-Einstellung, die beim Überschreiben oder Löschen eines Objekts die vorherige Fassung als ältere Version im selben Bucket aufbewahrt. Ein Backup dagegen ist eine Kopie, die an einem anderen Ort liegt, für eine feste Zeit gehalten wird und sich von dem, wogegen sie schützt, nicht entfernen lässt.

Was S3-Versionierung schützt – und was nicht

Versionierung fängt die häufigsten Fehler ab: Wird ein Objekt überschrieben, bleibt die alte Fassung als Version erhalten; ein einfaches Löschen setzt nur einen Delete-Marker. Alles, was darüber hinausgeht, überlebt sie nicht:

• Den gelöschten Bucket. Ein Bucket lässt sich erst löschen, wenn er leer ist – aber wer Versionen löschen darf, kann ihn leeren. Danach sind alle Versionen weg.
• Den kompromittierten Schlüssel. Die meisten Anwendungsschlüssel dürfen löschen. Ein DeleteObject mit Versions-ID entfernt eine alte Fassung endgültig – per Skript Tausende in wenigen Minuten.
• Die falsche Lifecycle-Regel. Eine Regel mit NoncurrentDays 1, eigentlich zum Sparen gedacht, räumt jede alte Version einen Tag nach dem Überschreiben ab.
• Den Ausfall von Region oder Projekt. Die Versionen liegen in derselben Region, im selben Projekt und hinter derselben Abrechnung wie das Original.

Ist Replikation ein Backup?

Replikation kopiert neue Objekte automatisch in einen zweiten Bucket, oft in einer anderen Region. Das hilft bei einem Regionsausfall, aber sie überträgt, was geschrieben wird: Verschlüsselt eine Ransomware Ihre Dateien, landen die verschlüsselten Fassungen pünktlich auch im Ziel. Ob Delete-Marker mitgehen, hängt bei AWS von der Konfiguration ab – in der aktuellen Regelform standardmäßig nicht, zuschaltbar schon. Das endgültige Löschen einer bestimmten Version überträgt AWS bewusst nie, zum Schutz vor böswilligem Löschen.

Was Replikation nicht kennt, ist ein Wiederherstellungspunkt – „der Stand von Dienstagnacht“ für den ganzen Bucket. Und das Ziel gehört meist zum selben Konto, mit denselben Administratoren. Replikation macht Daten verfügbar, ein Backup macht sie wiederherstellbar.

Was ein echtes Bucket-Backup braucht

• Einen anderen Ort. Ein eigenes Scaleway-Projekt nur für Backups und eine andere Region als die Originale, etwa nl-ams für Buckets in fr-par.
• Einen Schlüssel, der nicht löschen kann. Der nächtliche Kopierjob schreibt mit einem Schlüssel, der lesen und schreiben darf, aber kein Löschrecht hat.
• Object Lock mit Aufbewahrungsfrist. Jede geschriebene Version ist bis zu einem Datum gesperrt; Löschen und Überschreiben werden abgewiesen.
• Wiederherstellungspunkte. Pro Lauf eine Liste, welche Version jedes Objekts zu diesem Stand gehört.
• Getestete Wiederherstellung und Alarme. Ein Backup zählt erst, wenn ein Restore funktioniert hat; ein ausgefallener Lauf muss auffallen.

Governance oder Compliance: welcher Object-Lock-Modus?

Object Lock arbeitet nach dem WORM-Prinzip (write once, read many) und setzt Versionierung voraus. Es kennt zwei Modi:

• Governance: Wer keine besondere Berechtigung hat, kann eine gesperrte Version weder löschen noch überschreiben. Berechtigte können die Sperre aufheben – bei AWS braucht das s3:BypassGovernanceRetention und einen ausdrücklichen Header.
• Compliance: Niemand löscht oder überschreibt eine gesperrte Version vor Ablauf der Frist, auch nicht der Eigentümer oder ein Administrator. Der Modus lässt sich nicht ändern, die Frist nicht verkürzen.

Governance ist der vernünftige Start: Es hält Fehler und gestohlene Schlüssel ab und lässt einen Notausgang, etwa wenn eine Löschpflicht auch die Backups erreichen muss. Compliance wählen Sie, wenn eine Vorgabe unlöschbare Kopien verlangt. Bei Scaleway lässt sich Object Lock nach dem Aktivieren nicht mehr abschalten.

Wie richte ich ein Bucket-Backup mit Object Lock ein?

Mit der AWS CLI gegen den S3-Endpunkt von Scaleway sieht der Kern so aus:

1. Ein eigenes Projekt für Backups anlegen und den Bucket mit Object Lock erstellen: aws s3api create-bucket --bucket media-backup --object-lock-enabled-for-bucket.
2. Eine Standardfrist setzen: put-object-lock-configuration mit "Mode": "GOVERNANCE", "Days": 30. Bei Scaleway geht das derzeit nur über die CLI oder andere S3-Werkzeuge, nicht in der Konsole.
3. Eine Lifecycle-Regel, die alte Versionen nach derselben Frist ablaufen lässt – sonst wächst der Speicher unbegrenzt.
4. Einen Backup-Schlüssel anlegen: eine IAM-Anwendung mit den Berechtigungssätzen ObjectStorageObjectsRead, ObjectStorageObjectsWrite und ObjectStorageBucketsRead im Backup-Projekt – ohne ObjectStorageObjectsDelete und ohne ObjectStorageBucketsDelete.
5. Jede Nacht nur Geändertes kopieren und pro Lauf ein Manifest schreiben: Objektschlüssel → Versions-ID.
6. Einen Alarm einrichten, wenn ein Bucket 36 Stunden lang kein erfolgreiches Backup hatte.
7. Einmal im Monat eine Stichprobe aus dem letzten Manifest zurücklesen und Größe und Prüfsumme vergleichen.

Die Schritte 1 bis 4 sind eine Stunde Arbeit, 5 bis 7 das eigentliche Projekt: ein Job, der zuverlässig läuft und beweist, dass seine Kopien lesbar sind.

Wie Clusterward S3-Backups umsetzt

Clusterward verwaltet die Buckets Ihrer Anwendungen unter Object Storage; dort legen Sie das Backup-Ziel einmal an: Anbieter, Region – ohne Vorgabe, Sie entscheiden –, Name des Backup-Buckets, Sperrmodus und Aufbewahrung von 7 bis 365 Tagen, Standard 30 Tage im Governance-Modus. Clusterward erstellt den Bucket mit Object Lock und Versionierung, liest die Einstellungen zurück, erzeugt einen eigenen Backup-Schlüssel ohne Löschrecht und schreibt damit ein Testobjekt. Teilt das Ziel Region oder Projekt mit einem Ihrer Buckets, sagt die Karte das.

Danach läuft jede Nacht für jeden Bucket mit eingeschaltetem Backup ein Lauf, der nur Geändertes kopiert und mit einem Wiederherstellungspunkt endet. Zurück geht es nur in einen neuen Bucket – der laufende wird nie angefasst – oder als einzelne Datei über einen Link, der fünf Minuten gilt. Einmal im Monat liest ein Restore-Test eine Stichprobe zurück und vergleicht Größe und Prüfsumme. Benachrichtigungen melden einen fehlgeschlagenen Lauf, einen Bucket ohne gutes Backup seit 36 Stunden und einen fehlgeschlagenen Test. Details stehen auf der Seite S3-Backups; wie sich das in ein ISO-27001-Audit fügt, steht unter Compliance & ISO 27001. Nach einem Tenant-Offboarding bleiben die Wiederherstellungspunkte bis zum Ablauf der Sperre, zusätzlich zum Archiv aus Backup vor dem Löschen.

Fazit

Versionierung ist eine gute erste Schicht gegen Tippfehler, aber kein Backup: Sie liegt im selben Bucket, im selben Projekt, hinter demselben Schlüssel. Ein Backup braucht einen anderen Ort, einen Schlüssel ohne Löschrecht, Object Lock mit fester Frist, Wiederherstellungspunkte und Tests, die beweisen, dass es funktioniert. Replikation ergänzt das, ersetzt es aber nicht.

Wollen Sie Ihre Buckets wirklich sichern? Beschreiben Sie uns, wo Ihre Daten heute liegen und wer welchen Schlüssel hat. Wir zeigen Ihnen, wie ein Backup mit Object Lock dazu passt. Frage stellen →

Quellen und weiterführende Links

• Scaleway-Doku: Object Lock verwenden (englisch)
• Scaleway-Doku: Amazon S3 und IAM-Berechtigungen (englisch)
• AWS-Doku: Object Lock (englisch)
• AWS-Doku: Was S3-Replikation überträgt (englisch)
• AWS-Doku: S3-Versionierung (englisch)