Zusammenfassung

  • Fly.io nennt 24 Stunden nach der Löschung als Abruffenster für die ID eines gelöschten Volumes. Eine bereits gesicherte ID lässt sich weiter zum Auffinden noch aufbewahrter Snapshots verwenden.
  • Snapshots bleiben standardmäßig fünf Tage erhalten; einstellbar sind ein bis sechzig Tage. Geänderte Fristen gelten nur für neue Snapshots.
  • Die Stilllegung sollte Kennungen und tatsächliche Ablaufdaten übergeben. Das Ende der Volume-Gebühr und das Ende der gespeicherten Rückkehrmöglichkeit sind getrennte Entscheidungen.

Die Fristverlängerung erreicht die falsche Generation

Fünf Tage wirken knapp, sechzig Tage beruhigend. Bei Fly.io kann der Wechsel zwischen beiden Zahlen trotzdem nichts an der Kopie ändern, die ein Team gerade retten möchte. Eine geänderte Aufbewahrungsdauer gilt laut Dokumentation nur für neue Snapshots. Bestehende behalten ihre bisherige Frist.

Wer vor einer Stilllegung die Einstellung verlängert, hat damit die Zukunft neu bestellt. Die Vergangenheit wird nicht nachgeliefert. Für den geplanten Rückweg zählen Erstellungszeit und Frist des tatsächlich vorhandenen Snapshots.

Daneben läuft eine kürzere Uhr. Die ID eines gelöschten Volumes lässt sich laut Wiederherstellungsanleitung nur während der ersten 24 Stunden nach der Löschung abrufen. Hat das Team die Kennung bereits, kann es damit weiterhin die Snapshots finden, solange deren Aufbewahrung läuft.

Der Lagerbestand und der Schalter für einen neuen Abholschein schließen also nicht zwangsläufig gleichzeitig. Ein kleiner Verweis kann länger nützlich sein als die Oberfläche, aus der er stammt.

Was bei einer Löschung jeweils endet

Fly Volumes sind lokaler persistenter Speicher auf einem bestimmten physischen Host. Zerstört ein Kunde ein Volume, bleibt es 24 Stunden im Zustand pending_destroy, bevor es endgültig gelöscht wird. Bei einer von Fly.io vorgenommenen Migration auf einen anderen Host bleibt das Quellvolume dagegen eine Woche in diesem Zustand.

Der Anlass unterscheidet die Fristen. Aus der Migrationswoche ein allgemeines Kundenrecht nach eigener Löschung zu machen, würde sechs Tage erfinden. In einem Wiederherstellungsplan sind erfundene Tage besonders preiswert und besonders nutzlos.

Snapshots folgen nochmals eigenen Regeln. Tägliche automatische Aufnahmen sind standardmäßig aktiv. Die übliche Aufbewahrung beträgt fünf Tage und lässt sich auf ein bis sechzig Tage einstellen. Eine Löschung des Volumes startet für alte Snapshots keine neuen fünf Tage.

Der dokumentierte Weg führt von der gespeicherten Volume-ID zu einem vorhandenen Snapshot und von dort zu einem neuen Volume, das mindestens so groß ist wie das ursprüngliche. Das Ende der Ausgangsressource, die Abrufbarkeit ihrer Kennung und das Ablaufdatum eines Datenabbilds gehören damit auf verschiedene Zeilen.

Eine beauftragte Aufnahme ist noch kein Bestand

Auch eine manuell ausgelöste Aufnahme braucht Ausführung. Der Snapshot geht durch Warten und Laufen, bevor er als erstellt gilt. Eine Bestätigung, dass die Aufnahme geplant wurde, beschreibt Arbeit in der Warteschlange. Darauf sollte keine Stilllegung ihre letzte Rückkehrmöglichkeit gründen.

Ähnlich begrenzt wirkt das Abschalten automatischer Snapshots. Es beendet die künftigen täglichen Aufnahmen, entfernt bestehende aber nicht sofort. Diese laufen nach ihren eigenen Fristen aus.

