SQLite produktiv auf einem VPS betreiben

Wann SQLite die richtige Produktionsdatenbank auf einem VPS ist

SQLite in der Produktion auf einem VPS zu verwenden, ist für die meisten kleinen Anwendungen die richtige Wahl. Der Grund ist einfach: Ein Prozess auf einer Maschine, der in eine Datei schreibt, benötigt keinen Datenbankserver. Es gibt keinen Daemon, den Sie überwachen müssen, keinen Port, den Sie mit einer Firewall absichern müssen, kein Passwort, das Sie regelmäßig ändern müssen, und keine zweite Maschine, die Sie verfügbar halten müssen. Eine Abfrage ist ein Funktionsaufruf und kein Netzwerk-Roundtrip. Eine Seite mit vierzig Abfragen verursacht daher vierzig Funktionsaufrufe.

Die Einschränkungen sind begrenzt, aber relevant. SQLite erlaubt jeweils nur einen Schreibprozess für die gesamte Datenbankdatei. Außerdem kann die Datei nicht zwischen zwei Maschinen gemeinsam verwendet werden. Für einen einzelnen VPS mit einer einzelnen Anwendung sind beide Einschränkungen unproblematisch. Sobald Ihre Anwendung diese Struktur überschreitet, sind beide Einschränkungen nicht mehr akzeptabel. Dieser Leitfaden behandelt die Einstellungen, mit denen Sie SQLite auf einem Server sicher betreiben, die kontinuierliche Sicherung mit Litestream und den Punkt, an dem Sie auf eine andere Lösung wechseln sollten.

Installieren Sie zuerst das Befehlszeilenprogramm. Alle folgenden Befehle wurden unter Ubuntu 24.04 ausgeführt.

sudo apt update
sudo apt install -y sqlite3
sqlite3 --version

Der Befehl gibt eine Version aus, die mit 3. beginnt, gefolgt von einem Build-Datum und einem Quelltext-Hash. Ubuntu 24.04 enthält mit Stand Juli 2026 SQLite 3.45.1. Ihre Anwendung verwendet diese Binärdatei wahrscheinlich nicht: Die meisten Laufzeitumgebungen enthalten eine eigene Kopie der SQLite-Bibliothek, häufig eine neuere Version. Prüfen Sie daher die von Ihrem Datenbanktreiber gemeldete Version, bevor Sie sich auf eine aktuelle Funktion verlassen.

Warum der WAL-Modus die erste Änderung ist

Standardmäßig verwendet SQLite ein Rollback-Journal. Bevor SQLite eine Seite ändert, kopiert es die ursprüngliche Seite in eine -journal-Datei und bearbeitet anschließend die Datenbank direkt. Dafür sperrt SQLite die gesamte Datei exklusiv. Jeder Lesevorgang wartet daher, solange ein Schreibvorgang läuft. Auf einem Laptop fällt das nicht auf. Auf einem Webserver verzögert ein langsamer Schreibvorgang jede Anfrage, die auf die Datenbank zugreift.

Der WAL-Modus (Write-Ahead-Log) kehrt diese Reihenfolge um. Ein Schreibvorgang hängt die neuen Seiten an eine separate -wal-Datei an und lässt die Hauptdatenbank unverändert. Leser greifen weiterhin auf die Hauptdatei mit dem Snapshot zu, den sie beim Start ihres Lesevorgangs erhalten haben. Leser blockieren daher den Schreibvorgang nicht, und der Schreibvorgang blockiert die Leser nicht. Später kopiert ein Checkpoint die angesammelten WAL-Seiten zurück in die Hauptdatenbank. Diese eine Änderung trägt wesentlich dazu bei, dass SQLite hinter einer Webanwendung eingesetzt werden kann.

WAL-Modus aktivieren und bestätigen, dass er übernommen wurde

mkdir -p ~/app
sqlite3 ~/app/app.db "PRAGMA journal_mode=WAL;"

Der Befehl gibt wal aus. Diese Ausgabe ist nicht nur eine Information. PRAGMA journal_mode gibt den Modus zurück, in dem sich die Datenbank tatsächlich befindet. Die Antwort delete bedeutet daher, dass die Änderung fehlgeschlagen ist und weiterhin das Rollback-Journal verwendet wird.

Der WAL-Modus bleibt dauerhaft aktiviert. Er ist ein Flag im Datenbank-Header und keine Verbindungseinstellung. Deshalb führen Sie den Befehl einmal pro Datenbankdatei aus. Jede spätere Verbindung übernimmt den Modus, auch nach einem Neustart. Beweisen Sie dies mit einer neuen Verbindung.

