Timestream-Backup: Restore ohne Ticket

Wer eine Influx-Instanz in Amazon Timestream zurückholen wollte, schrieb bisher ein Support-Ticket. Jetzt liegt der Restore in der Konsole, direkt neben dem Knopf, der die laufende Instanz überschreibt.

Das Wichtigste in Kürze

Verwandt:AWS Identity Center: Multi-Region sitzt jetzt im Setup  /  Lieferkette bricht am Datenpfad zwischen MES und ERP

Der Restore hing am Support

Amazon Timestream speichert Messreihen. Wer InfluxDB dort als verwalteten Dienst betreibt, hatte schon interne Kopien. Zugriff darauf lief über ein Ticket. Am 7. August 2026 hat AWS den Schalter nach außen gelegt: eigene Backups, eigener Restore, in der Konsole, über die Kommandozeile oder die API. Das gilt für InfluxDB 2 und für InfluxDB 3.

Die alten Service-Kopien bleiben. AWS steuert sie weiter und gibt sie nur über den Support heraus. Interne Stände hält der Dienst rund einen Tag, Snapshots nach dem Löschen einer Ressource rund 30 Tage. Beides ersetzt keinen Plan, den man selbst auslöst. Beide Wege dürfen parallel laufen.

Wer bisher vor einem Versionswechsel oder einem Umbau der Instanz stand, wartete auf die Warteschlange. Jetzt kann der Abzug unmittelbar vor dem riskanten Schritt sitzen. Der Gewinn sitzt im Zugriff. Die Datenbank bleibt dieselbe.

Vier Zeitpläne, ein erster Vollabzug

Pro Instanz oder Cluster erlaubt AWS höchstens vier automatische Konfigurationen. Stündlich, täglich, wöchentlich, monatlich oder ein eigenes Cron, jede mit eigener Aufbewahrung. Der erste Backup zieht alles. Die folgenden laufen inkrementell und speichern nur, was sich geändert hat.

Für den Alltag reicht oft ein kurzer Rhythmus mit kurzer Haltung und ein langer Rhythmus für den Fall, den niemand jeden Morgen prüft. Geplante Läufe dürfen bis zu einer Stunde nach dem Solltermin starten. Unter Last dauert der erste Vollabzug länger, die Instanz bleibt dabei erreichbar.

Ein Feature-Aufpreis steht nicht in der Preisliste; bezahlt wird der Speicher der Kopien, bei InfluxDB 2 über EBS, bei InfluxDB 3 über S3. Beim Löschen der Ressource verschwinden die automatisierten Stände, On-Demand-Kopien bleiben. Wer die automatisierten behalten will, muss das beim Löschen ausdrücklich setzen.

Neue Instanz lässt die alte stehen

Der empfohlene Restore legt eine neue Ressource an. Die laufende Instanz bleibt unberührt. Fehlen Extra-Angaben, erbt die neue Kopie die Konfiguration des Backups. Eine einzelne Instanz lässt sich auf einen Read-Replicas-Cluster heben. Umgekehrt geht der Weg nicht: ein Cluster-Backup landet nicht auf einer einzelnen Instanz.

Das ist der Pfad vor einem Umbau, den man noch umdrehen können will. Die alte Instanz bleibt der Beweis, dass der Restore sitzt. Erst wenn die neue Kopie antwortet, fällt die Entscheidung über die alte.

Derselbe Knopf überschreibt die Produktion

REPLACE_EXISTING spielt den Backup auf die bestehende Ressource zurück. Die Instanz ist in der Zeit nicht erreichbar. Vorhandene Daten werden gelöscht und durch den Stand der Kopie ersetzt. Scheitert der Lauf, versucht der Dienst einen Rollback. AWS rät vorher zu einem frischen On-Demand-Backup. Ohne diesen Abzug ist der alte Datenstand danach weg.

Genau dieser Modus lässt sich per IAM sperren. Die Bedingung prüft den Restore-Modus und verweigert REPLACE_EXISTING. Wer viele Hände an derselben Konsole hat, setzt die Sperre bevor der erste Notfall kommt.

Frische Writes bleiben draußen

Ein Backup ist kein Abbild der letzten Sekunde. Bei InfluxDB 3 können Writes der letzten rund 15 Minuten fehlen. Ein Punkt-zu-Punkt-Restore braucht eine durchlaufende Konfiguration und einen Zeitstempel, der mindestens diese Viertelstunde zurückliegt.

Bei InfluxDB 2 gilt eine extra Lücke, sobald eine einzelne Instanz auf einen Read-Replicas-Cluster wandert. Mit kommen nur Daten, die schon in TSM-Dateien liegen. Was noch im Write-Ahead-Log steckt, bleibt draußen. Grobe Schwelle: rund zehn Minuten ohne Schreiblast oder 25 Megabyte Cache. Eine fast leere oder dünn beschriebene Instanz kann als leere Datenbank ankommen. Restore auf eine andere einzelne Instanz nimmt den WAL-Inhalt mit.

Cross-Region und Cross-Account fehlen. Backup und Restore bleiben im selben Konto und in derselben Region. AWS Backup, der zentrale Dienst für andere Tabellen in Timestream LiveAnalytics, deckt InfluxDB nicht. Wer eine Kopie in einer zweiten Region will, braucht einen eigenen Weg außerhalb dieses Schalters.

Die Kommandozeile und die API können denselben Lauf auslösen wie die Konsole. Für den ersten Plan reicht die Konsole. CLI-Namen gehören ins Runbook. Die Entscheidung fällt vorher.

Häufige Fragen

Bildquelle: KI-generiert (August 2026)