很多站长把“每天做一次全量备份”当成香港站群服务器的通用答案，但备份频率并不是由服务器名称或网站数量决定的。真正需要先确定的是：网站最多能承受多长时间的数据丢失，即 RPO；业务最多能接受多长时间无法访问，即 RTO。如果数据库每小时都有订单或内容写入，而备份每天才执行一次，那么备份任务即使次次成功，也无法满足业务恢复要求。

更可执行的规划方式是把站群拆成网站文件、数据库、运行配置和可重建数据四类，分别记录变化速度，再按业务重要程度制定周期。高频变化的数据库通常需要比代码文件更密集的备份；文件备份必须与数据库恢复点尽量匹配；备份完成后还要通过实际恢复验证，否则只能证明“文件被复制过”，不能证明“网站能够恢复”。

先用RPO和RTO确定备份目标

RPO决定多久备份一次

RPO表示故障发生后，业务允许丢失的最近一段数据时间。例如，RPO为1小时，意味着恢复后最多接受约1小时以内的数据缺失。备份间隔应不大于RPO，实际执行时还要为传输延迟、任务排队和校验预留余量，因此不建议把备份间隔刚好设成目标上限。

可以先为香港站群服务器上的网站建立如下分类：

上表中的周期是起步方案，不是固定标准。判断是否合适，应查看最近一段时间内的实际更新记录：如果两个备份之间经常有大量有效数据写入，当前周期就可能过长；如果备份任务占用高峰时段、但站点几乎没有变化，则可以通过错峰、增量或按变更触发来降低影响。

RTO决定备份形式和恢复演练深度

RTO是从开始恢复到网站能够正常提供服务的时间。RTO较短时，仅保留一个很大的压缩包通常不够，因为解压、数据库导入、权限修复和配置检查都可能成为耗时环节。

需要同时记录以下指标：

• 备份完成时间：从任务启动到备份和校验结束的时长。
• 恢复耗时：从选定恢复点到应用通过检查的时长。
• 恢复点时间：备份实际包含的数据截止时间，而不是文件的创建时间。
• 备份体积与增量体积：用于判断存储增长和传输压力。
• 验证延迟：备份完成后，多久能够确认该备份可读、可导入、可启动。
• 恢复成功率：连续多次演练中，能够按文档完成恢复的次数比例。

备份时长短，不代表恢复时长短；文件校验通过，也不代表数据库能正常导入。RTO必须通过恢复演练测量，不能只凭备份任务日志估算。

先划清备份范围，再安排周期

网站文件不应只备份首页目录

每个站点至少要登记以下内容：

• 网站代码和主题文件；
• 用户上传、附件、图片和媒体文件；
• 网站配置文件、环境变量说明和定时任务；
• 依赖版本文件、构建清单或部署记录；
• SSL证书及其对应的私钥，且要单独限制访问权限；
• 站点与数据库名称、账号权限、文件路径之间的对应关系。

缓存、临时文件、运行日志和可重新生成的依赖目录通常不必作为主要恢复数据，但不能直接忽略。应先确认它们是否包含业务文件、上传内容或恢复所需的版本信息。对于可以重新安装的依赖，至少保留版本锁定文件和安装说明，否则恢复时可能出现代码与依赖版本不匹配。

代码文件变化通常集中在发布、主题调整和配置修改时，因此适合采用“发布前备份加日常备份”的方式。用户上传文件和内容附件变化更频繁，不能因为代码没有更新就降低其备份频率。

数据库要单独规划

数据库备份范围至少包括：

• 业务表和索引；
• 视图、触发器、存储过程和事件；
• 字符集、排序规则等影响读取结果的设置；
• 数据库账号、授权关系和连接配置的恢复记录；
• 使用事务日志、归档日志或增量链时所需的连续日志。

逻辑备份便于查看和迁移，适合日常小规模恢复；物理备份或快照通常更适合缩短大数据库恢复时间，但必须确认快照的一致性、保留方式和独立存储情况。只保留数据库文件目录的复制品，不能自动证明数据库处于可恢复状态。

数据库账号密码不要直接写进命令行或脚本明文中。备份配置文件应限制权限，并与备份文件分开管理。若恢复时缺少密钥、账号或环境变量，即使数据库导入成功，网站也可能无法连接或无法解密原有数据。

站群不能只做一个总压缩包

多个网站共用一台香港站群服务器时，建议按站点建立清单和备份目录，而不是只生成一个无法区分内容的大文件。清单应包含：

这样可以避免一个站点恢复时误覆盖其他站点，也便于先恢复高优先级业务。站群任务还应错开执行时间，避免多个站点同时压缩、读取和传输造成备份窗口重叠。