sqlite3 ~/app/app.db "PRAGMA journal_mode;"

Erstellen Sie nun eine Tabelle und prüfen Sie, welche Dateien auf dem Datenträger erscheinen.

sqlite3 ~/app/app.db <<'SQL'
CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL);
INSERT INTO notes (body) VALUES ('first row');
SQL
ls -l ~/app/

Jetzt gibt es drei Dateien: app.db, app.db-wal und app.db-shm. Die Datei -wal enthält festgeschriebene Seiten, für die noch kein Checkpoint ausgeführt wurde. Die Datei -shm enthält einen gemeinsamen Speicherindex, den jede Verbindung einbindet. So stimmen alle Verbindungen über den Inhalt des WAL überein. Beide Dateien gehören zur Datenbank und sind keine temporären Dateien. Wenn Sie app.db allein kopieren, während die Anwendung läuft, fehlt in der Kopie jeder aktuelle Commit. Wenn Sie app.db löschen und die beiden anderen Dateien an ihrem Platz lassen, übernimmt SQLite diese veralteten WAL-Seiten in jede neue Datei, die unter diesem Namen erstellt wird. So beschädigen Sie eine neue Datenbank, wenn Sie versuchen, sie zurückzusetzen.

Die Verbindungseinstellungen, die jede Produktionsanwendung benötigt

Nur journal_mode wird in der Datenbank gespeichert. Jede andere unten aufgeführte Einstellung gilt pro Verbindung. Ihre Anwendung muss sie daher für jede geöffnete Verbindung setzen, einschließlich jeder Verbindung, die ein Pool im Hintergrund erstellt.

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;

busy_timeout = 5000 weist SQLite an, bis zu 5000 Millisekunden lang wiederholt zu versuchen, auf eine gesperrte Datenbank zuzugreifen, bevor database is locked zurückgegeben wird. Der Standardwert ist 0. Daher schlägt SQLite standardmäßig sofort fehl, sobald sich zwei Schreibvorgänge überschneiden. Dieser einzelne Wert beseitigt die meisten Sperrfehler, die fälschlicherweise SQLite selbst zugeschrieben werden.

synchronous = NORMAL ist die richtige Einstellung im WAL-Modus. Die damit verbundene Abwägung müssen Sie verstehen. Bei FULL ruft SQLite bei jedem Commit fsync für das WAL auf. Bei NORMAL synchronisiert SQLite stattdessen bei Checkpoints. Die SQLite-Dokumentation beschreibt den Verzicht eindeutig: Transaktionen sind nach einem Stromausfall oder einem harten Reset nicht mehr dauerhaft gespeichert. Der Datenbank entstehen durch diesen Stromausfall keine Schäden. Sie verlieren lediglich die letzten Commits, die noch nicht auf die Festplatte geschrieben wurden. Auf einem VPS ist dies normalerweise die richtige Abwägung, weil dadurch bei jedem einzelnen Schreibvorgang ein fsync aus dem Ausführungspfad entfernt wird.

foreign_keys = ON ist aus Gründen der Abwärtskompatibilität standardmäßig deaktiviert und gilt pro Verbindung. Ein Schema mit zahlreichen REFERENCES-Klauseln erzwingt überhaupt nichts, solange nicht jede Verbindung diese Einstellung aktiviert.

Eine weitere Einstellung wird erst später relevant. SQLite führt automatisch einen Checkpoint aus, sobald das WAL auf mehr als 1000 Seiten anwächst. Die Arbeit übernimmt die Verbindung, die zu diesem Zeitpunkt zufällig eine Transaktion abschließt. Für sich genommen ist das unproblematisch. Es wird relevant, wenn Litestream ausgeführt wird, weil Litestream steuern möchte, wann Checkpoints stattfinden.

Warum database is locked weiterhin auftritt, nachdem Sie busy_timeout gesetzt haben

Dies ist der Fehler, der viele wieder zu Postgres führt. Er hat eine bestimmte Ursache.

Ein Busy-Timeout installiert einen Busy-Handler. SQLite garantiert jedoch nicht, dass dieser aufgerufen wird.

Wenn SQLite feststellt, dass der Aufruf des Busy-Handlers zu einem Deadlock führen könnte, gibt es stattdessen SQLITE_BUSY an die Anwendung zurück.

