Letzte Woche habe ich meine Produktionsdatenbank gelöscht. Meine Arbeitsinstanz [Neotoma](https://neotoma.io) stieg von 6.174 Beobachtungen und 3.862 Entitäten auf 84 Beobachtungen und 67 Entitäten in einem Befehl. Monatelange Kontakte, Aufgaben, Gespräche, Feedback-Notizen, Transaktionen und Geschäftsregeln: weg.

Ich habe es zurückbekommen. Die endgültige Datenbank umfasst 6.296 Beobachtungen und 3.951 Entitäten über einen Zeitraum von fünf Wochen. Die Wiederherstellung dauerte etwa eine Stunde. In diesem Beitrag geht es darum, wie es passiert ist, warum eine Wiederherstellung möglich war und was die Erfahrung beim Aufbau eines Speichersystems gezeigt hat, dem man tatsächlich vertrauen kann.

## Was ist passiert?

Ich habe an der Neotoma-CLI gearbeitet und einen Entwicklungsworkflow getestet. Ich habe eine Folge von Befehlen ausgeführt, die den Datenbankstatus zurückgesetzt und neu initialisiert haben. Die Absicht bestand darin, Testdaten aus einer Entwicklungsumgebung zu löschen. Das Ziel war die Produktionsdatenbank.

Der Fehler war banal. Ich habe „neotoma reset“ ausgeführt, während „NEOTOMA_ENV“ auf Produktion eingestellt war. Ich dachte, ich hätte es auf Entwickler abgesehen. Als ich es bemerkte, enthielt die aktive Datenbank 84 neue Beobachtungen aus dem Neuinitialisierungsprozess und sonst nichts.

## Suche nach den Backups

Das erste, was ich tat, war, nach jeder Neotoma SQLite-Datei auf meinem Computer zu suchen. Ich habe zehn Kopien gefunden, die über Backup-Verzeichnisse, Datenordner und zeitgestempelte Wiederherstellungsartefakte von einem früheren Abschlussaufruf Anfang März verstreut waren.

| Quelldatei | Beobachtungen | Entitäten | Letzte Aktivität |
|---|---|---|---|
| `neotoma.prod.db.db` | 6.174 | 3.862 | 9. März |
| `neotoma.prod 2.db` | 4.406 | 3.073 | 10. März |
| Live-Ziel (nach dem Löschen) | 84 | 67 | 11. März |
| `neotoma.prod.db.recovered-*` | 4.381 | 3.059 | 3. März |
| `data-backups/data copy/` | 4.158 | 2.955 | 2. März |
| Diverse ältere Exemplare | 3.100 bis 3.931 | 2.558 bis 2.806 | 17. Februar bis 27. Februar |

Die Sicherungskopien existierten, weil ich die Datenbankdatei in unregelmäßigen Abständen manuell kopiert hatte. Kein formelles Backup-System, nur gelegentliche „cp“-Befehle, wenn ich mich daran erinnere oder nervös war. Eine dieser Kopien, „neotoma.prod.db.db“, hielt bis zum 9. März fast alles aufrecht. Eine zweite Kopie, „neotoma.prod 2.db“, enthielt bis zum 10. März Daten, die in der ersten Kopie fehlten.

Zwischen diesen beiden Dateien und den verbleibenden 84 Beobachtungen in der Live-Datenbank hatte ich genug Material, um die gesamte Zeitleiste zu rekonstruieren.

## Wie die Zusammenführung funktionierte

Neotoma verfügt über einen integrierten „merge-db“-Befehl zum Kombinieren von SQLite-Datenbanken. Der Prozess:

1. Sichern Sie alle beteiligten Dateien (sowohl Quellen als auch Ziel) in einem Verzeichnis mit Zeitstempel. Bei keinem Wiederherstellungsversuch sollten die Originale gefährdet werden.
2. Stoppen Sie den laufenden Neotoma-Server, um gleichzeitige Schreibvorgänge zu verhindern.
3. Führen Sie die Zusammenführung probeweise durch, um zu sehen, welche Konflikte bestehen.
4. Führen Sie die Zusammenführung mit „--mode keep-target“ aus, wodurch Zeilen aus der Quelle eingefügt werden, die dem Ziel fehlen, und die Zielversion aller Zeilen beibehalten wird, die beide Datenbanken gemeinsam nutzen.
5. Wiederholen Sie den Vorgang für die zweite Quelle.
6. Überprüfen Sie die Beobachtungs- und Entitätsanzahl.
7. Starten Sie den Server neu.

Die primäre Zusammenführung brachte 6.174 Beobachtungen aus dem größten Backup. Durch die sekundäre Zusammenführung kamen seit dem Fenster vom 10. März etwa 100 weitere hinzu. Die endgültige Zahl: 6.296 Beobachtungen, 3.951 Entitäten, Aktivitäten vom 9. Februar bis 11. März.

Nach dem Neustart habe ich Entitäten über das Neotoma MCP abgetastet, um sicherzustellen, dass auf alles zugegriffen werden konnte. Kontakte, Aufgaben, Gespräche, Feedback-Datensätze: alles vorhanden und richtig strukturiert.

## Warum diese Erholung möglich war

Die Wiederherstellung funktionierte aufgrund von drei Eigenschaften der Architektur von Neotoma.

**Beobachtungen sind die Quelle der Wahrheit.** Neotoma speichert keine Entitäten, indem es eine Zeile überschreibt, wenn sich etwas ändert. Jede Tatsache gelangt als unveränderliche Beobachtung in das System: „Alice‘s E-Mail ist alice@example.com, beobachtet am 3. März von Gmail.“ Der Entitätsstatus wird aus dem gesamten Satz von Beobachtungen berechnet. Das Beobachtungsprotokoll kann nur angehängt werden.

Das bedeutet, dass eine Datenbanksicherung eine vollständige Momentaufnahme aller Fakten ist, die das System jemals gesehen hat, und nicht nur des neuesten Stands. Als ich das Backup mit der Live-Datenbank zusammenführte, stellte ich nicht „den letzten bekannten Status jeder Entität“ wieder her. Ich habe die gesamte Geschichte noch einmal abgespielt.

**Entitäts-Snapshots werden abgeleitet, nicht primär.** Nach dem Zusammenführen der Beobachtungen berechnet Neotoma die Entitäts-Snapshots aus dem Beobachtungsprotokoll neu. Der Schnappschuss für jede Entität ist deterministisch: Bei gleichen Beobachtungen erhalten Sie immer den gleichen Entitätsstatus. Aus diesem Grund umfasst der Zusammenführungsbefehl einen Snapshot-Neuberechnungsschritt. Sobald die Beobachtungen vorliegen, bauen sich die Entitäten korrekt wieder auf.

**Primärschlüsselzusammenführung mit Konflikterkennung.** Der Befehl „merge-db“ durchsucht jede Tabelle, fügt Zeilen ein, die in der Quelle, aber nicht im Ziel vorhanden sind, und behandelt Konflikte nach Primärschlüssel. Im Modus „Ziel behalten“ gewinnt die Version des Ziels bei jeder Kollision. Im Probelaufmodus wird vor dem Festschreiben genau angezeigt, was eingefügt wird und was in Konflikt steht. Ich habe für beide Zusammenführungen Probeläufe durchgeführt und vor der Ausführung die Konfliktberichte überprüft.

Diese drei Eigenschaften zusammen sorgen dafür, dass die Datenbank sich selbst repariert, was bei herkömmlichen Sicherungen auf Zeilenebene nicht der Fall ist. Sie müssen sich keine Gedanken darüber machen, welches Backup die „richtige Version“ einer Entität enthält. Sie führen die Beobachtungen zusammen, berechnen sie neu und der richtige Zustand ergibt sich.

## Was ich gelernt habe

Die Erfahrung hat einige Dinge bestätigt.

**Informelle Backups sind besser als keine Backups.** Meine Angewohnheit, gelegentlich die Datenbankdatei zu kopieren, hat mir monatelange Arbeit erspart. Aber gelegentliche manuelle Kopien sind kein System. Sie hinterlassen Lücken. Wenn ich die Datenbank am 7. März statt am 11. März gelöscht hätte, wären die Daten vom 28. Februar bis zum 7. März verloren gegangen, da keine Kopie dieses Fenster vollständig abdeckte. Ich richte jetzt automatisierte tägliche Backups mit Time Machine auf meinem Mac ein.

**Der Env-Flag-Fehler ist ein Klassiker.** Jedes System, das in Entwicklungs- und Produktionsumgebungen betrieben wird, birgt dieses Risiko. Die Abhilfe besteht aus Bestätigungsaufforderungen für destruktive Vorgänge, farbcodierten Terminal-Eingabeaufforderungen oder separaten Anmeldeinformationen pro Umgebung. Nach diesem Vorfall habe ich eine erzwungene Bestätigung für „neotoma reset“ hinzugefügt, wann immer eine Produktionsumgebung erkannt wird. Das Flag „-y“ wird für prod ignoriert. Sie sehen „Neotoma reset (PRODUCTION)“ und eine Warnung, bevor etwas passiert.

**Eine ereignisbasierte Architektur zahlt sich bei der Wiederherstellung aus.** Wenn Neotoma Entitäten durch Überschreiben von Zeilen speichern würde, wäre eine Datenbanklöschung ein Datenverlustereignis ohne sauberen Wiederherstellungspfad. Da Beobachtungen unveränderlich sind und der Entitätsstatus abgeleitet wird, handelt es sich bei der Wiederherstellung um einen Zusammenführungs- und Neuberechnungsvorgang. Das Beobachtungsprotokoll ist die Grundwahrheit. Alles andere kann daraus nachgebaut werden.

**Ich habe die Tools getestet, die ich erstellt habe.** Ich habe den Befehl „merge-db“ vor Monaten für einen anderen Anwendungsfall geschrieben: das Kombinieren von Daten von Benutzern, die mehrere Neotoma-Instanzen ausführen. Ich hätte nie gedacht, dass ich es für meine eigenen Produktionsdaten verwenden würde. Da das Tool jedoch vorhanden war und die Konfliktlösung und die Neuberechnung von Schnappschüssen übernahm, verlief die Wiederherstellung eher mechanisch als stressig.

## Ihre Daten sollten Ihre Fehler überleben

Dieser Vorfall hat Lücken aufgedeckt, die Neotoma schließen sollte, damit Benutzer nie das tun müssen, was ich manuell getan habe.

**Automatische Snapshots.** Neotoma sollte nach einem Zeitplan und vor jedem zerstörerischen Vorgang einen Snapshot der Datenbank erstellen. Ein rotierender Satz zeitgestempelter Kopien, die 30 Tage lang aufbewahrt werden. Wenn Sie versehentlich einen Reset auf dem Produkt ausführen, ist der Snapshot vor dem Zurücksetzen genau dort. Die Wiederherstellung sollte nicht davon abhängen, ob Sie daran gedacht haben, in dieser Woche „cp“ auszuführen.

**Anomalieerkennung.** Ein plötzlicher Abfall von Tausenden von Beobachtungen auf nahezu Null ist nicht normal. Neotoma konnte dieses Muster erkennen und bestätigen, bevor es einen Commit durchführte. Eine einfache Heuristik: „Diese Operation würde mehr als 90 % der Beobachtungen entfernen, bestätigen Sie?“ hätte mein Abwischen komplett verhindert.

**Agentengesteuerte Wiederherstellung.** Da Agenten die primäre UX für Neotoma sind, sollte die Wiederherstellung auch über Agenten funktionieren. Sie sagen Ihrem Agenten: „Meine Datenbank sieht falsch aus, ich glaube, ich habe Daten verloren.“ Der Agent prüft die Anzahl der Beobachtungen, findet verfügbare Snapshots, vergleicht Datumsbereiche und führt Sie über das MCP durch die Zusammenführung. Keine CLI-Höhlenforschung erforderlich.

**Remote-Synchronisierung.** Lokale Backups schützen vor versehentlichem Überschreiben, jedoch nicht vor Festplattenausfällen. Neotoma sollte die Synchronisierung des Beobachtungsprotokolls mit einem Remote-Standort unterstützen: einem Cloud-Bucket, einem zweiten Computer oder einem selbst gehosteten Server. Da Beobachtungen nur angehängt werden können, ist das Synchronisierungsmodell einfach. Senden Sie neue Beobachtungen an die Fernbedienung. Rekonstruieren Sie den Entitätsstatus an beiden Enden.

Dank der gleichen Architektur, die diese Wiederherstellung ermöglicht hat, sind diese Funktionen einfach zu erstellen. Nur-Anhänge-Beobachtungen, abgeleitete Zustände und deterministische Neuberechnungen sind nicht nur Wiederherstellungseigenschaften. Sie bilden die Grundlage für Backup, Synchronisierung und Selbstheilung als erstklassige Garantien.

## Die Zahlen

| Metrisch | Vor dem Abwischen | Nach dem Abwischen | Nach der Genesung |
|---|---|---|---|
| Beobachtungen | 6.174 | 84 | 6.296 |
| Entitäten | 3.862 | 67 | 3.951 |
| Datumsbereich | 9. Februar bis 9. März | 10. März bis 11. März | 9. Februar bis 11. März |

Die endgültige Zahl ist höher als die Zahl vor der Löschung, da bei der Zusammenführung Beobachtungen aus allen drei Quellen kombiniert wurden: den beiden Sicherungsdateien und den verbleibenden Daten nach der Löschung. Einige Beobachtungen, die nur in der Sicherung vom 10. März oder nur in der Live-Datenbank vorhanden waren, waren nicht in der ursprünglichen größten Sicherung enthalten.

Wenn Ihr Speichersystem einen veränderlichen Zustand verwendet, ist eine Löschung dauerhaft. Wenn ein reines Anhänge-Beobachtungsprotokoll mit abgeleitetem Entitätsstatus verwendet wird, ist ein Löschen eine Zusammenführung ohne vollständige Wiederherstellung. Dieser Unterschied ist wichtig, wenn es sich bei den Daten um Ihre Kontakte, Ihre Verpflichtungen und Ihren Verlauf mit Agenten über Hunderte von Sitzungen hinweg handelt.

Neotoma ist [Open Source auf GitHub](https://github.com/neotoma-app/neotoma). Wenn Sie eine Speicherschicht wünschen, in der Ihre Daten auch die schlimmsten Fehler überstehen können, [versuchen Sie es](https://neotoma.io/install).