Zusammenfassung

  • Die projektweite Backup Compliance Policy verbietet das Löschen geschützter Snapshots und die nachträgliche Verkürzung ihrer Aufbewahrung. Auch ein Projekteigentümer bekommt dafür keine gewöhnliche Ausnahme.
  • Nach dem Beenden eines geschützten Clusters bleiben bestehende Snapshots gemäß Richtlinie erhalten. Eine zusätzliche Aufbewahrungsphase kann länger dauern als der Löschschutz; während dieser Verlängerung dürfen passend berechtigte Nutzer die Kopien löschen.

Ein Chef, eine Rechnung, kein Papierkorb

Wer ein Projekt besitzt, möchte gewöhnlich auch entscheiden, wann dessen Akten verschwinden. MongoDB Atlas verkauft eine Funktion, die genau an dieser Stelle widerspricht. Mit eingeschalteter Backup Compliance Policy bleibt die geschützte Vergangenheit auch vor ihrem eigenen Verwalter sicher.

Die Richtlinie untersagt jedem Nutzer unabhängig von seiner Rolle, einen geschützten Snapshot zu löschen oder dessen Aufbewahrungszeit nach der Erstellung zu verkürzen. Cloud Backup lässt sich ebenfalls nicht einfach abschalten. Die Sicherungspolitik eines einzelnen Clusters darf die Mindestanforderungen des Projekts nicht unterschreiten.

Diese Beschränkung hat einen einleuchtenden Wert: Ein überhasteter Administrator soll die Rückkehrmöglichkeit nicht zusammen mit den aktuellen Daten beseitigen können. Wer dessen Konto übernimmt, soll möglichst wenig zusätzliche Macht über die gesicherte Vergangenheit erhalten. Die Firma bestellt dafür eine Bremse, die auch dann noch greifen soll, wenn der nächste Verantwortliche es eilig hat.

MongoDB schreibt ausdrücklich, dass diese Wahl Möglichkeiten zur Senkung der Backup-Speicherkosten begrenzt. Genau an dieser Stelle gehört der Budgetverantwortliche mit an den Tisch. Sonst bestellt die Sicherheit die Bremse und der Einkauf sucht später vergeblich nach dem Lösehebel.

Der Projektordner bestimmt die Verpflichtung

Die Dokumentation nennt M10 und größere dedizierte Cluster als Voraussetzung. Hier geht es um entsprechende Atlas-Core-Umgebungen. Die Mindestregel gilt für das Projekt: Bestehende Cluster werden auf das erforderliche Niveau gebracht, neue übernehmen es ebenfalls. Wer für einen Cluster mehr verlangt, kann über diesen Mindeststandard hinausgehen.

Daraus folgt eine Entscheidung, die in einer kurzen Versuchsbeschreibung leicht fehlt: In welches Projekt kommt das Experiment? Läuft ein kurzlebiger Test unter einer langen projektweiten Aufbewahrung, kann seine gesicherte Geschichte den Test um ein Vielfaches überdauern. Der Standort im Verwaltungsmodell legt dann schon einen Teil der späteren Kosten fest.

Eine geringere Häufigkeit auf Clusterebene verändert nur künftige Sicherungen und muss weiter den Projektstandard erfüllen. Das vorhandene Operationsprotokoll bleibt im ursprünglichen Fenster. Bereits geschützte Fristen lassen sich nachträglich nicht durch einen hübscheren Plan verkürzen. Für die Kostenbetrachtung braucht es deshalb zwei Ansichten: neue Verpflichtungen und den verbleibenden Bestand.

Der Cluster geht, sein Nachlass bleibt

Der Beendigungsablauf hält diese Trennung fest. Ist die Schutzrichtlinie aktiv, bewahrt Atlas die vorhandenen Snapshots nach dem Clusterende gemäß Backup-Richtlinie auf. Bei Cloud Backup ohne diese Schutzrichtlinie gibt es dagegen eine ausdrückliche Auswahl, vorhandene Snapshots zu behalten. Ohne Cloud Backup steht diese Auswahl nicht zur Verfügung.

Bei Atlas Core bleibt das für zeitpunktgenaue Wiederherstellung nutzbare Operationsprotokoll in statischem Zustand erhalten, bis es dafür nicht mehr verwendbar ist. Es handelt sich um den vorhandenen Verlauf. Ein beendeter Cluster erzeugt keine fortlaufend neuen Geschäftsvorgänge.

Der Nachlass hält auch Verwaltungsteile fest. Solange unter der Richtlinie Snapshots vorhanden sind, lässt sich das Projekt nicht löschen. Können nicht sämtliche Projekte entfernt werden, bleibt auch die Organisation bestehen. Laut Dokumentation dient der Name des beendeten Clusters zur Zuordnung der Snapshots; ein neuer Cluster mit demselben Namen ist deshalb ausgeschlossen.