Der vermiedene Deadlock tritt beim Upgrade einer Transaktion auf. Ein allein stehendes BEGIN bedeutet in SQLite BEGIN DEFERRED. Wenn die erste Anweisung danach ein SELECT ist, befinden Sie sich in einer Lesetransaktion. Wenn ein späteres UPDATE in derselben Transaktion zu einer Schreibtransaktion werden muss und eine andere Verbindung seit Beginn Ihres Lesevorgangs geschrieben hat, kann SQLite Sie nicht warten lassen. Ihr Snapshot ist bereits veraltet. Durch das Warten würden sich die beiden Verbindungen gegenseitig blockieren. Die Dokumentation beschreibt das Ergebnis direkt:

Nachfolgende Schreibanweisungen aktualisieren die Transaktion zu einer Schreibtransaktion, wenn dies möglich ist, oder geben SQLITE_BUSY zurück.

Ihr Timeout von 5000 Millisekunden wird überhaupt nicht berücksichtigt. Der Fehler tritt sofort auf. Deshalb sieht es so aus, als hätte die Einstellung nichts bewirkt.

Die Lösung besteht aus einem Wort.

BEGIN IMMEDIATE;
UPDATE notes SET body = 'edited' WHERE id = 1;
COMMIT;

BEGIN IMMEDIATE übernimmt die Schreibsperre am Anfang, bevor etwas gelesen wird. Es gibt kein Upgrade. Daher muss kein Deadlock vermieden werden. Der Busy-Handler wird angewendet, und die Verbindung wartet, bis sie an der Reihe ist, statt mit einem Fehler abzubrechen. Lassen Sie schreibgeschützte Transaktionen weiterhin verzögert beginnen. Jede Transaktion, die einen Schreibvorgang enthält, sollte sofort beginnen.

Die zweite Ursache für Sperrfehler ist schwerer zu erkennen: Eine Schreibtransaktion bleibt während langsamer Vorgänge geöffnet. SQLite serialisiert Schreibvorgänge. Eine Transaktion, die geöffnet wird, eine externe API über das Netzwerk aufruft und anschließend einen Commit ausführt, blockiert daher während der gesamten Dauer dieses Aufrufs alle anderen Schreibvorgänge. Lesen Sie die benötigten Daten, schließen Sie die Transaktion, führen Sie den langsamen Vorgang aus und öffnen Sie anschließend eine kurze Schreibtransaktion, um das Ergebnis zu speichern.

Kontinuierliche Sicherung mit Litestream

Eine nächtliche Kopie kann bis zu einen Tag an Schreibvorgängen verlieren. Außerdem kann cp gegen eine aktive SQLite-Datenbank eine Kopie erzeugen, die sich nicht öffnen lässt. Zwei Vorgehensweisen sind sicher. sqlite3 app.db ".backup /path/to/backup.db" verwendet die Online-Backup-Schnittstelle von SQLite und funktioniert mit einer verwendeten Datenbank. Litestream geht weiter: Es überwacht das WAL und überträgt Änderungen kontinuierlich in den Objektspeicher. Dadurch sinkt der mögliche Datenverlust im schlimmsten Fall von einem Tag auf etwa eine Sekunde.

Litestream ist eine einzelne Go-Binärdatei, die neben Ihrer Anwendung läuft. Sie befindet sich nicht zwischen der Anwendung und der Datenbank. Ihre Anwendung schreibt weiterhin unverändert in SQLite. Litestream liest das WAL und lädt die Änderungen hoch.

cd /tmp
curl -fsSL -O https://github.com/benbjohnson/litestream/releases/download/v0.5.14/litestream-0.5.14-linux-x86_64.deb
sudo dpkg -i litestream-0.5.14-linux-x86_64.deb
litestream version

v0.5.14 ist die Version, die auf der offiziellen Linux-Installationsseite im Juli 2026 dokumentiert ist. v0.5.15 folgte am 21. Juli 2026. Ändern Sie die Version in beiden Zeilen so, dass sie dem aktuellen Tag auf der Releases-Seite entspricht. Verwenden Sie stattdessen das passende arm64-Paket, wenn Ihr VPS arm64 verwendet.

Die Konfigurationsdatei befindet sich unter /etc/litestream.yml. Beginnen Sie mit einer lokalen Dateireplikation. Damit prüfen Sie den gesamten Ablauf, ohne Cloud-Anmeldedaten zu benötigen.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      type: file
      path: /var/backups/litestream/app