让文件和数据库保持可用的一致性

文件备份与数据库备份要尽量对应

网站文件和数据库分开备份，但恢复时必须能够组成一个有效版本。例如，代码已经更新到新版本，数据库却仍是旧结构，可能出现字段不存在；数据库已经写入新内容，附件文件却没有同步备份，可能出现记录存在但文件丢失。

以下情况更容易产生不一致：

• 备份文件时网站仍在持续写入上传目录；
• 数据库导出过程中表结构发生变更；
• 先备份数据库，长时间后才备份附件；
• 只保留最新文件，却删除了与其匹配的数据库恢复点；
• 使用快照时没有暂停写入或确认数据库支持一致性快照。

较稳妥的做法是为每个恢复点记录一个时间标记，并让文件备份、数据库备份和配置备份都关联到该标记。发布或大规模导入前，可以短暂进入维护状态，先完成数据库和文件备份，再执行变更。

MySQL或MariaDB逻辑备份示例

下面的命令适用于已经确认使用MySQL或MariaDB、并且数据库主要采用InnoDB表的Linux环境。执行前应确认备份目录已挂载、空间充足，数据库账号具备读取表结构、触发器、事件和存储过程所需的权限。不要把真实密码直接放在命令行中。

command -v mysqldump
mysqldump --version

mysqldump --defaults-extra-file=/root/.my-backup.cnf \
  --single-transaction \
  --routines \
  --events \
  --triggers \
  --hex-blob \
  --databases site_db \
  > /backup/stage/site_db-$(date +%F-%H%M).sql

--single-transaction主要用于降低事务型表导出时对正常写入的影响，但它不能保证非事务型表在持续写入时的一致性。若数据库包含非事务型表，或者备份期间恰好发生结构变更，应根据业务情况安排维护窗口，或使用数据库自身的物理备份能力。

mysqldump执行返回成功，也不代表恢复一定成功。导出完成后应检查文件是否为空、压缩或校验是否正常，并在隔离环境中导入测试。不同数据库版本之间可能存在字符集、语法或权限差异，恢复环境应尽量与生产环境保持兼容。若实际使用的是其他数据库引擎，不要直接套用上述命令，应使用对应版本的备份工具并验证导出格式。

网站文件备份示例

以下示例适用于常见Linux环境中使用rsync复制网站目录的场景，不带删除参数，不会主动删除目标目录已有文件：

rsync -aH --numeric-ids \
  /var/www/site-example/ \
  /backup/stage/site-example/

执行前要核对源目录，避免把测试目录、挂载点或其他站点误当成生产目录。-aH用于尽量保留权限、时间和硬链接关系，但是否能保留所有者取决于执行账号和目标文件系统权限。若网站正在频繁写入，复制结果可能处于中间状态，应该在维护窗口执行，或先将上传写入切换到可控状态。

备份目录不应与生产目录共用同一个故障边界。保留一份同机副本有利于快速恢复，但如果存储损坏、误删或权限被一并修改，同机副本可能同时失效。至少要保留一份与生产环境相互独立、权限隔离的副本，并定期抽样恢复。

按变化速度制定一套可落地的周期

可以先采用“分层周期”，再根据备份窗口和恢复结果调整：

对于普通站点，可以把每日备份保留一到两周、每周备份保留一个月左右，再根据业务和合规要求增加月度恢复点。对于交易或重要内容站点，保留周期应覆盖退款、对账、内容追溯和误删发现所需的时间。保留策略不能只看备份数量，还要保证增量链对应的基础全量备份没有被提前删除。

删除旧备份前，应先确认：

1. 新的全量备份已经完成并通过恢复验证；
2. 依赖该全量备份的增量或日志链已经不再承担恢复任务；
3. 保留周期内仍存在可用恢复点；
4. 删除动作不会影响其他站点；
5. 删除记录、执行人和保留依据可以追溯。

用恢复演练证明备份有效

演练前的准备条件

恢复演练不应直接覆盖生产目录或生产数据库。应准备隔离的恢复环境，并提前确认：

• 具备一份已通过文件校验的备份；
• 知道对应的数据库版本和运行环境；
• 具备配置、账号权限和密钥说明；
• 已准备独立的测试域名或本地解析方式；
• 已暂停恢复环境中的定时任务、队列和外部通知；
• 已明确演练结束后的清理范围。

如果恢复环境缺少密钥、运行版本或数据库账号，演练结果应记录为“备份数据可读但恢复条件不完整”，不能简单标记为成功。

演练步骤

1. 选择恢复点

