Was ist passiert?
Hetzner meldete für den 12. November 2026 ab 02:20 UTC eine Störung des Object Storage am Standort fsn1 (Falkenstein). Laut Statusmeldung war der Dienst nur teilweise verfügbar. Anfragen an einige Buckets konnten fehlschlagen oder in eine Zeitüberschreitung laufen.
Um 03:32 UTC, also 72 Minuten nach dem genannten Beginn, schrieb Hetzner, der Fehler sei behoben und die Systeme würden weiter beobachtet. Auf behoben gesetzt wurde der Vorfall erst am 13. November um 11:13 UTC. Die Statusseite führt damit einen Zeitraum von 32 Stunden und 53 Minuten. Wie lange Anfragen tatsächlich fehlschlugen und wie viele Buckets betroffen waren, nennt Hetzner nicht.
Quelle und Zeitangaben stammen aus der Hetzner Statusmeldung, Stand 13. November 2026, abgerufen am 14. November 2026.
Zeitverlauf der Störung
Die Statusmeldung enthält vier Zeitpunkte. Als Beginn nennt Hetzner 02:20 UTC. Der Eintrag selbst wurde laut den Daten der Statusseite um 03:20 UTC angelegt, zwölf Minuten später folgte die Meldung zur Fehlerbehebung. Danach blieb der Vorfall 31 Stunden und 41 Minuten im Zustand Beobachtung, bis er geschlossen wurde.
Eine technische Ursache nennt die Meldung nicht. Wir spekulieren deshalb nicht über einen Auslöser. Für Betreiber ist ohnehin eine andere Frage wichtiger: Was hängt in der eigenen Umgebung an diesem Speicher, und wie schnell fällt ein Fehler dort auf?
Wer war betroffen?
Betroffen sein konnten nur Projekte, die Buckets am Standort fsn1 nutzen. Hetzner beschreibt Object Storage als S3-kompatiblen Speicher mit standortgebundenen Endpunkten. Für Falkenstein lautet der Endpunkt fsn1.your-objectstorage.com, für Nürnberg und Helsinki gibt es eigene. Als typische Anwendungsfälle nennt die Dokumentation automatische Backups und das Bereitstellen von Dateien über eine öffentliche URL.
Für eine Website heißt das: Ein Server bei Hetzner war nicht automatisch betroffen. Relevant war der Vorfall dort, wo Backup-Jobs in einen Bucket in fsn1 schreiben oder wo Medien, Downloads und Exporte direkt aus einem solchen Bucket ausgeliefert werden. In der Nacht zum 12. November kann das ein fehlgeschlagenes Backup oder ein nicht ladendes Bild bedeutet haben.
Endpunkte und Anwendungsfälle beschreibt Hetzner in der Übersicht zu Object Storage, Stand 23. September 2024.
So prüfen Sie die Abhängigkeit in zwei Minuten
Suchen Sie zuerst in der Konfiguration von Website, Backup-Werkzeug und Server nach dem Endpunkt. Taucht fsn1.your-objectstorage.com auf, nutzt das System einen Bucket am betroffenen Standort. Ändern Sie dabei noch nichts.
Prüfen Sie danach, ob der Bucket jetzt antwortet. Für öffentliche Dateien genügt ein Abruf mit Zeitlimit. Für private Buckets listet ein S3-kompatibles Werkzeug den Inhalt mit den vorhandenen Zugangsdaten auf. Sehen Sie anschließend in das Protokoll des Backup-Werkzeugs: Gibt es für den 12. November ein vollständiges Backup, oder steht dort ein Fehler oder Timeout?
grep -rIl "your-objectstorage.com" /pfad/zur/konfiguration
curl -sS -m 10 -o /dev/null -w '%{http_code} %{time_total}s\n' https://<bucket-name>.fsn1.your-objectstorage.com/<datei>
aws s3 ls s3://<bucket-name> --endpoint-url https://fsn1.your-objectstorage.comDieselbe Reihenfolge aus Eingrenzen, Messen und Abgleichen haben wir beim Hetzner DNS-Ausfall im Oktober 2026 beschrieben.
Was jetzt zu tun ist
Wer Buckets in fsn1 nutzt, sollte die Zeit vom 12. November 02:20 UTC bis zum Abschluss am 13. November in den eigenen Protokollen nachsehen. Fehlende Backups lassen sich nachholen. Wichtig ist, dass danach wieder eine vollständige und lesbare Sicherung vorliegt. Ein Backup gilt erst als vorhanden, wenn eine Wiederherstellung daraus geprüft wurde.
Bei Anwendungen, die Dateien in den Bucket hochladen, lohnt ein Blick auf abgebrochene Uploads. Starten Sie fehlgeschlagene Jobs nur dann erneut, wenn eine doppelte Verarbeitung ausgeschlossen ist.
- Backup-Protokolle für den 12. und 13. November prüfen.
- Fehlende Sicherungen nachholen und eine Wiederherstellung testen.
- Abgebrochene Uploads und Exporte der Anwendung kontrollieren.
- Befund mit Uhrzeit und Fehlermeldung dokumentieren.
Monitoring, Statusseite und Fallbacks
Die Statusseite ist eine wichtige Quelle, aber kein Alarm. In diesem Fall wurde die Meldung eine Stunde nach dem genannten Beginn angelegt. Ein eigenes Monitoring sollte deshalb zwei Dinge selbst prüfen: ob ein Testobjekt im Bucket abrufbar ist, und ob das letzte Backup erfolgreich und nicht älter als erwartet ist. Ein Backup-Job, der still scheitert, ist das größere Risiko als ein kurzer Ausfall.
Hetzner schreibt in der Dokumentation, dass alle Daten eines Buckets ausschließlich in einem Rechenzentrum am gewählten Standort liegen. Innerhalb des Clusters schützt eine Verteilung auf mehrere Server vor dem Ausfall einzelner Speicherserver. Der Anbieter ergänzt selbst, dass jedes Produkt nur ein Teil einer sicheren Backup-Strategie sein kann.
Daraus folgt eine einfache Regel: Backups gehören nicht nur an den Ort, an dem auch die Website läuft. Eine zweite Kopie an einem anderen Standort oder bei einem anderen Anbieter macht eine Störung wie diese zu einer Randnotiz. Für öffentlich ausgelieferte Dateien hilft ein vorgelagerter Cache, kurze Aussetzer zu überbrücken. Beides sollte getestet sein, bevor es gebraucht wird.
Die Angaben zu Speicherort und Redundanz stehen in den allgemeinen Fragen zu Object Storage, Stand 23. September 2024.
Welche Backup-Leistungen in einem Wartungsvertrag konkret beschrieben sein sollten, zeigt unser Beitrag WordPress Wartung Kosten.
Updates, Backups und technische Kontrollen bündeln wir für WordPress Seiten in unserer WordPress Wartung. Dort lässt sich auch klären, wo Sicherungen liegen und wie eine Wiederherstellung geprüft wird.
Fazit
Der Vorfall betraf einen Teil der Buckets an einem Standort. Hetzner meldete die Fehlerbehebung nach 72 Minuten und schloss den Vorfall nach knapp 33 Stunden Beobachtung. Wer weiß, welche Systeme an einem Bucket hängen, Backups unabhängig vom Anbieter ablegt und deren Erfolg überwacht, kann eine solche Meldung in wenigen Minuten einordnen.
Weitere nüchterne Einordnungen zu Betrieb und Sicherheit finden Sie im devvibe Magazin.