备份不是“把文件复制一份”，而是保证业务连续性的最后一道防线。本小节从实用角度出发，梳理一套可立即落地的备份策略和灾难恢复预案。
1. 明确备份对象与优先级
不要笼统地“全盘备份”，而是按业务影响分级：
- 核心数据：数据库、配置文件、用户生成的内容（如
/var/lib/mysql、/etc、/home）。恢复时最优先处理。 - 应用程序与环境：Web 服务目录、自定义脚本、编译安装的软件。可用版本管理（Git）+ 包列表（
dpkg --get-selections或rpm -qa）相结合的方式备份。 - 系统镜像：干净的基础系统安装后做一次镜像备份，便于快速重建节点。只在系统大版本升级或季度维护时更新。
2. 备份策略：全量 + 增量的组合
- 每日增量备份：对变化频繁的数据（如数据库、日志）使用增量备份，减小备份窗口和存储消耗。
- 每周全量备份：定期做一次完整快照，避免增量链断裂时无法恢复。
- 保留策略：按“3-2-1 原则”（3份副本，2种不同介质，1份异地存储）规划。例如：本地备份服务器保留近 7 天的增量 + 4 周的全量；异地对象存储（或另一机房）保留近 3 个月的关键数据。
3. 实用备份工具选择
- 文件级备份：
rsync：适合网站目录、配置文件，配合--link-dest可实现类增量快照，占用空间小。tar+cron：简单可靠，适合打包/etc、/home等，可配合gpg加密后传输。- 数据库备份：
- MySQL/PostgreSQL：使用自带的
mysqldump或pg_dump，务必加--single-transaction（InnoDB）或同等选项确保一致性。大规模实例用xtrabackup（Percona）做物理热备。 - 块级 / 快照备份：
- 使用 LVM 快照，在冻结文件系统后做一致性快照，再挂载备份。
- 云环境直接使用云厂商的磁盘快照功能（如 AWS EBS Snapshot、阿里云快照）。
- 裸机恢复：
dd或partclone做全盘镜像，适合完全不可中断的系统，但体积大、效率低。- 推荐“重建系统 + 恢复数据”的方式：用 kickstart/preseed 自动安装基础系统，然后恢复配置和数据，比全盘恢复更灵活。
4. 灾难恢复预案（DRP）要素
- 文档化：用简单的 Markdown 或 Wiki 记录恢复步骤，包含：
- 恢复优先级与互相依赖关系（先恢复数据库，再恢复应用）。
- 准确的路径、命令、验证方法（如“恢复后运行
php artisan health”）。 - 网络、IP、主机名等配置模板。
- 最小恢复单元演练：每季度至少做一次模拟恢复，从备份中拉取核心数据库并启动应用，确保流程真实可用。
- 人员与权限：确保至少 2 名运维人员有访问备份存储和执行恢复的权限，且相关内容不依赖某个人脑中的记忆。
- 紧急联系方式：整理 IDC 机房、云服务商、关键业务负责人的联系方式，打印出来或存放在独立于生产系统的通讯渠道中。
5. 验证与监控
备份若不验证，等于没有备份。
- 自动验证脚本：备份完成后自动解压检查文件列表、校验 MD5/SHA256 或尝试启动数据库恢复测试（在隔离环境中）。
- 监控告警：备份失败、空间不足、备份耗时异常时，立即通过邮件、企业微信等方式通知相关人员。
- 定期全流程演练：至少每年一次，在备用硬件或临时虚拟机中完整还原业务环境，记录实际耗时和改进点。
6. 快速恢复步骤示例（以 LAMP 应用为例）
- 准备基础系统：使用相同发行版的 ISO 最小化安装，配置网络和 SSH。
- 恢复系统配置：将备份的
/etc覆盖，重启相关服务。 - 恢复数据库：
mysql < backup.sql，检查表状态。 - 恢复应用代码：
rsync -a backup/app/ /var/www/app/ - 调整权限：
chown -R www-data:www-data /var/www/app/ - 启动应用并执行冒烟测试（访问首页、登录、核心 API）。
备份与灾难恢复本质上是风险管理和流程纪律。保持脚本简单、文档清晰、演练频繁，远比堆积昂贵工具更有效。