Beachten Sie, dass das Feld replica im Singular steht. Litestream 0.5 hat das replicas-Array aus der 0.3-Serie durch einen einzelnen Replikatblock ersetzt. Eine Konfiguration mit zwei Einträgen schlägt beim Start nun fehl. Viele Anleitungen von Drittanbietern zeigen weiterhin das alte Array. Übernehmen Sie daher die oben gezeigte Struktur und nicht das erste Beispiel, das eine Suche liefert. In der 0.5-Serie wurde außerdem das Unterkommando litestream wal in litestream ltx umbenannt, weil sich das Format der Sicherungen auf dem Datenträger geändert hat.

Prüfen Sie, ob die Konfiguration geparst werden kann, bevor Sie etwas aktivieren.

sudo litestream databases -config /etc/litestream.yml

Prüfen Sie anschließend den gesamten Ablauf manuell. Diese Form überspringt die Konfigurationsdatei und repliziert eine Datenbank in einen Pfad.

mkdir -p /tmp/replica
litestream replicate ~/app/app.db file:///tmp/replica/app

Der Prozess läuft im Vordergrund weiter. Öffnen Sie eine zweite Shell, schreiben Sie eine Zeile und stellen Sie das Replikat in einer neuen Datei wieder her.

sqlite3 ~/app/app.db "INSERT INTO notes (body) VALUES ('written after replication started');"
litestream restore -o /tmp/restored.db file:///tmp/replica/app
sqlite3 /tmp/restored.db "SELECT count(*) FROM notes;"

Die Anzahl enthält die neue Zeile. Wenn sie nicht enthalten ist, wurde die Änderung noch nicht synchronisiert. Litestream überträgt Änderungen nach einem sync-interval, das standardmäßig 1 Sekunde beträgt. Warten Sie daher und führen Sie die Wiederherstellung erneut aus. Diese eine Sekunde ist außerdem Ihr Wiederherstellungspunkt. Bei einem Absturz gehen höchstens die Schreibvorgänge aus dem letzten Synchronisierungsintervall verloren. Keine Konfiguration kann diesen Wert auf null setzen.

Für einen echten Speicher ersetzen Sie den Replikatblock durch eine S3-URL. Dies funktioniert mit Amazon S3 und mit S3-kompatiblem Objektspeicher anderer Anbieter.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      url: s3://your-bucket-name/app
      region: us-east-1

snapshot:
  interval: 24h
  retention: 24h

Bewahren Sie die Anmeldedaten nicht in dieser Datei auf. Litestream liest LITESTREAM_ACCESS_KEY_ID und LITESTREAM_SECRET_ACCESS_KEY aus der Umgebung. Legen Sie sie daher in einem systemd-Drop-in ab, das root gehört und den Modus 600 hat.

Die oben gezeigten Snapshot-Werte sind die Standardwerte. Der Standardwert für die Aufbewahrung führt häufig zu Missverständnissen. Die Aufbewahrung gibt an, wie lange Litestream Snapshots und die zugehörigen Dateien behält. Sie bestimmt damit auch, wie weit Sie in der Zeit zurück wiederherstellen können. Bei vierundzwanzig Stunden ist eine fehlerhafte Migration, die Sie am Mittwochmorgen bemerken, anhand des Zustands von Montag bereits nicht mehr wiederherstellbar. Setzen Sie retention: 168h auf eine Woche und akzeptieren Sie den zusätzlichen Speicherbedarf.

Weisen Sie die Wiederherstellung nach, bevor Sie sie benötigen

litestream restore -o /tmp/check.db /home/appuser/app/app.db
sqlite3 /tmp/check.db "PRAGMA integrity_check;"
sqlite3 /tmp/check.db "SELECT count(*) FROM notes;"

Bei Angabe eines Datenbankpfads sucht litestream restore das passende Replikat in /etc/litestream.yml und lädt es herunter. PRAGMA integrity_check gibt bei einer intakten Datei ok aus. Jede andere Ausgabe bedeutet, dass die wiederhergestellte Kopie nicht verwendbar ist. Führen Sie diesen Vorgang regelmäßig mit einem systemd-Service und Timer aus und lesen Sie die Ausgabe. Solange Sie eine Sicherung nicht mindestens einmal wiederhergestellt haben, wissen Sie nicht, ob sie funktioniert.

Litestream unter systemd ausführen

Das Debian-Paket installiert eine litestream-Unit, die /etc/litestream.yml liest.

sudo systemctl enable litestream
sudo systemctl start litestream
sudo journalctl -u litestream -f

