备份文件严禁放在public/目录下，必须存于Web不可访问路径（如runtime/backup/），命名需含数据库名、秒级时间戳和明确后缀，备份后须用sha256sum校验并记录日志，文件权限应设为0600且属主为Web进程用户。
备份文件不能放在public/目录下
直接把 backup_20260625.sql 丢进 public/ 目录，等于把数据库明文挂在网上。任何人拼出 URL 就能下载，比如 https://yoursite.com/public/backup_20260625.sql —— 这不是备份，是泄密。
必须存到 Web 进程不可直接访问的路径：
-
runtime/backup/（ThinkPHP 默认 runtime 受 .htaccess 或 nginx location 保护） -
/data/backups/（绝对路径，需确保 PHP 进程有写权限） -
/var/backups/yourapp/（Linux 系统级路径，更隔离）
确认路径权限：Web 用户（如 www-data）可写，但 HTTP 服务器无法通过 URL 映射到该目录。用 curl https://yoursite.com/runtime/backup/ 测试是否返回 403 或 404。
文件名必须含时间戳和数据库名
用 backup.sql 这种固定名，下次备份就覆盖前一次，真出事时只剩最后一份——而它可能已损坏或不完整。
立即学习“PHP免费学习笔记（深入）”；
命名规则要带三要素：
- 数据库名（区分多库场景）
- 精确到秒的时间戳（避免并发备份冲突）
- 后缀明确（
.sql或.sql.gz）
推荐格式：backup_shop_20260625183402.sql。PHP 中可用：date('YmdHis') 生成时间部分，别用 time()——它不含前导零，排序会乱。
备份后必须校验完整性
磁盘静默损坏、写入中断、空间不足都可能导致备份文件“看似存在，实际残缺”。只检查文件大小 > 0 毫无意义。
安全做法是立即计算哈希并落日志：
- 用
sha256sum /data/backups/backup_shop_20260625183402.sql得到校验值 - 把结果写进
runtime/logs/backup.log，格式如：[2026-06-25 18:34:02] backup_shop_20260625183402.sql → a1b2c3... - 还原前先比对哈希，不一致则拒绝导入
别跳过这步——99% 的备份失效案例，都是恢复时才发现文件打不开或语法报错，而日志里早有哈希不匹配记录。
权限设置不能依赖默认值
Linux 下 PHP 写出的文件，默认权限常是 644（owner 可读写，group/other 只读）。但这不够：其他用户仍可能读取备份文件。
必须显式收紧：
- 创建目录时设权限：
mkdir -m 700 /data/backups - 写文件时加
0600：file_put_contents($path, $content, LOCK_EX | FILE_APPEND)不够，得用chmod($path, 0600) - 确认属主是 Web 进程用户（如
chown www-data:www-data /data/backups）
尤其注意容器环境：挂载卷的初始权限可能覆盖 PHP 的 chmod，得在 entrypoint 脚本里预设目录权限。
