01先列出真正需要保存的东西
把数据分成几类：无法重新生成的业务数据、服务配置、部署脚本，以及可以重新构建的产物。优先保护前两类；缓存和下载包一般不值得与重要数据使用相同的保留策略。
证书私钥、访问令牌和数据库备份可能包含敏感信息。备份副本应限制访问权限；需要加密时，恢复所需的密钥必须另行保管，不能只存在被备份的机器上。
02数据库需要一致的快照
直接复制正在写入的数据库文件可能得到不一致的状态。应优先使用数据库提供的备份接口或一致性导出方式。SQLite 可以使用在线备份接口；启用 WAL 后，更不能把主文件的一次普通复制当作完整备份。
如果没有在线备份能力，可以在维护窗口停止写入后再备份，并明确记录停机时间。具体方法要与数据库类型及业务恢复要求相匹配。
03让失败能够被发现
记录每次备份的时间、大小和校验值，并设置保留周期。某天备份突然变成几百字节，即使命令成功退出，也值得检查。远端副本和原始数据放在不同故障域，才能应对整机损坏。
不要把同步等同于备份：删除操作也可能立即同步到另一端。保留历史版本可以降低误删风险，但版本数量要结合数据增长和可用空间设计。
04在临时目录恢复并核对
恢复演练应写入隔离目录或测试环境，避免覆盖现有数据。先检查文件数量、校验值和权限，再尝试让应用读取恢复的数据。对于数据库，还要验证记录数量和关键查询。
最后记录恢复耗时与依赖：需要哪些软件、哪把密钥、哪份配置？这些信息构成一份简短的恢复手册。备份的价值，在于你知道如何把它重新变成可用服务。