Zusammenfassung

  • Der dokumentierte Standard gilt für neue Objekte; ihre Aufbewahrungsdauer beginnt jeweils mit der Erstellung. Eine gemeinsame Dauer ist deshalb kein gemeinsames Ablaufdatum für einen wachsenden Bestand.
  • Objektbezogene Enddaten und unabhängig gesetzte Legal Holds bilden verschiedene Beschränkungen. Zeitablauf allein beweist weder die Aufhebung eines Holds noch die Löschung einer Version.
  • Aktivierte Objektsperren können am Bucket nicht deaktiviert werden, und die Versionierung lässt sich danach nicht aussetzen. Diese Bindung ist nicht gleichbedeutend mit ewiger Aufbewahrung jedes Objekts.

Dauer und Stichtag beantworten verschiedene Fragen

Eine Einkaufsentscheidung kann mit einer einfachen Vorgabe beginnen: Alle neu archivierten Unterlagen sollen dieselbe Aufbewahrungsdauer erhalten. Einfach bleibt damit die Regel, nicht zwangsläufig der spätere Bestand. Werden Objekte zu verschiedenen Zeitpunkten erstellt, beginnen ihre dokumentierten Fristen nicht gemeinsam. Dieses Beispiel ist hypothetisch; es beschreibt keinen gemessenen Kundenbestand.

Scaleways Anleitung zur Objektsperre, geprüft am 21. Mai 2026, legt den Beginn der Standarddauer auf die Erstellung des jeweiligen Objekts. Sie unterscheidet Angaben in Tagen oder Jahren von einem absoluten objektbezogenen Endzeitstempel. Der Bucket-Standard bestimmt somit, welche Regel neue Bindungen erzeugt. Er ist keine vollständige Liste der bereits vorhandenen Enddaten.

Zudem kann eine objektbezogene Einstellung laut Anleitung den Standard für dieses konkrete Objekt überschreiben. Eine einzige Bucket-Konfiguration beweist folglich nicht den Schutzstatus jeder Version. Aus der Anwendung auf neue Objekte folgt auch kein Nachweis einer rückwirkenden Sperre für alles zuvor Vorhandene. Bestehende Einstellungen müssen gesondert bekannt sein; ein Neustart der Uhr beim Lesen oder Umbenennen wird hier nicht unterstellt.

Der gekaufte Schutz begrenzt spätere Entscheidungen

Im Compliance-Modus kann eine geschützte Version während der angegebenen Frist nicht gelöscht oder überschrieben werden, auch nicht durch Eigentümer oder Administratoren. Moduswechsel und Verkürzung der Frist sind laut detaillierter Anleitung ausgeschlossen. Governance erhält dagegen für entsprechend berechtigte Nutzer eine Möglichkeit zur Änderung und gezielten Löschung.

Diese Wahl verteilt die künftige Verfügungsgewalt unterschiedlich. Ein Unternehmen kann eine stärkere Schranke wünschen, gerade weil ein späterer Administrator eine geschützte Aufzeichnung nicht entfernen können soll. Die Einschränkung ist dann Teil des Nutzens. Sie wird jedoch auch relevant, wenn sich ein legitimer betrieblicher Plan später ändert.

Für Objektsperren verlangt Scaleway Versionierung. Ist die Sperre am Bucket aktiviert, kann sie nicht deaktiviert und die Versionierung nicht ausgesetzt werden. Das bindet den Betriebsmodus des Behälters. Es besagt weder, dass jede einzelne Version unendlich lange aufbewahrt wird, noch dass alle denselben Parametern unterliegen.

Die Ebenen dürfen nicht zusammenfallen. Die dauerhafte Bucket-Entscheidung betrifft das aktivierte Regime. Die nicht verkürzbare Objektfrist betrifft eine bestimmte geschützte Version bis zu ihrem Datum. Wer beides pauschal als „permanente Aufbewahrung“ bezeichnet, verliert gerade die Bedingungen, die der Einkauf bewerten müsste.

Ein Legal Hold wartet nicht auf dieselbe Uhr

Der dokumentierte Legal Hold ist ein unabhängiger Ein-oder-Aus-Zustand ohne Ablaufdatum. Ein Nutzer mit den erforderlichen Berechtigungen muss ihn ausdrücklich aufheben. Fristgebundene Aufbewahrung und Hold können gleichzeitig gelten. Das Ende der einen Beschränkung belegt nicht das Ende der anderen.

Ein Objekt könnte daher in einem beispielhaften Bestand seine Aufbewahrungsfrist überschritten haben und trotzdem unter einem aktiven Hold stehen. Umgekehrt beweist ein aufgehobener Hold nicht, dass eine separate Frist abgelaufen oder zulässig geändert worden ist. Diese logischen Beziehungen sind keine Beobachtung realer Rückstände bei Scaleway.

