Felix Ostrowski

Für openbiblio.social ziehen wir Konsequenzen: Die Instanz wird in den kommenden Wochen zu einem professionellen Mastodon-Dienstleister migriert, mit belastbaren Backup- und Recovery-Konzepten. Der Ausfall hat uns zugleich gezeigt, was für eine großartige Community wir haben. Danke für eure Geduld, euer Vertrauen und eure Treue. 9/9

Wichtig ist uns ein Punkt ausdrücklich: Dieses Szenario ist nicht repräsentativ für die Infrastruktur der @stabi_berlin. Unsere anderen Dienste laufen im eigenen Rechenzentrum – dort wären Recovery-Zeiten von Stunden, nicht Wochen, realistisch gewesen. Auch der Datenverlust wäre ausgeblieben. 8/9

Hier ist uns eine klare Einordnung wichtig: Der kurzfristige Serverumzug an Feiertagen ist aus unserer Sicht inakzeptabel. Gleichzeitig trifft uns selbst eine erhebliche Mitschuld: Wir hatten kein externes, unabhängig gelagertes Backup. Diese Kombination hat die Situation eskalieren lassen. 5/9

Nach vielen Versuchen fanden wir noch eine alte PostgreSQL-13-Instanz, die im Zuge einer Migration auf PG15 am 19.11. abgeschaltet worden war. Auch diese war beschädigt, aber noch erreichbar. In aufwändiger Kleinstarbeit wurden Fehler in rund 100.000.000 Tabellenzeilen behoben, bis ein konsistenter Dump erzeugt werden konnte. 6/9

Nach der Migration ließ sich der Server nicht mehr ordnungsgemäß starten. Es traten massive Dateisystem-Fehler auf, Speicheroptimierungen brachen ab. In den folgenden Tagen zeigte sich das Ausmaß: defekte Blöcke, Inode-Probleme und eine schwer beschädigte PostgreSQL-Datenbank. Unsere Backup-Dateien waren allesamt davon betroffen, ein System-Snapshot ist vorab vom Hoster gelöscht worden. 3/9

Dieser Dump wurde auf einen neuen Server übertragen, dort migriert und in eine frische Mastodon-Instanz eingespielt. Bei der finalen Inbetriebnahme hatten wir Unterstützung durch einen externen Dienstleister. Trotz aller Bemühungen ließ sich ein Datenverlust nicht vollständig vermeiden – das tut uns sehr leid. 7/9

Ein regulärer Dump aus der produktiven Datenbank war ebenfalls nicht mehr möglich, mehrere Tabellen enthielten beschädigte Heaps. Reindexing schlug fehl, Reparaturen hätten massiven Datenverlust bedeutet. Parallel baten wir den Hoster um Hilfe, insbesondere um Snapshots vor der Migration. Die ernüchternde Antwort: Es existierte kein nutzbares Backup mehr. 4/9

Am 26.12.2025 wurde die Instanz zunächst träge, kurz darauf war kein Zugriff mehr möglich. Ein regulärer Neustart ließ sich nicht mehr durchführen. Noch am selben Tag informierte uns der Hoster, dass unser Server aus „Stabilitätsgründen“ kurzfristig auf ein anderes Wirtssystem migriert werden müsse – mit sehr kurzer Vorlaufzeit und mitten an Weihnachten. 2/9