So sichern Sie SQLite-Datenbanken im laufenden Betrieb ohne Datenverlust auf S3

SQLite wegen seiner Einfachheit lieben? Einen frischen VPS aufsetzen, einen kleinen Dienst starten, eine Datenbankdatei daneben ablegen, und alles funktioniert mit sofortiger Reaktionszeit. Keine zusätzlichen Docker-Container mit PostgreSQL, keine Benutzerverwaltung oder Konfiguration von Zugriffsrechten. Wunderschön.

Probleme entstehen, wenn der Server unerwartet abstürzt oder der Anbieter „aus Versehen" Ihre Festplatte löscht. Wenn Sie einmal täglich über cron ein Backup erstellt haben, haben Sie einen ganzen Tag an Benutzern und Bestellungen verloren. Wenn Sie versucht haben, die Datenbankdatei mit einem einfachen cp zu kopieren, während Schreibvorgänge stattfanden, hatten Sie am Ende eine beschädigte Datei, die SQLite nicht einmal öffnet.

Der Ersteller der bekannten BoltDB Key-Value-Datenbank, Ben Johnson, stand vor genau diesem Dilemma und baute Litestream. Es ist ein kleines Go-Tool, das das SQLite-Backup-Problem ein für alle Mal löst.

Was Litestream macht und warum Sie es brauchen

Litestream läuft als Hintergrundprozess auf demselben Server wie Ihre Anwendung. Seine Aufgabe ist es, kontinuierlich Änderungen aus Ihrer lokalen SQLite-Datenbank an den Remote-Speicher zu streamen. Dies kann ein S3-kompatibler Cloud-Dienst, Yandex Object Storage, MinIO oder einfach ein Ordner auf einer anderen eingehängten Festplatte sein.

Als Ergebnis erhalten Sie ein fertiges Disaster-Recovery-System. Wenn Ihr VPS in Flammen aufgeht, starten Sie eine neue Instanz, führen Sie einen einzelnen Restore-Befehl aus, und die Datenbank wird bis zur letzten Transaktion vor dem Absturz wiederhergestellt.

Das Hauptmerkmal des Tools ist die Zuverlässigkeit. Es interagiert mit der Datenbank strikt über die offizielle SQLite C-API, nicht durch blindes Lesen roher Bytes von der Festplatte. Dies garantiert, dass Schreibphasen nicht mit Komprimierung oder Journal-Checkpoints überlappen und die Datenbank nicht zu einer beschädigten Datei wird.

Wie die Replikation unter der Haube funktioniert

Um zu verstehen, wie es funktioniert, erinnern wir uns an den WAL-Modus (Write-Ahead Logging) von SQLite.

Standardmäßig schreibt SQLite Änderungen direkt in die Haupt- .db-Datei. Im WAL-Modus gehen alle neuen Transaktionen zuerst in ein separates Journal mit der -wal-Erweiterung. Periodisch werden diese Änderungen zurück in die Hauptdatei geschrieben. Dieser Ansatz beschleunigt Schreibvorgänge und blockiert keine Lesezugriffe.

Litestream nutzt diesen Mechanismus:

1. Es schaltet die Datenbank in den WAL-Modus.
2. Überwacht neue Seiten, die in der WAL-Datei erscheinen.
3. Kopiert diese Änderungen und sendet sie in kleinen Segmenten an S3.
4. Steuert den Checkpoint-Prozess, damit SQLite die WAL nicht vorzeitig löscht, bevor die Daten in die Cloud hochgeladen wurden.

Die Verzögerung beim Senden der Daten an S3 beträgt nur wenige Sekunden. Wenn der Server kaputt geht, verlieren Sie maximal Daten aus den letzten paar Sekunden.

Einrichtung und Verwendungsbeispiel

Sie können die Replikation in ein paar Minuten starten. Laden Sie einfach das Binary herunter oder verwenden Sie ein fertiges Docker-Image.

Lassen Sie uns zunächst die Konfigurationsdatei litestream.yml erstellen:

dbs:
  - path: /var/lib/my-app/production.db
    replicas:
      - url: s3://my-backup-bucket/production.db

Verbindungsparameter zu S3 wie Zugriffsschlüssel und Endpunkt werden normalerweise über Standard-Umgebungsvariablen übergeben: AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY.

Der Prozess wird mit einem einfachen Befehl gestartet:

litestream replicate -config /etc/litestream.yml

Oft wird Litestream im selben Docker-Container wie die Hauptanwendung ausgeführt, unter Verwendung eines leichtgewichtigen Prozess-Orchestrierers wie entrypoint.sh oder supervisord.

Wenn der Server abgestürzt ist und Sie die Datenbank an einem neuen Ort bereitstellen müssen, führen Sie den Restore-Befehl aus, bevor Sie die Anwendung starten:

litestream restore -o /var/lib/my-app/production.db s3://my-backup-bucket/production.db

Das Tool holt das neueste Basis-Dump aus dem Bucket, lädt alle fehlenden WAL-Segmente darauf herunter, assembliert eine vollständige Datenbankdatei und legt sie am angegebenen Pfad ab.

Einschränkungen und Fallstricke

Das Tool sieht sehr ansprechend aus, aber Litestream hat einen klaren Scope und seine eigenen Einschränkungen.

Erstens erfordert das Tool, dass der WAL-Modus aktiviert ist. Wenn Ihre Anwendung oder eine bestimmte Datenbanktreiber-Bibliothek damit nicht kompatibel ist, funktioniert nichts.

Zweitens ist dies ein Disaster-Recovery-Tool, nicht für horizontale Lese-Skalierung. Sie können Litestream nicht verwenden, um fünf Kopien des Dienstes auf verschiedenen Servern zu starten, die alle gleichzeitig aus derselben replizierten Datenbank lesen. Für verteilte Szenarien mit mehreren Nodes sind Sie mit LiteFS vom selben Team oder Projekten wie rqlite besser beraten.

Drittens, wenn Sie eine riesige Datenbank mit Hunderten von Gigabytes mit konstanten schweren Schreibvorgängen haben, können S3-Traffic und API-Anfragekosten eine unangenehme Überraschung sein. Das Tool ist für kleine bis mittlere Workloads konzipiert.

Wem dieses Projekt nützlich sein wird

Litestream beseitigt die Notwendigkeit, heavyweight Datenbanken einzurichten, wo kein echter Bedarf dafür besteht. Es ist eine ausgezeichnete Wahl für:

• Telegram-Bots und REST-APIs in Go, Python oder Node.js mit einer einzelnen Anwendungsinstanz.
• Projekte auf Frameworks wie PocketBase oder Directus, die auf SQLite laufen.
• Persönliche selbst-gehostete Dienste auf günstigen VPS.
• Microservices mit lokalem Cache oder Client-Datenisolierung.

Wenn Sie Ihr Projekt auf SQLite umstellen wollten, aber die Angst vor Datenverlust auf der Festplatte Sie zurückgehalten hat, versuchen Sie, Litestream hinzuzufügen. Die Einrichtung dauert eine halbe Stunde, aber Sie werden ruhig schlafen.