在 Linux 上部署 SQLite 防止数据丢失，核心在于将数据库文件的所有权交给运行应用的用户，并限制其他用户的写入权限，同时开启 WAL 模式增强崩溃恢复能力。

命令速用版

假设数据库文件为 app.db，运行应用的用户为 www-data：

# 修改所有者
chown www-data:www-data /path/to/app.db
# 设置权限（仅所有者读写）
chmod 600 /path/to/app.db
# 进入 sqlite 开启 WAL 模式
sqlite3 /path/to/app.db "PRAGMA journal_mode=WAL;"

为什么会这样

SQLite 是嵌入式数据库，数据存储为普通文件，没有内置的用户认证系统，其安全性主要由文件系统的访问控制列表决定。如果权限设置过于宽松（如 777），任何用户都可能修改或删除数据库文件，导致数据丢失或损坏。此外，SQLite 默认依赖操作系统层面的文件权限控制，缺乏原生加密支持，因此文件权限是第一道防线。

分步处理

1. 确认运行用户
首先确定你的应用程序是以哪个用户身份运行的。常见的 Web 服务用户可能是 www-data、nginx 或自定义用户。使用 ps -ef | grep 进程名 查看。

2. 修改文件所有权
将数据库文件及其所在目录的所有者改为应用用户。例如：
chown -R www-data:www-data /path/to/data/
这确保只有该用户拥有控制权，避免其他用户误操作。

3. 设置严格权限
对数据库文件设置 600 权限（仅所有者读写），对目录设置 700（仅所有者读写执行）。
chmod 600 /path/to/app.db
chmod 700 /path/to/data/
这能防止未授权用户读取敏感数据或写入垃圾数据。

4. 启用 WAL 模式
在 SQLite 中执行 PRAGMA journal_mode=WAL;。WAL（Write-Ahead Logging）模式可以将数据更改记录在日志文件中，发生故障时通过回放日志恢复数据，减少因并发或断电导致的数据损坏风险。

5. 配置定期备份
权限只能防止人为误删或未授权修改，无法防止磁盘故障。建议使用 rsync 或 cron 任务定期备份数据库文件到独立存储位置。

怎么验证是否生效

1. 检查权限位
执行 ls -l /path/to/app.db，确认输出类似 -rw------- 1 www-data www-data。前九个字符应为 rw-------，所有者应为应用用户。

2. 测试写入
切换到应用用户执行写入操作，确认成功；切换到其他用户尝试写入，确认被拒绝（Permission denied）。

3. 检查 WAL 文件
开启 WAL 模式后，数据库同级目录下应出现 -wal 和 -shm 后缀的文件，表明模式已生效。

常见坑

1. 权限过宽导致风险
避免使用 777 权限。虽然这能解决“无法写入”的报错，但会让任何用户都能删除或篡改数据库，极大增加数据丢失风险。

2. 版本兼容性问题
如果在不同系统间迁移数据库文件（如 Windows 到 Linux），需注意 SQLite 版本差异。旧版本可能无法识别新版本生成的 WAL 模式文件，报“文件已加密或损坏”错误。确保两端 SQLite 版本一致。

3. 忽略备份
文件权限是访问控制，不是数据冗余。即使权限设置完美，硬件故障仍可能导致数据丢失，必须配合定期备份。

参考来源

• OSCHINA - Linux 文件权限管理策略确保文件安全防止误删
• CSDN 博客 - 【SQLite 安全存储指南】:PHP 开发者必须知道的 6 个数据保护实践
• 腾讯云开发者社区 - SQLite3 数据库文件 - 仅在 Linux 上损坏/加密
• Linux 文件权限设置：如何保护重要数据
• sqlite 实时数据库怎样避免数据丢失