订单、用户信息和财务流水一旦找不回来，影响会直接落到客户体验和经济损失上。备份要在上线前就设计好，出了事再补，通常已经来不及。
这篇文章从运维的角度讲三件事：阿里云数据库备份有哪些方式，怎么配置，出问题时怎么恢复。最后用一个误操作的场景，说明恢复的每一步怎么走。
一、默认备份为什么不够用
很多团队建库时开一个默认备份，之后就不再看它。数据量小、变化慢的时候，这样问题不大。业务一增长，问题会陆续出现：
- 备份频率跟不上业务：每天凌晨做一次全量，最坏情况下会丢掉接近一整天的数据。
- 保留周期太短：问题第三天才被发现，需要的备份早已被覆盖。
- 没有试过恢复：备份文件存在，不代表能还原。不少事故是在真正恢复时才暴露出问题。
- 备份和主库放在同一区域：遇到区域级故障，两份数据会一起受影响。
选备份方案前，先确定两个数。RPO是最多能接受丢失多少数据，RTO是服务最长能停多久。RPO决定备份频率，以及是否需要时间点恢复。RTO决定恢复流程要不要提前演练，要不要预留临时实例。这两个数定不下来，就无法判断一套备份方案好不好。
二、阿里云RDS常见的三种备份方式
以阿里云关系型数据库（RDS MySQL、PostgreSQL、SQL Server）为例，常用的备份方式有以下三种。
1. 自动备份
实例创建后，在控制台设置备份时间窗口和保留天数即可。自动备份一般由全量备份加日志备份组成，支持按时间点恢复（PITR），也就是把实例还原到某个具体时刻。大部分业务用它就够了。
2. 手动备份
大版本升级、批量清洗数据、调整表结构之前，手动触发一次全量备份。手动备份不受自动策略的保留周期影响，不会被自动清理，适合当作变更前的还原点。记下备份ID，出问题时能快速定位。
3. 导出到OSS做异地存储
合规要求高的业务，可以定期把逻辑备份导出到对象存储OSS，必要时放到另一个地域。常见做法是用mysqldump、pg_dump生成逻辑备份，再上传到OSS，并开启版本控制和生命周期规则。逻辑备份便于跨版本迁移和单表还原，但数据量大时导出和导入都慢，不适合作为唯一的恢复手段。
下面是一个逻辑备份的示例脚本，仅供参考，使用前按实际环境修改：
#!/bin/bash
# 逻辑备份示例：导出MySQL数据库并压缩
DB_HOST="rm-xxxxxxxx.mysql.rds.aliyuncs.com"
DB_USER="backup_user"
DB_NAME="app_db"
BACKUP_DIR="/data/backup"
DATE=$(date +%Y%m%d_%H%M%S)
mysqldump -h "$DB_HOST" -u "$DB_USER" -p"$DB_PASSWORD" \
--single-transaction --routines --triggers \
"$DB_NAME" | gzip > "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz"
# 上传至OSS（需已安装并配置ossutil）
ossutil cp "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz" oss://your-backup-bucket/mysql/
密码要通过环境变量或密钥管理服务注入，不要写进脚本。另外，-p 参数会让密码出现在进程列表里。生产环境可以改用权限受限的 --defaults-extra-file 配置文件。
三、一个误操作的恢复场景
下面这个场景是为了说明恢复流程而设计的，并非某个团队的实际记录。假设某电商团队在大促前调整订单库结构，脚本执行时误删了一批历史订单的关联数据，第二天上午客服才发现问题。
排查时，团队先查看自动备份。备份每天凌晨两点执行，保留7天。事故发生在下午，最近的可用备份距离误操作约有12小时的数据间隔。好在实例开启了RDS时间点恢复，可以还原到误操作前一分钟的状态。
恢复分五步进行：
- 用审计日志确认误操作的准确时间，核对影响了哪些表、多少行数据。
- 把实例时间点恢复到一个新的临时实例，不直接覆盖生产库。
- 从临时实例导出受影响的表，与生产库逐表比对。
- 把正确数据回写生产库，核对订单金额和记录数。
- 确认无误后释放临时实例，并写复盘记录。
这次恢复大约花了3小时。复盘得出两条结论。第一，变更脚本要先在测试环境执行，并准备回滚方案。第二，恢复演练要定期做，不能等事故发生后才第一次尝试。之后团队把恢复演练放进月度运维计划，关键库的备份保留期也从7天延长到30天。
四、落地时注意什么
- 按RPO和RTO确定备份频率。核心库开启时间点恢复，只靠每天一次全量备份通常不够。
- 重要变更前手动备份，并把备份ID记入变更单。
- 定期导出到异地OSS，用生命周期规则控制存储成本，过期文件自动清理。
- 每季度至少做一次恢复演练，真正还原一遍，检查备份文件能否使用，步骤是否正确。
- 控制备份文件和访问权限。备份里通常有完整的用户数据，权限过宽造成的泄露风险不亚于丢数据。
备份配置本身不难，难的是长期坚持执行，并定期确认备份真的能用。策略、恢复流程和演练都落实下来，备份才算可靠。
