Object Storage bietet einige technische Features, die ohne Kontext auf den ersten Blick kompliziert und einzeln für sich überflüssig wirken können, sich kombiniert jedoch als sehr praktisch für bestimmte Szenarien erweisen, zum Beispiel für Immutable Backups mit S3.
In diesem praxisnahen Tutorial erfährst du, wie du die S3-Features Versioning, Object Locking, Retention und Compliance Mode einsetzen kannst, um Immutable Backups (unveränderliche Datensicherungen) im Object Storage zu erstellen.
Außerdem erhältst du einige Best-Practice-Empfehlungen, die dir zusätzlichen Schutz bei der Sicherung deiner Backups bieten.
Wann und warum Immutable Backups sinnvoll sind
Unveränderliche Backups bieten Schutz vor versehentlichem oder böswilligem Löschen während der Aufbewahrung – selbst dann, wenn die Zugangsdaten kompromittiert wurden. Neben dem Schutz vor dem Löschen besteht auch ein Schutz vor dem Überschreiben der Daten.
Das ist insbesondere dann sinnvoll, wenn regulatorische Anforderungen erfüllt werden müssen und nachgewiesen werden soll, dass die Speicherung der Backups auf dem WORM-Prinzip („write once, read many“) basiert.
Natürlich sollen die Backups in den meisten Fällen nicht für immer und ewig gespeichert werden. Häufig gilt es, eine bestimmte Aufbewahrungsfrist einzuhalten (z.B. 30 Tage), nach deren Ablauf die Backups wieder gelöscht werden dürfen.
S3-Features im Überblick
Nun gilt es zu klären, wie S3 genutzt werden kann, um Immutable Backups zu realisieren.
Im Folgenden erfährst du, was es mit den eingangs genannten S3-Features genau auf sich hat und wie diese miteinander in Beziehung stehen.
- Versioning
- Statt ein Objekt zu überschreiben, entstehen neue Versionen davon.
- Ältere Versionen des Objekts bleiben erhalten und können nur explizit gelöscht werden.
- Wird ein Objekt ohne Angabe der Version gelöscht, so wird lediglich ein „Delete Marker“ gesetzt.
- Object Lock
- Stellt sicher, dass Objektversionen bis zu einem bestimmten Zeitpunkt nicht gelöscht oder überschrieben werden können.
- Kann nur beim Erstellen eines Buckets aktiviert werden.
- Kann später nicht mehr deaktiviert werden.
- Greift nur, wenn Versioning aktiv ist. Ohne Versioning ist Object Lock wirkungslos.
- Wirkt auf Objekte erst, wenn eine Retention oder ein „Legal Hold“ gesetzt wurde.
- Retention
- Besteht aus einem Zeitraum und einem Modus.
- Der Zeitraum gibt an, wie lange Objekte nicht gelöscht werden können.
- Einmal gesetzt, kann der Zeitraum nur verlängert – nicht mehr verkürzt – werden.
- Der Modus legt fest, ob bestimmte Ausnahmen für das Löschen vor Ablauf des Retention-Zeitraums gelten sollen.
- Compliance Mode
- Ein Retention-Modus, der keine Ausnahmen für das Löschen oder Überschreiben von Objekten zulässt.
- Selbst User mit Admin-Berechtigungen können die Objekte vor Ablauf des Retention-Zeitraums nicht löschen.
Empfehlungen
Bevor wir mit der Umsetzung beginnen, hier noch ein paar Best Practices für einen noch besseren Schutz deiner Daten.
- Isolation je Workload
- Pro Team/Anwendung einen separaten Bucket anlegen, um Berechtigungen klar abzugrenzen und spätere Audits zu vereinfachen.
- Least Privilege umsetzen
- Verwende getrennte User-Accounts mit möglichst eingeschränkten Berechtigungen für den jeweiligen Einsatzzweck.
- Beispiel: Ein User mit Schreibrechten für das Erstellen von Backups und einen separater User nur mit Leserechten für Restores.
- Verschlüsselung at rest
- Objekte beim Upload per SSE-C verschlüsseln lassen.
- Vor dem Upload wird ein Secret generiert, das im S3-Request für den Upload oder Download übergeben wird, um die Daten zu ver- bzw. entschlüsseln.
Schritt für Schritt zum Immutable Backup
Im folgenden Beispiel erstellen wir einen Bucket mit Object Lock, Versioning und einer Standard-Retention von 30 Tagen im Compliance Mode. Wer das Ganze zunächst nur testen möchte, kann die Standard-Retention seines Buckets auf einen Tag setzen.
Anschließend laden wir eine Backup-Datei hoch und prüfen, ob wir diese mit einem unserer S3-User löschen können.
Falls noch nicht vorhanden, richte dir zunächst ein Object Storage Projekt bei MyNWS ein.
Logge dich hierzu auf MyNWS ein und klicke in der linken Navigationsleiste auf „+ Object Storage“. Bestätige anschließend die Projekterstellung mit einem Klick auf „Create“.
Als nächstes erstellen wir einen User, den wir „Backups“ nennen. Nach der Erstellung erhalten wir automatisch einen Access Key und einen Secret Key für S3. Diese Zugangsdaten müssen wir für spätere Nutzung sicher aufbewahren (z.B. in einem zentralen Passwortmanager).
Gemäß Best-Practice-Empfehlungen erstellen wir aus dem „Backups“-User zwei Subuser:
- Der erste Subuser heißt „Backup-Creator“ und erhält Schreibrechte (
write). Der Key-Type bleibt auf „S3“. Die Zugangsdaten (Access Key und Secret Key) sollten wir sofort sichern.
- Der zweite Subuser heißt „Backup-Restorer“ und erhält nur Leserechte (
read). Auch hier setzen wir den Key-Type auf „S3“ und sichern die Zugangsdaten direkt.
Das ist auch schon alles, was in MyNWS vorbereiten werden muss. Weiter geht es auf der Command Line.
CLI Client installieren und einrichten
In diesem Tutorial verwenden wir den MinIO-Client, um Immutable Backups einzurichten. Es gibt natürlich auch andere S3-kompatible Clients und SDKs, die wir nutzen könnten, bspw. s3cmd.
Wir laden uns den Client (hier für Linux) herunter und bereiten ihn für die Ausführung vor:
wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
mv mc /usr/local/bin/Nach der Installation des MinIO-Clients erstellt man drei Aliases.
Den ersten Alias erstellen wir mit den Zugangsdaten des Hauptnutzers (Backups).
mc alias set backups https://storage.netways.cloud <BACKUPS_ACCESS_KEY> <BACKUPS_SECRET_KEY> --api S3v4Den nächsten Alias benötigen wir später für die Uploads unserer Backups.
mc alias set backup-creator https://storage.netways.cloud <CREATOR_ACCESS_KEY> <CREATOR_SECRET_KEY> --api S3v4Den letzten Alias nutzen wir später für den Restore unserer Backups.
mc alias set backup-restorer https://storage.netways.cloud <RESTORER_ACCESS_KEY> <RESTORER_SECRET_KEY> --api S3v4Für die Einrichtung nutzen wir vorerst allerdings nur den Alias „backups“.
Schritt 1: Bucket erstellen
Nun erstellen wir einen Bucket mit Object Lock und Versioning. Da die Namen von Buckets einzigartig sein müssen, fügen wir dem Namen eine Zufallszahl hinzu.
BUCKET_NAME="backups-immut-testing-$RANDOM"
mc mb --with-lock --with-versioning backups/$BUCKET_NAMEZur kurzen Gegenprüfung, ob das Versioning nun aktiv ist:
mc version info backups/$BUCKET_NAMEDie Rückgabe sollte ähnlich wie folgt lauten:
backups-setup/backups-immut-testing-18509 versioning is enabledSchritt 2: Retention setzen
Jetzt setzen wir die Retention. Danach erhalten neue Objekte automatisch 30 Tage Schutz im Compliance-Modus, ohne dass beim Upload Zusatzangaben nötig sind.
mc retention set --default compliance 30d backups/$BUCKET_NAMEIn diesem Fall lautet die Rückgabe wie folgt:
Object locking 'COMPLIANCE' is configured for 30DAYS.Schritt 3: Upload
Jetzt nutzen wir unseren „backup-creator“-Alias, um ein Backup hochzuladen. Im Beispiel nutze ich eine Datei namens backup.tar.gz.
Außerdem verwende ich die Server-Side-Encryption (SSE-C, Parameter --enc-c), um die Datei zu verschlüsseln. Den Schlüssel (ENCRYPTION_KEY) dafür erstellen wir vorab. Diesen sollten wir uns natürlich abspeichern, um die Datei später wieder herunterladen zu können.
TARGET_PATH="$BUCKET_NAME/backups/$(date --iso-8601)/backup.tar.gz"
ENCRYPTION_KEY=$(openssl rand -hex 32)
mc put --enc-c "backup-creator/$TARGET_PATH=$ENCRYPTION_KEY" ./backup.tar.gz backup-creator/$TARGET_PATHDer Versuch, nach dem Upload mit dem gleichen Alias die Retention-Informationen abzufragen, scheitert, da der verwendete User nur Schreibrechte hat.
mc retention info backup-creator/$TARGET_PATH
Unable to get object retention on `backup-create/backups-immut-testing-18509/backups/2025-10-08/backup.tar.gz`: Access Denied.Verwenden wir stattdessen den „backups“-Alias, so bekommen wir die gewünschten Informationen.
mc retention info backups/$TARGET_PATH
Name : backups-setup/backups-immut-testing-18509/backups/2025-10-08/backup.tar.gz
Mode : COMPLIANCE, expiring in 29 daysSchritt 4: Löschversuch
Zu diesem Zeitpunkt sollten Löschversuche noch scheitern, ganz egal, mit welchem User wir es versuchen.
Versuchen wir es zuerst mit dem Alias ‚backup-restorer‘. Da dieser nur Leserechte hat, scheitern wir bereits an mangelnden Schreib- bzw. Löschrechten.
mc rm --versions --force backup-restorer/$TARGET_PATHRückmeldung:
mc: <ERROR> Failed to remove `backup-restore` recursively. Access Denied.
Mit dem Alias ‚backup-creator‘ können wir ebenfalls nicht löschen.
mc rm --versions --force backup-creator/$TARGET_PATHAntwort:
mc: <ERROR> Failed to remove `backup-create/backups-immut-testing-18509/backups/2025-10-08/backup.tar.gz` recursively. Access Denied.
Und selbst unser Haupt-User (Alias ‚backups‘), kann das Backup aktuell nicht löschen.
mc rm --versions --force backups/$TARGET_PATHAusgabe:
mc: <ERROR> Failed to remove `backups` recursively. AccessDeniedSchritt 5: Download testen
Zur Bestätigung, dass das Backup weiterhin verfügbar ist, listen wir die Versionen des Objekts auf und laden anschließend die ursprüngliche Version herunter.
mc ls --versions backup-restorer/$TARGET_PATHMeine Ausgabe:
[2025-10-08 11:27:50 UTC] 1.0GiB STANDARD 4sSduZoDnWRnF4qXf61AAY2OKQvgU5U v1 PUT backup.tar.gz
Die lange Zeichenkette nach dem Wort „STANDARD“ ist die Version-ID. Diese kopiert man sich und startet dann den Download.
Hierfür verwende ich nun den Alias „backup-restorer“ und gebe den ENCRYPTION_KEY zur Entschlüsselung an.
mc get --enc-c "backup-restorer/$TARGET_PATH=$ENCRYPTION_KEY" \
--version-id 4sSduZoDnWRnF4qXf61AAY2OKQvgU5U backup-restorer/$TARGET_PATH /tmp/backup-download.tar.gzDer Download der Datei startet. Das Backup kann also noch heruntergeladen werden.
...-08/backup.tar.gz: 1.00 GiB / 1.00 GiB ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 10.09 MiB/s 1m41sDamit sind wir auch schon an unserem Ziel angelangt.
Einfacher als gedacht: Immutable Backups mit S3 Object Storage
S3 Object Lock bietet eine tolle Grundlage um Immutable Backups zu realisieren, die vor Löschung und Manipulation schützen. Das Setzen von Retention-Zeiträumen garantiert eine Compliance-konforme Aufbewahrung. Wichtig ist hierfür, Versioning und Object Lock beim Erstellen von Buckets zu aktivieren.
Als Ausblick sind Lifecycle-Rules ein wertvolles Mittel, um nach Ablauf der Retention automatisch alte Versionen und Delete-Marker aufzuräumen. Sie helfen, Speicherplatz zu sparen und das Datenmanagement zu automatisieren — ohne den Schutz während der Aufbewahrungszeit zu beeinträchtigen. Beispiele, wie sich Lifecycle-Rules erstellen lassen, findest du in unseren Docs.
0 Kommentare