Versionierung hält alte Stände im selben Bucket, im selben Projekt, mit demselben Schlüssel – ein Backup ist das nicht. Clusterward kopiert jeden Bucket jede Nacht in einen Backup-Bucket mit Object Lock, am besten in einem eigenen Scaleway-Projekt und einer anderen Region. Jede Nacht ist ein Wiederherstellungspunkt, standardmäßig 30 Tage aufbewahrt und jeden Monat getestet.
Ein S3-Backup ist eine nächtliche Kopie jedes Buckets, den Clusterward verwaltet, in einen Backup-Bucket mit Object Lock. Den Backup-Bucket legen Sie einmal auf der S3-Seite an; danach sind die Backups für jeden Bucket an – auch für Buckets, die später dazukommen. Kopiert wird nur, was sich geändert hat, und gelöschte Objekte bleiben für die Aufbewahrungszeit wiederherstellbar.
Löschen Sie den Bucket, verlieren Sie den Schlüssel oder fällt die Region aus, gehen die Versionen mit. Ein Backup liegt woanders, wird für eine feste Zeit gehalten und lässt sich von dem, wogegen es schützt, nicht entfernen. Genau das fragt ein ISO-27001-Audit unter A.8.13.
| Merkmal | Versionierung | S3-Backup in Clusterward |
|---|---|---|
| Ort | derselbe Bucket, dasselbe Projekt | eigener Backup-Bucket, am besten eigenes Projekt und andere Region |
| Wer kann löschen | jeder mit dem Schlüssel des Buckets | niemand mit dem Backup-Schlüssel – er hat kein Löschrecht |
| Region fällt aus | Original und Versionen weg | Kopie in der anderen Region |
| Aufbewahrung | bis jemand aufräumt | feste Frist, 7 bis 365 Tage |
| Nachweis | keiner | Wiederherstellungstests und CSV für das Audit |
Ein eigenes Scaleway-Projekt als S3-Provider registrieren. Sein Schlüssel braucht einmal IAM-Manager-Rechte.
S3 → Backups → „Set up backups“: Provider, Region, Bucket-Name, Sperre und Tage. Eine Region ist nicht vorbelegt – Sie entscheiden.
Bucket mit Object Lock und Versionierung, Aufbewahrung, Aufräumregeln, eigener Backup-Schlüssel und ein Testobjekt – dann „Ready“.
Jeder Bucket bekommt seinen Lauf; am Ende steht ein Wiederherstellungspunkt mit jedem Objekt dieser Nacht.
Beide Modi sperren jede Kopie bis zum Ende ihrer Aufbewahrung. Sie unterscheiden sich darin, ob ein Administrator des Backup-Projekts eine Kopie vorher entfernen kann. Über „Change retention…“ ändern Sie die Tage und wechseln von Governance zu Compliance; Compliance lässt sich nur verlängern, nie verkürzen oder zurücknehmen.
| Sperre | Wer eine gesperrte Kopie löschen kann | Wann wählen |
|---|---|---|
| Governance | niemand mit dem nächtlichen Backup-Schlüssel; ein Administrator des Backup-Projekts in der Scaleway-Konsole | der Standard – erlaubt, eine Löschanfrage auch in den Backups umzusetzen |
| Compliance | niemand – nicht Clusterward, kein Administrator, nicht der Scaleway-Support –, bis die Aufbewahrung endet | wenn eine Vorgabe unlöschbare Kopien verlangt; Löschanfragen greifen dann erst mit dem Ablauf |
Kopiert wird, was neu ist oder sich in Größe oder Prüfsumme geändert hat. Unverändertes verweist auf frühere Nächte.
Ein im Bucket gelöschtes Objekt bleibt für die Aufbewahrungszeit wiederherstellbar.
Den nächtlichen Schlüssel legt Clusterward eigens an; er kann schreiben, aber nichts löschen.
Objekte bis zur S3-Grenze von 5 TB: über 2 GiB in Teilen, jeder Teil wird einzeln wiederholt.
„Bucket backup failed“ bei einem Fehler, „Bucket backup missing“, wenn ein Bucket 36 Stunden kein gutes Backup hatte.
Liegen Buckets in der Region oder dem Projekt des Backups, nennt die Karte sie – ein Ausfall träfe beide.
„Backup history…“ am Bucket listet jede Nacht als Wiederherstellungspunkt. „Restore into a new bucket…“ kopiert diese Nacht in einen neuen, privaten Bucket – der laufende Bucket wird nie angefasst. Jedes Objekt kommt mit genau dem Stand dieser Nacht zurück, mit Inhaltstyp und Metadaten; auf Wunsch nur ein Ordner.
Meist geht es um eine gelöschte Datei: „Download a file…“ sucht die Dateien einer Nacht nach Name oder Pfad und lädt eine über einen Link herunter, der fünf Minuten gilt.
Ein Backup zählt erst, wenn eine Wiederherstellung geklappt hat. Einmal im Monat liest Clusterward aus dem jüngsten Wiederherstellungspunkt jedes Buckets eine Stichprobe zurück und vergleicht Größe und, wo vorhanden, Prüfsumme. Ein Test liest nur und schreibt nirgendwohin; „Test restore“ startet einen sofort.
| Was | Wie |
|---|---|
| Stichprobe | das neueste und das größte Objekt (bis 100 MiB) plus Zufall – bis 50 Objekte oder 500 MiB |
| Prüfung | Größe muss passen, Prüfsumme wo vorhanden |
| Fehlschlag | „Bucket restore test failed“ an Ihre Kanäle |
| Nachweis | „Download evidence…“: CSV jedes Backups, jeder Wiederherstellung und jedes Tests, bis 400 Tage |
| Protokoll | jeder Download steht im Audit-Log |
Wie Buckets, Provider und Schlüssel entstehen, beschreibt Object Storage. Datenbanken, Festplatten und frühere Versionen sichert Clusterward auf anderen Wegen – den Überblick gibt Backups & Wiederherstellung.
Der Backup-Nachweis ist auch einer der Berichte der Compliance-Seite, die Bucket-Backups und Wiederherstellungstests als ISO-27001-Prüfungen zeigt.
Buckets, eigene IAM-Schlüssel pro Anwendung und Bucket-Policies.
Zu Object StorageDatenbanken, Festplatten, Buckets und frühere Versionen im Überblick.
Zu BackupsLive-Prüfungen, Berichte und das Compliance-Paket für Ihr Audit.
Zur Compliance-SeiteIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir richten ein Backup-Ziel mit Object Lock ein, spielen eine Nacht in einen neuen Bucket zurück und laden den Nachweis für Ihr Audit herunter.
