SQLite 的备份不仅包括导出数据,还包括在线热备、数据恢复以及应对损坏场景的急救方案。本文将介绍多种备份策略和恢复手段。
SQLite 提供了 Online Backup API,允许在数据库正在被读写的情况下进行一致性备份。这是最推荐的备份方式,不会阻塞业务。
通过命令行 sqlite3 工具可以很方便地使用:
# 在内存中创建源数据库的备份 sqlite3 source.db ".backup main backup.db" # 或者使用 dump 方式(生成 SQL 文本) sqlite3 source.db ".dump" > backup.sql
在编程语言中(如 Python),利用 sqlite3 模块的 backup 方法:
import sqlite3 def backup_db(src, dst): src_conn = sqlite3.connect(src) dst_conn = sqlite3.connect(dst) with dst_conn: src_conn.backup(dst_conn) src_conn.close() dst_conn.close()
这种方法使用的是 API 的逐步复制机制,即使在备份过程中有写入操作,也能保证备份文件是一个完整的一致性快照。
物理备份:直接复制 .db 文件(以及 .wal 和 .shm 文件)。前提:必须确保数据库处于一致性状态。
方法:执行 PRAGMA wal_checkpoint(TRUNCATE); 将 WAL 日志合并回主库并清空日志,然后复制文件。
逻辑备份:使用 .dump 导出 SQL 语句。
优点:可读性高,可以跨版本恢复,能过滤特定的表。
缺点:恢复速度较慢,尤其是对于大型数据库。
SQLite 以稳健著称,但异常断电、磁盘故障或 NFS 滥用仍可能导致数据库损坏。当数据库损坏时,常见的错误码是 SQLITE_CORRUPT。
.recover 命令(SQLite 3.29.0+):这是官方提供的“救命稻草”。即使数据库头部损坏或部分数据不可读,.recover 也会尽力从文件中提取所有可能的数据。
# 尝试从损坏的数据库中恢复数据 sqlite3 corrupted.db ".recover" > recovered.sql # 导入到新库 sqlite3 new.db < recovered.sql
PRAGMA integrity_check:定期执行完整性检查,尽早发现潜在的数据损坏迹象。
PRAGMA quick_check:比 integrity_check 更快,适合在生产环境高频监控。
对于大规模数据库,全量备份代价高昂。可以利用 SQLite 的 WAL 模式实现增量备份:
备份基础数据库文件(如每天凌晨备份一次)。
定期备份 .wal 文件。
恢复时,将基础文件复制回来,然后合并最新的 .wal 文件。
注意,管理 .wal 文件需要小心处理 Checkpoint 的时机,否则 .wal 可能会被清空。