SQLite: kopia bazy pracującej w trybie WAL

Zrozum zestaw plików

Przy trybie WAL świeże zatwierdzone zmiany mogą znajdować się w pliku -wal, a nie wyłącznie w głównym .db. Ręczne skopiowanie tylko jednego pliku podczas pracy aplikacji nie jest uniwersalną metodą tworzenia spójnej kopii. Nie usuwaj plików WAL i SHM, żeby „naprawić” aktywną bazę.

Użyj mechanizmu backupu

Przykład korzysta ze standardowego modułu Pythona. Docelowy plik ma unikalną nazwę i nie nadpisuje poprzedniej kopii. Konto wykonujące operację potrzebuje dostępu do źródła oraz katalogu kopii.

import sqlite3
from datetime import datetime, timezone
from pathlib import Path

backup_dir = Path("backups")
backup_dir.mkdir(exist_ok=True)
stamp = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ")
source = sqlite3.connect("file:app.db?mode=ro", uri=True)
target = sqlite3.connect(backup_dir / f"app-{stamp}.db")
try:
    source.backup(target, pages=100, sleep=0.1)
finally:
    target.close()
    source.close()

Tryb mode=ro zapobiega przypadkowemu utworzeniu pustej bazy po pomyłce w ścieżce. Backup online może współpracować z aktywną aplikacją, lecz przy intensywnych zapisach wymaga obserwacji czasu wykonania i dostępnego miejsca.

Zweryfikuj kopię osobno

Na kopii uruchom PRAGMA integrity_check; lub odpowiedni test integralności. Wynik ok nie dowodzi, że aplikacja zawiera oczekiwane dane. Sprawdź także liczbę kluczowych rekordów, wersję schematu i możliwość otwarcia kopii przez zgodną wersję programu. Dane logowania i klucze szyfrujące mogą wymagać osobnego zabezpieczenia.

Odtwarzanie to procedura

Zatrzymaj procesy korzystające z docelowej bazy, zachowaj obecną wersję do analizy i dopiero potem wykonuj kontrolowane odtworzenie. Nie podmieniaj pojedynczego pliku pod pracującym procesem. Test odtworzenia przeprowadzaj regularnie w oddzielnym katalogu; sam fakt powstania archiwum nie potwierdza, że da się z niego uruchomić usługę.

Czytaj dalej