选择可信备份并恢复站点

介绍

一家小商店用订单服务关联客户、商品和数量。预设事件发生后，两个订单不见了。你的任务是恢复所需数据，同时保留与数据库无关的公开商品目录。环境中的人物和记录都是合成数据，没有恶意软件。

备份是用于恢复的副本。归档将多个文件打包，校验和则概括文件的字节内容。你将理解为什么只有来自可信来源的参考值才能让校验和发挥作用，然后通过暂存区恢复真实的 SQLite 数据库。这是有限范围的恢复练习，并非完整的事件响应流程。

你只需会输入终端命令和切换标签页。Workstation 和 App Server 是同一训练主机上、起始目录不同的独立终端会话，不是两台机器。浏览器页面在 Order Service 中。

保留受损的服务数据

在这一步，你将了解缺失的业务数据，并在修改服务前保留回滚副本。

打开 Order Service。正常情况下，每行会将订单编号与客户、状态、商品及数量关联。所需恢复点包含以下三个订单：

现在只有 4101。点击 Public catalog：其中仍应列出马克杯、笔记本和手提袋。这份上传文件不属于数据库，恢复后也必须保留。随后返回订单页面。

API 是供程序使用的服务接口。在 Workstation 中，curl 请求 API；-f 将服务器错误视为失败，-s 隐藏进度，-S 则仍显示错误。这里的 127.0.0.1 表示当前训练主机，8080 是服务端口。

curl -fsS http://127.0.0.1:8080/api/orders

结果是 JSON 数组，即用方括号包围的行列表。只有 Mina 的记录。请求成功不代表业务数据完整。

切换到 App Server。pwd 打印当前目录：

pwd

应显示 /srv/order-service。SQLite 将应用表存储在 orders.db 中。这个预配置服务没有写入程序，每次请求都重新打开数据库，因此这里可以安全复制。繁忙的生产数据库则需要保证应用一致性的备份流程。

cp 的参数依次是源和目标。把当前数据库保留在应用目录之外，这样错误恢复后还可以撤回：

cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db

通常没有输出就表示复制完成。恢复后不要重复此命令，否则恢复后的数据库会覆盖回滚副本。你已保留受损状态，服务本身仍待恢复。

选择可信的恢复归档

在这一步，你将排除被修改的备份，并把适合且通过验证的归档放入暂存目录。

切换到 Workstation。cd 切换目录，ls 列出目录内容。绝对路径以 / 开头，不受当前目录影响。

cd /home/labex/project/recovery/backups

ls

这里有三个 .tar.gz 归档：tar 将文件打包，gzip 负责压缩。文件名描述恢复时间；最新的未必安全，也未必适合。

cat 打印文本文件。读取由备份保管方单独提供的恢复点说明：

cat /opt/backup-custodian/recovery-points.txt

0800 归档早于订单 4102 和 4103。0900 归档包含所需恢复点。1000 候选更晚，但仍需检查完整性。

完整性表示字节相对于参考值没有变化。SHA-256 生成用于比较的摘要。保管方的清单由 root 拥有，位于普通用户可编辑的恢复目录之外。场景假定该清单通过独立受保护的渠道送达；本实验不教授数字签名或密钥分发。管理员访问可以越过本地所有权限制，因此不要把这台教学主机当作无法篡改的信任锚。

sha256sum -c 读取文件名与摘要配对，并比较当前目录中的对应文件。使用独立清单：

sha256sum -c /opt/backup-custodian/SHA256SUMS

0800 和 0900 应报告 OK，1000 应报告 FAILED。非零退出和警告是预期现象：至少一个归档被修改了。不要提取该候选。

旁边的清单可以与备份一起被修改。比较其结果：

sha256sum -c SHA256SUMS

三个都报告 OK。能修改归档的人也能替换旁边的校验和。不可信摘要的匹配无法证明真实性。较早的 0800 归档未变，但缺少所需记录。选择 0900，因为它既未变又满足要求。

暂存目录让你在接触在线服务前检查恢复数据。mkdir -p 创建目录，目录已存在时也可使用：

mkdir -p /home/labex/project/recovery/stage

把通过验证的候选复制到这里：

cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz

如果源路径拼错，cp 会报告找不到文件；用 ls 查看后重试。检查点验证实际暂存归档的字节，而不是你写下的验证声明。

检查暂存数据库

在这一步，你将检查归档成员、提取唯一的预期文件，并在不修改的情况下读取暂存数据库。

在 Workstation 中进入暂存目录：

cd /home/labex/project/recovery/stage

tar -tvzf 列出 gzip 压缩归档：t 表示列表，v 包含类型和权限，z 表示 gzip，f 指定归档。列出内容不会提取文件。

tar -tvzf orders-0900.tar.gz

唯一成员应为 orders.db，权限字段以 - 开头，表示普通文件。如果看到绝对路径、.. 路径部分、链接或意外文件，请停止操作。这里检查成员名有用，因为这个可信训练归档只有一个普通文件；这并不是适用于任意归档的完整安全提取策略。不要运行可疑备份中的程序。

提取时用 x 代替 t，并去掉详细输出选项 v。末尾的 orders.db 将提取范围限制为该成员，--no-same-owner 则保留你自己的所有权：

tar -xzf orders-0900.tar.gz --no-same-owner orders.db

SQLite 将有关联的表存储在一个文件中。预配置工具 db-view 以只读方式打开数据库，检查内部一致性和关系，再打印关联后的业务行。此次恢复无需编写 SQL 或编辑数据库。给工具提供暂存文件路径：

/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db

应看到 Integrity: ok、Relationships: ok，随后是三个所需订单。有效的数据库也可能属于错误恢复点，因此还要与第 1 步比较客户、状态和数量。

路径错误时，工具会报错，而不会创建空数据库。用 pwd 和 ls 检查后重试。若数据不符，返回独立清单，选对归档后重新提取。在线站点仍然受损：仅完成暂存并没有恢复应用。

恢复并测试在线服务

在这一步，你将只替换指定数据库，通过真实请求确认恢复，并保留公开上传文件。

切换到 App Server。回滚副本保存在此目录之外，暂存数据库也已检查通过。只把这个数据库复制到应用指定的数据路径：

cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db

源和目标是不同文件。不要把整个暂存目录覆盖到 /srv/order-service：其中有必须保留的无关上传文件。这个预配置只读应用在每次请求后关闭数据库，因此无需重启守护进程。其他应用可能需要遵循其维护或重启流程。

查询应用，不要仅凭备份文件或 restored 文本文件存在来判断：

curl -fsS http://127.0.0.1:8080/api/orders

应有 4101、4102、4103 三行，客户正确，状态为 packed，数量依次为 1、2、3。打开 Order Service 并刷新，表中应显示相同记录。

也检查无关的公开上传文件：

curl -fsS http://127.0.0.1:8080/uploads/catalog.txt

Public catalog: mugs, notebooks, tote bags

在浏览器中点击 Public catalog，确认内容相同。恢复意味着所需业务数据回来，而且无关的正常功能仍可用。

若服务报告 Database unavailable，请重新检查暂存数据库，再用正确绝对路径执行单文件复制。调查错误时，如需回到原始受损状态，可以使用保留的副本：

cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db

最后这个命令会有意撤销恢复。如果使用了它，完成实验前请再次把通过验证的暂存数据库复制到在线路径。保留回滚文件以供后续检查。

总结

你保留了回滚副本，将备份字节与独立可信清单比较，选择了合适的恢复点，并检查暂存 SQLite 数据库。随后恢复真实服务，验证恢复的关系和无关上传文件。最新、未变和适合是不同属性；安全恢复需要正确结合这些条件。