日本台湾云服务器云主机的备份容灾与异地恢复实操案例

1.

概述与体系设计

- 目标：实现日本（主站）与台湾（异地）云主机的RPO≤5分钟、RTO≤30分钟。
- 组件：文件备份（rsync/Restic）、数据库备份（binlog/Percona XtraBackup 或 MySQL 主从）、对象存储（S3兼容）做为长期备份、DNS/负载均衡做故障切换。

2.

准备与前置条件

- 两端要互通SSH（公钥认证）、开通对象存储跨区权限、在两侧准备备份磁盘或Bucket。
- 工具：rsync, restic, mariadb/mysql, xtrabackup, socat/keepalived，监控（Prometheus/Alertmanager）。

3.

文件级增量备份（rsync + cron）

- 在日本主站创建SSH密钥并把公钥放到台湾备份账号的~/.ssh/authorized_keys。
- 命令示例（单向同步到台湾备份机）：rsync -azP --delete -e "ssh -i /root/.ssh/id_rsa" /var/www/ backup@TAIWAN_IP:/data/backup/www/。
- 定时任务（crontab -e）：*/15 * * * * rsync ... >> /var/log/rsync_www.log 2>&1 （每15分钟增量，满足短RPO）。

4.

使用Restic到对象存储做版本化备份

- 在日本主站初始化仓库：export RESTIC_REPOSITORY="s3:s3.example.com/japan-backup"; export AWS_ACCESS_KEY_ID=...; restic init。
- 备份命令：restic backup /var/www --tag prod --host japan-web --exclude /var/www/cache。
- 恢复命令：restic restore latest --target /restore/path。支持加密、去重，适合长期保留。

5.

数据库热备：使用mysqldump + binlog

- 全量：mysqldump --single-transaction --flush-logs --master-data=2 -u root -p --databases appdb > /backup/appdb.sql。
- 将生成的log位置写入备份台账，scp appdb.sql 到台湾备份机并导入：mysql -u root -p < appdb.sql。
- 启用二进制日志，定期传输binlog：scp /var/lib/mysql/mysql-bin.* backup@TAIWAN:/backup/binlog/ （或用rsync增量传输），用于恢复到指定时间点。

6.

更稳健的热备：Percona XtraBackup（物理热备）

- 在日本节点安装xtrabackup：xtrabackup --backup --target-dir=/backup/xtrabackup/$(date +%F-%H%M) --user=xtrabackup --password=PW。
- 准备：xtrabackup --prepare --target-dir=...。拷贝到台湾并直接解压到MySQL数据目录，保证文件权限并启动MariaDB。
- 优势：无需停库重建，恢复速度快，适用于大库。

7.

主从实时复制（建议用于零宕机切换）

- 在主库创建复制账号：CREATE USER 'repl'@'%' IDENTIFIED BY 'pwd'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES; FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;（记录File和Position），导出数据后UNLOCK TABLES。
- 在台湾从库执行：CHANGE MASTER TO MASTER_HOST='JAPAN_IP', MASTER_USER='repl', MASTER_PASSWORD='pwd', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=123; START SLAVE; SHOW SLAVE STATUS\G。
- 切换步骤（主站故障）：在台湾执行 STOP SLAVE; RESET SLAVE ALL; 并把应用连到台湾数据库，或把台湾提升为主库（设置写权限）。

8.

快照与块存储复制

- 如果使用云硬盘（如Cinder/EBS类），在日本定时做快照并将快照复制到台湾区（多数云厂商支持跨区复制）。
- 操作步骤：创建快照 -> 等待完成 -> 复制快照到台湾 -> 在台湾由快照创建磁盘并挂载 -> 挂载后检查文件系统并启动服务。适合整机恢复。

9.

故障切换（Failover）与DNS策略

- 使用低TTL DNS（如60秒），并配置健康检查的DNS提供商（或Cloudflare/Route53）。发生主站不可达时，自动将流量导向台湾VIP或负载均衡器。
- 可采用Keepalived + VRRP在两地或同区内做虚拟IP漂移（跨公网复杂），更常见是修改DNS或使用云厂商的全局负载均衡（GLB）。

10.

演练与验证步骤

- 定期演练：1) 在维护窗口切断日本应用网络；2) 在台湾提升从库为主（停止从库，确认可写）；3) 将应用指向台湾DB并检查事务一致性；4) 验证静态文件、用户登录、支付流程等关键路径。
- 检查点：数据是否丢失（比对binlog位置）、服务是否可用、监控告警是否触发。

11.

自动化脚本与检查清单

- 建议编写脚本自动化：备份触发脚本、快照复制脚本、恢复脚本（restic restore、xtrabackup restore、rsync恢复）。
- 清单示例：SSH连通、备份完整性校验（restic check / md5sum 对比）、从库延迟监控、DNS TTL 设置、紧急联系人清单。

12.

问：如何最小化RPO与RTO？

- 答：将文件同步频率降到几分钟（rsync每1-5分钟或使用实时文件同步工具lsyncd），数据库采用主从实时复制并启用binlog；DNS设置低TTL并使用自动健康检查的全局负载均衡，结合自动化故障切换脚本，能把RPO降至分钟级，RTO降至十几分钟。

13.

问：演练中最常见的错误有哪些？

- 答：常见错误包括：未验证备份可恢复性（只是备份但不能恢复）、复制账号权限或网络策略被防火墙阻断、DNS缓存未清导致切换延迟、未同步时钟/时区导致日志位置不一致。演练时逐项排查并记录复盘。

14.

问：成本与安全如何权衡？

- 答：跨区实时复制与低TTL全局负载均衡会增加带宽与DNS费用；物理快照长期保留占用存储；建议分层：核心数据库采用实时复制+短期快照，静态资源用对象存储跨区复制，长期备份使用冷存储并加密（restic自带加密），同时使用最小权限原则与加密传输（SSH、SSL）。

来源：日本台湾云服务器云主机的备份容灾与异地恢复实操案例