Zum Abschalttermin gehört folglich eine Übergabe. Jemand übernimmt die verbleibenden Kopien, deren Ablaufdaten und deren Speicherrechnung. Die abgerechneten aktiven Clusterstunden und der verbliebene Backup-Speicher sind unterschiedliche Positionen. Eine laufende Rechnung für die Geschichte belegt keinen weiterlaufenden Rechner.

Leer heißt auch: keine alten Sicherungen

Die Richtlinie lässt einen geregelten Weg zur Deaktivierung offen. In einem nicht leeren Projekt beantragt die benannte Sicherheits- oder Rechtsvertretung Unterstützung und durchläuft eine eingehende Prüfung. MongoDB Support genehmigt den Antrag; danach können Projekteigentümer die Richtlinie deaktivieren. Administratorrolle und Antragsberechtigung sind damit getrennt.

Für tatsächlich leere Projekte gilt eine Ausnahme. Weder aktive noch pausierte Cluster dürfen vorhanden sein, ebenso wenig aufbewahrte Snapshots früher beendeter Cluster. Dann darf ein Organisations- oder Projekteigentümer die Richtlinie deaktivieren. Eine leere Liste laufender Datenbanken reicht bei erhaltenen Sicherungen noch nicht.

Auch die benannte Person gehört zum Betriebsmodell. Die Einrichtung verlangt ihren Namen und die E-Mail-Adresse, die sie für das Supportportal verwendet. Eine falsche Adresse muss mit Support korrigiert werden. Unternehmen brauchen deshalb eine Nachfolge, wenn die zuständige Person wechselt. Die technische Bindung hat keinen Anlass, sich nach den Laufzeiten von Arbeitsverträgen zu richten. Konkrete Bearbeitungszeiten für Kundenanträge veröffentlicht die hier verwendete Dokumentation nicht.

Mehr Aufbewahrung kauft nicht automatisch mehr Schutz

Bei der zusätzlichen Snapshot-Aufbewahrung werden Kopien über den Schutzzeitraum hinaus gespeichert. In dieser zusätzlichen Phase können Nutzer mit passender Rolle sie löschen. Ist auch diese Verlängerung zu Ende, löscht Atlas automatisch.

Eine Kopie kann also weiter existieren, nachdem ihre besondere Löschsperre geendet hat. Für eine Firma, die vor böswilligen Löschungen schützen will, zählt das Ende der Sperre. Für eine Firma, die anschließend noch auf ältere Daten zugreifen möchte, zählt zusätzlich das Ende der Aufbewahrung. Ein einziger Balken mit der Gesamtdauer verschluckt diese Unterscheidung.

Überschneiden sich zwei Zeitpläne bei demselben Snapshot, gilt die längere Aufbewahrung. MongoDB zeigt das am Beispiel einer täglichen Sicherung für zwei Tage und einer wöchentlichen Samstagskopie für drei Wochen. Die am Samstag gemeinsam erzeugte Sicherung folgt der Wochenregel. Wer nur die kürzere Zeile liest, plant ihre Entfernung zu früh.

Die Speicherrechnung zählt anders als die Inventarliste

Die Kostenbeschreibung für dedizierte Cluster erklärt, warum sich die Rechnung kaum aus Snapshot-Anzahl mal aktueller Datenbankgröße ableiten lässt. Gewöhnliche Cloud Backups arbeiten überwiegend inkrementell; entscheidend sind die gemeldeten gespeicherten Mengen und die Region. Die Darstellung eines GB-Monat-Tarifs in täglichen GB-Tagen ist keine Verdoppelung der Rechnung. Continuous Cloud Backups verwenden eigene Tarife und berücksichtigen Snapshots samt internem Operationsprotokoll.

Bestimmte Konfigurationswechsel, Ausweichvorgänge oder Wartung des zugrunde liegenden Cloud-Anbieters können mehrere vollständige Snapshots nötig machen. Umgekehrt bleiben Daten erhalten, die nach dem Löschen einer Kopie noch von anderen referenziert werden. Ein Snapshot weniger verspricht daher keine bestimmte Ersparnis. Dafür braucht es die tatsächlich abgerechneten Mengen, Regionen, Fristen und geltenden Tarife.

Der Einkauf sollte die Funktion an ihrer wirklichen Zusage messen: Die Firma bindet sich für einen gewählten Zeitraum gegen das schnelle Löschen. Das kann ein guter Kauf sein. Auf dem Bestellzettel fehlt dann allerdings noch ein Name, wenn niemand die Verantwortung für das verbleibende Archiv übernimmt.