Eine erfolgreiche Ausgabe nennt jede Datenbank aus der Konfiguration und bleibt anschließend bis auf regelmäßige Synchronisierungszeilen still. Ein Fehler no such file or directory für den Pfad Ihrer Datenbank bedeutet, dass der Pfad in der Konfiguration falsch ist oder der Prozess die Datenbank nicht lesen kann. Die Unit wird standardmäßig als root ausgeführt. Das erfordert mehr Berechtigungen als nötig. Litestream muss sowohl die Datenbank als auch das Verzeichnis, in dem sie liegt, lesen und beschreiben können. Dazu verwendet es die -wal- und -shm-Dateien neben Ihrer Datenbank. Geben Sie daher das Konto an, das Ihre Anwendung bereits verwendet.

# /etc/systemd/system/litestream.service.d/override.conf
[Service]
User=appuser
Group=appuser

Wenden Sie die Änderungen mit sudo systemctl daemon-reload und sudo systemctl restart litestream an. Ein dediziertes Dienstkonto mit den geringsten erforderlichen Berechtigungen einzurichten dauert nur wenige Minuten. Dadurch läuft auf dem System kein zweiter root-Prozess, sondern nur ein Backup-Agent.

Eine Reihenfolge ist wichtig, wenn Sie den Rechner vollständig neu aufbauen. Die Datenbank muss wiederhergestellt werden, bevor die Anwendung startet. litestream restore akzeptiert -if-db-not-exists. Der Befehl beendet sich mit dem Status 0, wenn die Datei bereits vorhanden ist. Daher kann er bei jedem Systemstart ausgeführt werden. Fügen Sie ihn in einer ExecStartPre-Zeile der Unit Ihrer Anwendung ein. Ein neues VPS lädt dann die Datenbank herunter, während ein bereits eingerichtetes System nichts tut. litestream replicate bietet ein entsprechendes -restore-if-db-not-exists-Flag, falls Sie diese Einstellung lieber an einer Stelle verwalten möchten.

Wo SQLite auf einem VPS an Grenzen stößt

Netzwerkdateisysteme. Diese Einschränkung lässt sich nicht durch Konfiguration umgehen. Der WAL-Modus erfordert, dass jeder Prozess, der die Datenbank verwendet, einen kleinen Speicherbereich gemeinsam nutzt. Diese Funktion stellt die Datei -shm bereit. Die SQLite-Dokumentation formuliert die Regel ohne Einschränkung:

Alle Prozesse, die eine Datenbank verwenden, müssen sich auf demselben Hostcomputer befinden. WAL funktioniert nicht über ein Netzwerkdateisystem.

Eine Datenbank auf einer eingebundenen NFS-Freigabe (Network File System) oder SMB-Freigabe kann daher beschädigt werden. Kein Pragma verhindert das. Dabei wird häufig eine wichtige Unterscheidung übersehen. Ein Netzwerk-Blockgerät, wie es die meisten VPS-Anbieter als zusätzlichen Speicher bereitstellen, erscheint für Linux als gewöhnliche Festplatte mit einem gewöhnlichen Dateisystem. Das ist unproblematisch. Eine eingebundene Dateifreigabe ist es nicht.

Ein zweiter Anwendungsserver. Keine Einstellung ermöglicht diesen Betrieb. Sobald zwei Rechner dieselben Daten bereitstellen müssen, benötigen Sie eine Datenbank, die über das Netzwerk kommuniziert. Entscheiden Sie sich für diesen Wechsel, solange Sie noch Zeit für die Planung haben.

Schreibintensive Arbeitslasten. Dass immer nur ein Prozess schreibt, ist eine Eigenschaft des Dateiformats und keine konfigurierbare Option. Kurze Schreibvorgänge sind günstig, weil jeder Commit an das WAL angehängt wird. Der Durchsatz hängt daher stärker von der Latenz kleiner Schreibvorgänge Ihres Datenträgers ab als von Ihrer CPU. Unter NVMe im Vergleich zu SATA-SSD-Speicher auf einem VPS sehen Sie, wie sich dieser Unterschied auswirkt. Lange Transaktionen sind das eigentliche Problem, weil sie alle anderen Schreibvorgänge in eine Warteschlange dahinter stellen.

Analytische Abfragen. SQLite ist ein zeilenorientierter Speicher, der für Transaktionen entwickelt wurde. Ein Dashboard, das hundert Millionen Zeilen durchsucht, ist eine andere Aufgabe für ein anderes Werkzeug. DuckDB im Vergleich zu SQLite für Serveraufgaben beschreibt, wo diese Grenze liegt.

