Felix Ostrowski

Online Services & Information Management [@stabi_berlin](https://openbiblio.social/@stabi_berlin )

Last Notes

2026-08-31 12:15:50 GMT

- reply

Und: "Schwerwiegende technische und sicherheitsrelevante Vorfälle wie Dienstunterbrechungen und Datenlecks seien im Vergleich zum Vorjahr um 40 Prozent gestiegen. Die Zeit, die Mitarbeiter für die Bekämpfung der Probleme aufwenden mussten, sogar um 70 Prozent."

2026-08-31 12:15:21 GMT

- reply

Darin heißt es u.a.: "Code-Änderungen an den internen Softwareplattformen und der Infrastruktur seien etwa im Vergleich zum Vorjahr um 220 Prozent gestiegen. Änderungen, die dazu führten, dass neue oder verbesserte Funktionen die Meta-Nutzer erreichten, stiegen jedoch nur um 36 Prozent."

2026-08-31 12:14:46 GMT

- reply

Interessant ist, dass offenbar auch ein großes Tech-Unternehmen dagegen steuert: https://www.heise.de/news/Massiver-Umbau-gekippt-Meta-wollte-KI-nativ-werden-und-scheiterte-11434074.html.

2026-01-15 16:05:11 GMT

- reply

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

2026-01-15 16:04:53 GMT

- reply

Wichtig ist uns ein Punkt ausdrücklich: Dieses Szenario ist nicht repräsentativ für die Infrastruktur der [@stabi_berlin](https://openbiblio.social/@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

2026-01-15 16:04:35 GMT

- reply

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

2026-01-15 16:04:20 GMT

- reply

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

2026-01-15 16:04:03 GMT

- reply

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

2026-01-15 15:59:44 GMT

- reply

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

2026-01-15 15:59:28 GMT

- reply

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

2026-01-15 15:59:11 GMT

- reply

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

2026-01-15 15:58:54 GMT

Wir möchten den längeren Ausfall von openbiblio.social transparent erklären. Der Vorfall war technisch komplex, organisatorisch unerquicklich und für uns alle belastend. In diesem Thread schildern wir, was passiert ist, wo Fehler lagen und wie wir künftig mit solchen Risiken umgehen werden. /cc @npub13e9…qmuw @npub1h2m…xj26 @npub1scr…txv5 1/9

2025-01-15 11:01:16 GMT

- reply

Das Problem sollte behoben sein. Hintergrund war, dass nach einem Server-Reboot der Opensearch-Dienst nicht wieder hochgefahren war: https://docs.joinmastodon.org/admin/elasticsearch/ @npub1scr…txv5 @npub1s9r…mgl3