Für den Käufer ergibt sich daraus eine einfache Disziplin: den Bestand prüfen, nicht nur die Einstellung. Welche Kopie existiert, wann wurde sie aufgenommen, welche Frist gilt für sie und wer kann sie finden? Eine freundlich aussehende Zahl im Konfigurationsfeld beantwortet davon erstaunlich wenig.

Zudem kann eine tägliche Aufnahme Schreibvorgänge seit dem letzten Aufnahmezeitpunkt verpassen. Längere Aufbewahrung hält vorhandene Vergangenheit länger fest; sie fängt keine nie aufgenommenen Transaktionen nachträglich ein. Häufigkeit und Dauer sind unterschiedliche Bestellungen.

Zwei Kostenstellen, eine Übergabe

Fly.io berechnet Volumes zeitanteilig nach Stunden. Auch unverbundene Volumes und solche an angehaltenen Machines kosten Geld. Im Zustand pending_destroy entstehen keine Volume-Gebühren mehr.

Snapshot-Speicher wird separat zeitanteilig abgerechnet, nach Abzug des Freibetrags und auf Grundlage inkrementell gespeicherter Änderungen. Ein stillgelegtes Volume kann somit seinen eigenen Kostenlauf beendet haben, während gespeicherte Snapshots noch eine andere Position darstellen. Das Konto ist durch den einen Statuswechsel nicht automatisch kostenfrei.

Daraus folgt kein vernünftiger Grund, alte Ressourcen unbegrenzt stehen zu lassen. Es folgt ein Grund für eine präzise Übergabe. Das Geschäft legt fest, bis wann eine Rückkehr sinnvoll sein muss. Der technische Verantwortliche ordnet diesem Wunsch eine reale Kopie mit realem Ablaufdatum zu. Eine zur Wiederherstellung berechtigte Person erhält die Referenzen.

Das kleine Paket enthält Volume-ID, Zusammenhang mit App und Organisation, Snapshot-ID, Aufnahmezeit, Zustand und tatsächliche Frist. Es bleibt auffindbar, wenn die ursprüngliche Ressource aus dem gewöhnlichen Bestand verschwunden ist. Ein Eintrag in der privaten Terminalhistorie des ausgeschiedenen Projektleiters wäre dafür ein ehrgeizig schlechtes Ablagesystem.

Die Kennung zeigt den Weg, sie erteilt keine Rechte

Eine gespeicherte ID ersetzt keine Zugriffsberechtigung. Sie beweist auch nicht die Vollständigkeit der Daten. Nach dem Erstellen eines neuen Volumes folgen Anschluss, Anwendungsstart und fachliche Prüfung. Diese Arbeit gehört in das verfügbare Zeitfenster.

Die öffentlichen Unterlagen nennen keine garantierte Wiederherstellung durch den Support bei verlorener Kennung; eine solche Zusage würde das wirtschaftliche Risiko verändern. Der beschriebene reguläre Weg reicht bereits aus, um das Sichern der Referenz vor der Löschung zu begründen.

Der RIPE-NCC-Mitgliedseintrag bestätigt die Identität Fly.io, Inc. Er lokalisiert kein Kundenvolume. Firmenanschrift, Laufzeitregion und Wiederherstellungskennung sind verschiedene Arten von Wissen. Ein umfangreicher Beschaffungsordner kann die ersten beiden enthalten und beim dritten dennoch leer sein.

Der Wert einer noch aufbewahrten Kopie besteht in einer ausübbaren Option: Mit Zeit, Berechtigung und neuer Ressource lässt sich daraus ein Wiederherstellungsversuch machen. Überlebende Daten und überlebende Referenzen müssen sich vor Fristende treffen.

Cloud-Ressourcen können stundenweise in Rente gehen. Die Erinnerung daran, was von ihnen noch zurückgeholt werden kann, braucht einen benannten Nachfolger.

Offizielle Quellen