VACUUM bei Replikation. Ein vollständiges VACUUM schreibt die gesamte Datenbankdatei neu. Litestream muss sie daher erneut vollständig hochladen. Die Litestream-Dokumentation rät davon ab, den Vorgang während aktiver Replikation direkt auszuführen. Stoppen Sie den Replikator, führen Sie den Vacuum-Vorgang aus, starten Sie ihn erneut und rechnen Sie mit einem neuen vollständigen Snapshot.

Zwei Replikatoren für eine Datenbank. Führen Sie niemals zwei Litestream-Prozesse für dieselbe Datenbank oder dasselbe Replikationsziel aus. Die Dokumentation stellt ausdrücklich klar, dass Sie dies verhindern müssen. Andernfalls erhalten Sie eine Replik, die Sie nicht wiederherstellen können.

Was Litestream nicht abdeckt

Litestream schützt die Datenbankdatei und nichts anderes. Hochgeladene Dateien, die Anwendungskonfiguration, TLS-Zertifikate (Transport Layer Security) und die Unit-Dateien müssen Sie weiterhin selbst verwalten. Kombinieren Sie Litestream nach einem Zeitplan mit verschlüsselten Backups außerhalb des Servers mit restic, damit beide Bereiche abgedeckt sind. Wenn die Maschine neu ist, beschreibt die ersten zehn Minuten auf einem neuen VPS die Einrichtung des Benutzerkontos und der Firewall, die in dieser Anleitung vorausgesetzt wird.

FAQ

Ist SQLite für eine Produktionsanwendung ausreichend?

Für eine Anwendung auf einem Server: ja, sofern Sie den WAL-Modus aktivieren, ein busy timeout festlegen und kontinuierliche Sicherungen erstellen. Die relevanten Grenzen sind strukturell: Es gibt jeweils nur einen Schreibvorgang gleichzeitig und nur einen Hostcomputer. Eine Anwendung innerhalb dieser Grenzen erhält eine Datenbank ohne Netzwerklatenz und ohne separaten Prozess, den Sie überwachen müssen. Eine Anwendung außerhalb dieser Grenzen benötigt eine Client-Server-Datenbank. Keine Optimierung ändert daran etwas.

Warum erhalte ich nach dem Setzen von busy_timeout weiterhin database is locked?

Weil SQLite den busy handler überspringt, wenn das Warten zu einem Deadlock führen könnte. Eine Transaktion, die mit einem einfachen BEGIN beginnt, ist verzögert: Ein einleitendes SELECT versetzt sie in eine Lesetransaktion, und ein späterer Schreibvorgang muss die Transaktion hochstufen. Wenn eine andere Verbindung dazwischen geschrieben hat, gibt SQLite sofort SQLITE_BUSY zurück, statt Ihren busy handler aufzurufen, weil Ihr Lesesnapshot bereits veraltet ist. Starten Sie jede Transaktion, die schreiben soll, mit BEGIN IMMEDIATE. Dadurch wird die Schreibsperre sofort übernommen und das Timeout gilt.

Kann ich meine SQLite-Datenbank auf Netzwerkspeicher ablegen?

Nicht auf einem Netzwerkdateisystem wie NFS oder SMB. Der WAL-Modus benötigt, dass alle Prozesse den Speicher über die Datei -shm gemeinsam nutzen. Laut der SQLite-Dokumentation muss sich jeder Prozess, der die Datenbank verwendet, auf demselben Hostcomputer befinden. Ein von Ihrem Anbieter angeschlossenes Netzwerkblockgerät ist etwas anderes: Linux erkennt darauf eine normale Festplatte mit einem normalen Dateisystem, und SQLite funktioniert dort.

Benötige ich Litestream, wenn ich bereits nächtliche Sicherungen ausführe?

Das hängt davon ab, wie viele Daten Sie verlieren können. Bei einem nächtlichen Auftrag verlieren Sie möglicherweise bis zu vierundzwanzig Stunden an Schreibvorgängen. Litestream synchronisiert ungefähr einmal pro Sekunde. Bei einem Absturz verlieren Sie daher ungefähr die Schreibvorgänge der letzten Sekunde. Litestream ist außerdem sicherer als das Kopieren der Datenbankdatei mit cp, da dadurch eine Datenbank während eines Schreibvorgangs erfasst werden kann. Litestream deckt nur die Datenbank ab. Lassen Sie daher zusätzlich eine allgemeine Dateisicherung laufen.