Liebe Leser,
unsere Mastodon-Instanz ist aktuell nicht erreichbar. Unser Account @linuxnews liegt beim Anoxinon e.V.
Laut Statusseite fiel zunächst eine NVMe-SSD des Root-Servers aus. Kurz darauf traf es auch die zweite, sodass beide Root-NVMes zeitgleich ausgefallen sind. Hier sage ich als Admin: Sh*t happens. Das ist bitter, so etwas ist mir selbst schon passiert und niemand ist davor gefeit.
Was uns bei LinuxNews mehr zu denken gibt, ist dieser Abschnitt der Statusseite:
RAID1/5/6/* ist kein Backup und ein Backup sollte Vollständig sein. Unser Backup war es nicht und hatte eine Lücke, die DB. Aktuell sind wir am schauen wir wir damit umgehen. Ihr könnt euch gerne via XMPP unter xmpp:anoxinon@conference.anoxinon.me?join an der Diskussion beteiligen. Heute ist auch erst der 2. Tag nach dem Desaster und wir gehen noch mal alle Backups dazu durch, ob nicht ggf. in einem doch noch was verborgen ist.
Fehlt die Datenbank dauerhaft, verlieren wir unseren Account und damit unsere über Jahre gewachsene Identität im Fediverse. Das wäre für uns ein herber Verlust. Wir hoffen mit dem Team, dass sich in einem der Backups doch noch ein brauchbarer Stand findet.
Unser Angebot an Anoxinon
Anoxinon ist ein ehrenamtlich getragener Verein, und der Betrieb solcher Infrastruktur ist Arbeit, die selten jemand sieht. Projekte, auf die wir uns im Alltag verlassen, unterstützen wir. Anoxinon gehört dazu, ebenso der Codeberg e.V. Deshalb bieten wir konkret Hilfe an, statt nur zu kommentieren:
Gerne unterstützen wir das Team kostenlos dabei, ein belastbares Disaster-Recovery-Konzept aufzusetzen: von der Backup-Strategie über den getesteten Restore bis zur Dokumentation, mit der sich die Wiederherstellung im Ernstfall reproduzieren lässt. Alternativ oder ergänzend beteiligen wir uns finanziell an dem, was jetzt zur Wiederherstellung des Betriebs nötig ist. Das Team kann uns übers Kontaktformular jederzeit erreichen.
Testet eure Backups
Für alle anderen ist dieser Vorfall die Erinnerung, die man nicht oft genug wiederholen kann: Testet eure Backups und zwar vollständig. Vollständig heißt, dass sich aus dem Backup der komplette Dienst in einer leeren Umgebung wiederherstellen und danach benutzen lässt. Bei einer Datenbank reicht es nicht, dass ihr Verzeichnis irgendwo mitgesichert wird. Ein Filesystem-Abzug einer laufenden Datenbank ist im Zweifel inkonsistent und im Ernstfall nicht wiederherstellbar. Was zählt, ist ein sauberer Dump oder ein point-in-time-fähiges Verfahren, das ihr auch zurückgespielt und geprüft habt.
Bei uns läuft dieser Test ohnehin monatlich automatisiert. Den aktuellen Vorfall nehmen wir zum Anlass, ihn dieses Wochenende zusätzlich einmal von Hand durchzuspielen: einen manuellen Restore des kompletten Stacks, Datenbank inklusive. Bei der Gelegenheit prüfen wir auch unsere Disaster-Recovery-Dokumentation und schärfen sie nach, wo nötig. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Erst der geprüfte Restore macht daraus eine Gewissheit.
Danke Anoxinon-Team!
Bei allem Ärger über den Vorfall gehört auch das gesagt: Anoxinon hat die Instanz über Jahre zuverlässig betrieben, mit sehr wenig Problemen und schneller Hilfe, wenn doch mal etwas war. Ein einzelner schwerer Ausfall entwertet diese Arbeit nicht. Hinter dem Verein stehen Menschen, die ihre Zeit ehrenamtlich geben und die stecken gerade in einer unangenehmen Lage.
Wer den Verein unterstützen möchte, hat zwei Wege: mit den eigenen Händen über Mitmachen oder mit einer Spende. Beides hilft, damit solche Angebote weiter existieren.
Update
Dieser Post ist gestern (2026-07-31) entstanden und die Veröffentlichung war für heute geplant. Mittlerweile gibt es ein Update von Anoxinon.
Update 2026-08-03
Laut Statusseite von Anoxinon ist doch noch ein Backup der Datenbank aufgetaucht und die Instanz ist wieder online.
Das mehrere Disks ausfallen kommt öfter vor als man denkt. Bei herkömmlichen Harddisks sind manchmal mehrere Disks defekt, aber der Raid-Controller merkt es nicht. Fällt eine Disk aus und wird ersetzt begint der Rebuild. Und dann, während dem Rebuild fallen weitere Platten aus und das wars dann. Und bei SSDs und NVMEs gibt es diverse Hetsteller mit Firmware-Bugs. Wenn man die Firmware nicht aktualisiert sterben sie alle gleichzeitig an Tag X (meist im Abstand weniger Minuten). Schon mehrfach erlebt. 🙈 Tja, Backup, Backup, Backup! 🤷
Dieses Ereignis wäre für Euch, aber auch für andere Fediverse-Nutzer der Augenblick zu überdenken, ob die richtige Plattform gewählt wurde.
Verschwindet eine Instanz und kehrt nicht wieder, oder ist, wie im vorliegenden Fall die Datenbank beschädigt und lässt sich nicht wiederherstellen (ich drücke Anoxinon e.V., dass es klappt ), dann sind alle Inhalte, Interaktionen und Kontakte weg… endgültig.
In Eurem Text gibt es aber ein Wort, welches man beachten sollte: Identität!
Bei den meisten Diensten im Fediverse ist die Identität eines Nutzers an die Instanz gebunden. Verschwindet die Instanz, ist die Identität auch verloren.
Die Lösung: nomadische Identität!
Möchte man dem Verlust der Identität, der eigenen Inhalte, der Kontakte etc. vorbeugen, muss man eine Plattform wählen, die eine nomadische Identität bietet. Die erste Wahl ist für diesen Fall: Hubzilla. Diese Software gibt es bereits seit 14 Jahren (anfangs noch unter einem anderen Namen) und sie ist inzwischen ausgesprochen “gut abgehangen” (soll heißen: sehr weit entwickelt und unter stetiger Weiterentwicklung).
Und mit eingeschaltetem ActivityPub ist ein Hubzilla-Kanal ganz normaler Teil des Fediverse und kann jeden, der im Fediverse ist, erreichen. Durch die Art der Implementierung der nomadischen Identität ist es möglich, auf einer oder mehreren Hubzilla-Instanzen (Hub) einen Klon des Kanals anzulegen, der automatisch im Hintergrund immer mit dem Hauptkanal synchronisiert wird. Fällt der Hub mit dem primären Kanal aus, so ist das kein Problem, weil alles noch auf den Hubs mit den Klonen vorhanden ist. Man kann mit diesen dann auch, ohne Verzögerung, weiter im Fediverse aktiv sein. Kehrt der primäre Hub zurück, verwendet man wieder diesen – ohne Verluste. Bleibt er verschollen, macht man einen der Klone zum primären Kanal und hat nichts verloren.
Eine ähnliche Funktionalität bieten auch die Dienste (streams), Forte und bei Mitra wird diese entwickelt, aber bei Hubzilla ist sie ausgereift und man findet auch ausreichend Hubs, um sie wirklich sinnvoll nutzen zu können (man muss seinen Kanal ja auch irgendwo klonen können). Hinzu kommt, dass auch eine eigene Hubzilla-Instanz sehr einfach zu installieren ist, und diese mit recht spärlichen Ressourcen auskommt.
Wer nun meint, er wolle aber ums Verrecken Microblogging mit Zeichenbegrenzung… nun, der postet bei Hubzilla einfach auch nur kurze Beiträge.
Ach… und wenn die Instanz zurückkehrt, dann kann man trotzdem zu Hubzilla umziehen und zumindest seine Kontakte mitnehmen… für eine ausfallsichere Zukunft wäre das vielleicht eine Überlegung wert.
Top, so geht gute Zusammenarbeit, hoffe sie kommt zustande!