„Legal Hold“ ist hier ein Produktbegriff. Der Artikel legt keine gesetzliche Mindestdauer und keine Rechtsgrundlage für bestimmte Unterlagen fest. Ein Anbieterbeispiel kann eine technische Einstellung erläutern, aber nicht die rechtliche Pflicht des Käufers bestimmen.

Sichtbarkeit ist nicht der Bestand an geschützten Versionen

Die Fehlerbehandlung zur Objektlöschung, geprüft im Juli 2025, erklärt, dass eine Löschung ohne Versionskennung im versionierten Bucket einen Löschmarker erzeugt; die betroffenen Objekte bleiben vorhanden. Governance-Umgehung und Versionskennung werden dort als gesonderte Anfragebedingungen behandelt. Die Beschreibung dieser Grenze ist keine Aufforderung, Kundendaten zu verändern.

Die Sicherungsdokumentation ergänzt, dass Versionierung neue Versionen unter demselben Namen erzeugen kann. Ein Name oder eine gewöhnliche Auflistung repräsentiert daher nicht die vollständige aufbewahrte Geschichte. Sichtbarer Zustand, Existenz einer konkreten Version und die dafür geltenden Berechtigungen sind verschiedene Informationen.

Eine nur auf sichtbaren Elementen beruhende Bestandsmeldung könnte die verbleibenden Bindungen falsch darstellen. Das ist ein möglicher Messfehler, kein Beleg verlorener geschützter Daten oder falscher Kundenabrechnungen. Ein Löschmarker beweist keine physische Vernichtung. Der umgekehrte Nachweis vorhandener Bytes beweist ebenso wenig eine erfolgreiche Wiederherstellung der Anwendung.

Die Aufbewahrung ersetzt keinen Wiederanlauf

Scaleways Modell geteilter Speicherverantwortung ordnet den Infrastrukturbetrieb dem Anbieter zu und lässt Lebenszyklusentscheidungen, Versionsmanagement, Kontinuitätsmaßnahmen und Integritätsarbeit beim Kunden. Beschriebene Aufzeichnungen auf Anfrage sowie kundenseitige Prüfpflichten sind keine gemessene Wiederherstellungsleistung für ein bestimmtes Archiv.

Der Schutz einer Version vor einer definierten Änderung bestätigt nicht, dass sämtliche benötigten Anwendungsteile konsistent erfasst wurden. Er validiert auch keine Ersatzumgebung. Wer „aufbewahrt“ mit „wiederherstellbar“ gleichsetzt, verlangt von einer Löschbeschränkung den Nachweis eines anderen Nutzens.

Die öffentlichen Texte nennen außerdem eine größere Systemgrenze. Die Konzeptseite und die Sicherungsanleitung vom April 2026 führen die Löschung des gesamten Kontos als Ausnahme neben dem Fristablauf auf. Die Kontoschließungsanleitung vom Februar 2026 beschreibt die dauerhafte Löschung von Ressourcen und Sicherungen bei erhaltenem Konsolenzugang und unterscheidet diesen Vorgang von der Löschung persönlicher Daten.

Wie eine aktuell gesperrte Version dabei genau behandelt wird, ist durch diese Untersuchung nicht geklärt. Es wurde kein Konto geschlossen und kein Umgehen getestet. Daraus folgt weder eine bewiesene Schwachstelle noch ein nachgewiesenes Versagen der objektbezogenen Zusage. Der Anbieter sollte den Geltungsbereich erläutern; die Administratorbeschränkung darf nicht stillschweigend zu einer ungeprüften Garantie für jede Kontolebenszyklusaktion erweitert werden.

Der Standard ist ein Eingangswert, nicht das Ergebnis

Der Einkauf muss fragen, welche spätere Entscheidung für welchen Datensatz bis wann beschränkt ist. Ein einheitlicher Standard kann sinnvoll sein und dennoch unterschiedliche offene Bindungen erzeugen. Neue Erstellungszeitpunkte, explizite Enddaten und Holds machen den relevanten Bestand feiner als den Bucket.

Die sechs Quellen beziffern weder Gesamtrechnung, Einsparung, Vorfallrisiko noch Wiederherstellungserfolg. Sie stützen eine präzisere Schlussfolgerung: Die einfache Konfiguration beseitigt nicht die Vielfalt der übernommenen Verpflichtungen. Stärkerer Schutz muss nach der tatsächlich entstehenden Grenze der Verfügungsgewalt bewertet werden, nicht nach einem kleineren Bildschirmbestand oder einer allein verstrichenen Uhr.

Quellen