SQLiteのバックアップはファイルを作れたことと、その中身を読めることを分けて確かめます。保存先を取り違えたり、空のDBを控えとして残したりしても、ファイルの存在確認だけでは気づけません。
Pythonのsqlite3には、接続したDBを別の接続先へ複写するbackupがあります。作成後は元とは別の接続で開き、必要なテーブル、件数、確認用の値を読み戻します。
架空DBを別ファイルへ保存する
次は三件の架空データを持つメモリーDBを、一時フォルダーへ保存する例です。実際の台帳は開きません。保存先はこの例のための新しい場所で、既存のバックアップを上書きしません。
import sqlite3
from pathlib import Path
from tempfile import TemporaryDirectory
source = sqlite3.connect(":memory:")
try:
source.execute("CREATE TABLE tickets(id TEXT PRIMARY KEY NOT NULL)")
with source:
source.executemany(
"INSERT INTO tickets VALUES (?)", [("T1",), ("T2",), ("T3",)]
)
with TemporaryDirectory() as directory:
target = Path(directory) / "practice-backup.sqlite3"
if target.exists():
raise FileExistsError(target)
destination = sqlite3.connect(target)
try:
source.backup(destination)
finally:
destination.close()
check = sqlite3.connect(target.as_uri() + "?mode=ro", uri=True)
try:
count = check.execute("SELECT count(*) FROM tickets").fetchone()[0]
integrity = check.execute("PRAGMA integrity_check").fetchone()[0]
print("バックアップの件数:", count)
print("整合性確認:", integrity)
assert count == 3 and integrity == "ok"
finally:
check.close()
finally:
source.close()
保存したDBの件数は3、integrity_checkはokになります。Windows・Python 3.12.10・SQLite 3.49.1で、このバックアップと別接続からの読み戻しを確認しました。稼働中の業務DBや並行更新を試験した結果ではありません。
元の入力はwithブロックを抜けて確定した後、backupを呼んでいます。未確定の書き込みを残したまま実行する構成へ、そのまま移さないでください。
okでも必要な情報を比べる
integrity_checkはDB内部の整合性を調べるためのものです。担当者が必要とする最新の明細が入っているか、対象期間が正しいか、業務上の金額が合っているかまで判断する検査ではありません。
実際の確認では対象DBの識別情報、作成日時、必要なテーブルの件数や代表的な値を合わせます。個人情報を含む行を、確認ログへ無条件で複写する必要はありません。
保存と復旧の手順を分ける
バックアップを作る場所と、復元を試す場所は元のDBと分けます。復元できるか確認するために、稼働中の台帳をそのまま置き換える手順にはしません。
使用中のSQLiteファイルを単純にコピーする運用では、関連ファイルや更新中の状態も考慮する必要があります。backupを使ったことだけで、保存世代、権限、保管先、障害時の取り出し方まで整ったとは言えません。
例の一時フォルダーは処理終了時に片付けられる練習用です。実際のバックアップとして残すなら、保存先、保持する世代、確認日、復元担当を決めてください。既存ファイルの存在確認も同時実行の競合まで防ぐ仕組みではないため、複数の処理が同じ出力名を使わない設計も必要です。
DBの基本操作はSQLite入門、保管する対象と世代の整理は自動化ツールのバックアップ設計で補えます。
参考資料
Python sqlite3とSQLite Backup APIの公式資料を2026年11月1日に確認しました。
