博客能打开以后，我开始补备份。最初容易以为把 Typecho 文件夹压缩一下就够了，后来发现文章、图片和程序配置分散在不同位置，少一部分都可能导致恢复后的站点不完整。
先把数据分清楚
文章、评论、分类、账号与大部分设置在 MySQL 数据库；上传的封面和头像在网站目录；Nginx、PHP-FPM、MySQL 的运行参数在系统配置目录。它们共同组成网站。
我目前的正式脚本是 /opt/backup_secure.sh，每天凌晨 03:00 运行，备份分为：
| 目录 | 保存什么 |
|---|---|
| /opt/backups/database | Typecho 数据库导出 |
| /opt/backups/website | 网站程序、主题和上传图片 |
| /opt/backups/config | LNMP、系统服务和监控配置 |
| /opt/backups/grafana | Grafana 数据库 |
| /opt/backups/logs | 备份过程日志 |
备份保留 30 天，日志按脚本策略保留 60 天。这里记录的是本站方案，不能直接套用到容量和业务要求不同的服务器。
数据库与文件怎么保持可靠
数据库使用 mysqldump 的 --single-transaction 和 --quick。前者适合 InnoDB 表的一致性导出，后者让客户端逐行读取，避免一次把整个结果装进内存。备份期间仍应避免表结构变更；非事务表不能因此获得相同的一致性保证。
凭据由受权限保护的配置文件提供，不把密码拼在命令行或博客示例中。导出压缩后用 gzip -t 检查；网站和配置归档用 tar -tzf 验证是否能读取。
脚本先写临时文件，检查成功后再改成正式文件名。这样失败的半成品不会被误认成一次完整备份。全部成功以后才清理过期副本，避免“新备份失败，旧备份却先被删掉”。
为什么 Grafana 也在里面
仪表盘、账号和设置不全是配置目录里的 YAML。本站 Grafana 使用 SQLite，服务运行期间直接复制数据库文件可能遗漏尚在写入的状态，所以采用 SQLite 在线备份接口，再检查数据库完整性。
监控配置备份也包含邮件通知配置。归档中可能有授权码、证书私钥等秘密，因此备份目录只允许管理用户访问，不能把整个压缩包当学习资料公开。
日常怎样检查
crontab -l
ls -lh /opt/backups/database/
ls -lh /opt/backups/website/
ls -lh /opt/backups/config/
ls -lh /opt/backups/grafana/看最近生成时间、文件大小和日志退出结果；不要只看到文件名就认定成功。每天一次全量备份意味着两次成功备份之间仍可能丢失新增数据。现在采用服务器内备份，无法抵御整盘损坏；下一步需要恢复演练，再考虑异地副本。
文件一致性与保留时间
数据库一致性快照不等于上传文件与 SQL 的跨系统一致性。上传或主题变更频繁时，应规划短暂写入冻结或应用级一致性流程。每天备份也不保证永远满足 24 小时 RPO，任务失败会扩大缺口。30 天与 60 天是脚本保留策略，手工变更备份另有管理方式；请按实际文件清单与日志判断，不要默认任意旧快照都还存在。
内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。
评论 (0)