中小型企业的灾难恢复规划：保护您的业务免受不可避免的影响

**60% 的丢失数据的小型企业会在 6 个月内关闭。**然而，只有 23% 的中小企业拥有记录在案且经过测试的灾难恢复计划。那些在灾难中幸存下来的企业并不是那些避免了灾难的企业，而是那些为灾难做好准备的企业。

本指南为中小型企业提供了实用的灾难恢复框架，涵盖从基本备份策略到多区域故障转移架构的所有内容。

要点

• 在选择灾难恢复策略之前定义 RPO 和 RTO --- 这些数字决定您的架构和预算
• 3-2-1 备份规则（3 个副本、2 个介质类型、1 个异地）是最低可接受的备份策略
• 未经测试的备份不是备份 --- 安排季度恢复演习
• 灾难恢复成本与 RTO 要求呈线性关系：24 小时 RTO 成本是 1 小时 RTO 的 10%

---

定义恢复目标

RPO（恢复点目标）

按时间测量的最大可接受数据丢失。如果您的 RPO 为 1 小时，则您最多可以容忍丢失 1 小时的数据。

RTO（恢复时间目标）

可接受的最长停机时间。如果您的 RTO 为 4 小时，那么您的企业可以在离线状态下生存长达 4 小时。

将目标与业务影响相匹配

---

备份策略

3-2-1 规则

• 每个关键数据集的 3 副本
• 2不同的存储类型（例如本地磁盘+云）
• 1 副本位于不同的地理位置

自动 PostgreSQL 备份

#!/bin/bash
# /opt/scripts/backup-database.sh
# Run via cron: 0 */6 * * * /opt/scripts/backup-database.sh

set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/opt/backups/database"
S3_BUCKET="s3://ecosire-backups/database"
DB_NAME="ecosire"
DB_USER="app"
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Create backup with compression
echo "Starting backup at $(date)"
pg_dump -h localhost -U "$DB_USER" -Fc "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Verify backup integrity
pg_restore --list "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" > /dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "ERROR: Backup verification failed"
  exit 1
fi

BACKUP_SIZE=$(du -h "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" | cut -f1)
echo "Backup created: ${BACKUP_SIZE}"

# Upload to S3 with server-side encryption
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "$S3_BUCKET/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256

# Upload to secondary region
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "s3://ecosire-backups-dr/database/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256 \
  --region eu-west-1

# Clean up local backups older than retention period
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete

echo "Backup complete at $(date)"

应用程序文件备份

#!/bin/bash
# Backup application files, uploads, and configuration

TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Backup Odoo filestore
tar czf "/opt/backups/files/filestore_${TIMESTAMP}.tar.gz" /opt/odoo/data/filestore/

# Backup uploaded documents
tar czf "/opt/backups/files/uploads_${TIMESTAMP}.tar.gz" /opt/app/uploads/

# Backup configuration (secrets excluded)
tar czf "/opt/backups/config/config_${TIMESTAMP}.tar.gz" \
  --exclude='*.env*' \
  --exclude='*.pem' \
  /opt/app/infrastructure/

# Upload all to S3
aws s3 sync /opt/backups/ s3://ecosire-backups/ --sse AES256

---

故障转移架构

第 1 层：冷备用（RTO：4-24 小时）

• 备份存储在云存储中
• 恢复涉及配置新的基础设施和从备份恢复
• 最便宜的选择：只需支付存储费用
• 适用于非关键内部应用

第 2 层：热待机（RTO：1-4 小时）

• 备用服务器正在运行但未接收流量
• 数据库复制使备用数据保持最新
• 恢复涉及提升待机和更新 DNS
• 成本适中：以较小的规模支付备用服务器的费用

Primary (active) ----replication----> Standby (warm)
                                         |
                   On failure: promote + DNS update

第 3 层：热备（RTO：<30 分钟）

• 主动-被动或主动-主动配置
• 通过健康检查自动故障转移
• 具有同步复制功能的数据库
• 成本更高：支付完全重复的基础设施费用

                     Health Check
                         |
Load Balancer ------> Primary (active)
       |
       +-------------> Secondary (hot standby, auto-promote)

第 4 层：多区域主动-主动（RTO：<5 分钟）

• 多个区域同时提供流量
• 按地理位置划分的全球负载均衡器路线
• 多主写入的数据库冲突解决
• 最高的成本和复杂性

成本比较

---

恢复测试

季度恢复演习

每个季度执行一次完整恢复测试：

1. 选择最近 30 天内的随机备份
2. 提供恢复基础设施（与生产分开）
3. 从备份恢复数据库
4. 从备份中恢复应用程序文件
5. 从 Git 部署应用程序代码
6. 针对恢复的环境运行冒烟测试
7. 根据 RTO 目标衡量实际恢复时间
8. 记录调查结果并更新灾难恢复计划

恢复演习清单

• 数据库从备份成功恢复
• 应用程序启动并处理请求
• 用户身份验证有效
• 关键业务流程完成（下订单、生成发票）
• 集成端点响应（支付网关、电子邮件）
• 实际恢复时间满足 RTO 目标
• 团队无需参考文档即可了解自己的角色
• 沟通渠道有效（您如何通知利益相关者？）

---

事件响应手册

严重级别

SEV1 响应步骤

1. 在 15 分钟内确认事件
2. 评估范围：受影响的内容、受影响的用户数量
3. 与利益相关者沟通：状态页面更新、客户通知
4. 使用最快的可用选项（回滚、故障转移、扩展）来缓解
5. 解决根本原因
6. 事后分析 48 小时内：时间表、根本原因、行动项目

---

常见问题

我们应该为灾难恢复预算多少？

合理的灾难恢复预算是生产基础设施成本的 10-25%。对于每月在基础设施上支出 500 美元的公司，每月为灾难恢复预算 50-125 美元。这包括云备份存储、热备用服务器和监控。投资回报率计算：如果您的企业因停机每小时损失 5,000 美元，并且 DR 将潜在的 24 小时停机减少到 4 小时，则 DR 投资可节省 100,000 美元。

如果我们使用托管云提供商，我们是否需要灾难恢复？

是的。云提供商可以防止硬件故障和数据中心中断，但不能防止应用程序错误、意外删除、勒索软件或帐户泄露。您的灾难恢复计划必须涵盖云提供商未涵盖的场景：数据损坏、资源删除、安全漏洞和供应商锁定风险。

我们如何处理 Odoo ERP 系统的灾难恢复？

Odoo DR 需要三个组件：(1) PostgreSQL 数据库备份（自动、加密、异地）、(2) 文件存储备份（上传的附件、报告模板）、(3) 自定义模块代码（在 Git 中）。恢复涉及：配置服务器、安装 Odoo、恢复数据库、恢复文件存储、部署自定义模块。 ECOSIRE 提供托管 Odoo DR 以及自动备份和经过测试的恢复程序。

最常见的灾难恢复故障是什么？

未经测试的备份。超过 30% 的备份恢复因损坏、备份不完整、依赖项缺失或密码更改而失败。第二个最常见的故障是过时的文档——灾难恢复计划引用的服务器、凭据或过程不再存在。季度测试可以解决这两个问题。

---

接下来会发生什么

灾难恢复是运营弹性的支柱之一。将其与监控和警报 相结合以实现早期检测，将其与零停机部署 相结合以实现安全更改，并与安全强化 相结合以实现威胁预防。

联系 ECOSIRE 了解灾难恢复规划和实施，或探索我们的 DevOps 指南 了解完整的基础设施路线图。

---

由 ECOSIRE 出版——帮助企业为不可避免的事情做好准备。