记录备份生成时间、数据截止时间、文件清单和数据库备份类型。优先选择最近一次完整备份，也可以抽查较早的长期保留点。

1. 先验证备份文件

对压缩包执行目录读取，对校验清单执行校验。校验只能说明文件在传输或保存过程中没有明显变化，不能替代应用恢复测试。

   tar -tzf /backup/stage/site-example.tar.gz > /tmp/site-example.list
   sha256sum -c /backup/stage/SHA256SUMS

1. 恢复网站文件和配置

恢复到隔离目录，核对文件数量、权限、属主和软链接。不要在未确认源目录的情况下使用带有删除目标文件功能的同步命令，以免误删恢复环境中的其他数据。

1. 恢复数据库

在隔离数据库实例中导入备份，检查表数量、关键表记录数、字符集、触发器和定时事件。导入前确认目标数据库不是生产数据库，避免测试数据覆盖真实业务。

1. 启动应用并执行功能检查

至少检查首页、后台登录、内容读取、搜索、文件下载、文件上传和一项数据库写入功能。涉及邮件、支付或外部回调的功能应使用测试配置，避免演练触发真实业务动作。

1. 记录恢复指标

记录从开始恢复到应用可用的时间、恢复后的数据截止时间、失败步骤和人工操作数量。若需要临时手工修复权限或配置，也应写入恢复文档。

1. 清理和复盘

演练结束后清理测试数据库、临时密钥和测试文件，但不要删除生产备份。对照RPO和RTO检查差距，并把缺失的步骤补进恢复手册。

高优先级、持续写入的网站可以按月抽查恢复；更新较少的网站至少按季度演练一次，并在数据库结构变更、运行环境升级或大规模迁移后增加一次演练。若连续多次只验证文件、不验证数据库导入和应用启动，演练频率再高也不能证明完整恢复能力。

看到不同结果时如何调整方案

备份经常超出窗口

先查看是数据读取、压缩、传输还是校验阶段耗时增加。若只有大文件目录增长，应考虑按目录和变化率拆分；若数据库导出耗时增加，应评估逻辑备份是否仍适合当前规模；若多个站点同时执行，应错开任务，而不是简单提高并发。

备份任务影响网站响应时，可以调整到低峰时段、采用增量方式或降低同时运行的站点数量。但不能为了缩短备份窗口而直接跳过数据库一致性检查。

备份成功但恢复失败

常见原因包括备份文件不完整、数据库版本不兼容、账号权限缺失、配置和密钥未保存、文件与数据库不属于同一恢复点。此时应把该备份标记为不可用于恢复，保留失败日志，并检查上一份通过验证的恢复点，而不是反复使用同一份有问题的文件。

恢复时间超过RTO

先测量数据库导入、文件复制、权限修复和应用启动各阶段耗时。若数据库导入占主要时间，可以评估物理备份或更细粒度的增量方案；若文件恢复耗时较长，可以按站点优先级恢复，先恢复代码和关键数据，再补齐低优先级附件。任何优化都必须通过下一次完整演练确认，不能只根据理论速度调整目标。

数据丢失超过RPO

检查最近一个“可恢复点”而不是最近一个“已生成文件”的时间。如果中间的备份虽然生成但从未校验，实际RPO应按上一个通过验证的恢复点计算。之后缩短数据库备份间隔、增加日志或增量保存，并确认备份任务没有因权限、空间或挂载异常而静默失败。

用复测结果决定下一轮周期

香港站群服务器的备份周期不应一次设定后长期不变。每次站点数量、数据库写入量、上传目录大小、代码版本或恢复环境发生明显变化时，都应重新测量备份窗口和恢复耗时。

可以使用以下判断方法：

• 最近备份间隔大于业务允许的数据损失时间：缩短周期或增加增量、日志备份。
• 备份完成但恢复点无法通过导入和应用检查：先修复一致性和验证流程，再讨论频率。
• 备份任务与业务高峰重叠：错峰或分批执行，观察对站点响应和任务成功率的影响。
• 恢复耗时超过RTO：优先定位最慢阶段，并通过演练验证新的备份形式。
• 保留点过多导致管理混乱：按恢复链和业务用途清理，不能只按文件数量删除。
• 站群中不同网站变化差异明显：拆分策略，让高频写入网站使用更密集周期，低频站点采用按变更和每日周期。

最终应以“最近可验证恢复点、实际数据损失窗口、完整恢复耗时”作为决策依据。只有当备份范围覆盖网站数据和数据库，恢复点之间保持一致，并且恢复演练能够按记录步骤完成，备份周期才真正满足业务需要。