在原店旁打开恢复后的商店

介绍

PAPER & FORM 现在有四笔订单，但保存的备份止于 R-103。你需要在原店旁打开较早状态，查看订单明细，并证明恢复服务能够独立接收新测试单。

本实验独立开始。原始数据库与 backups/cutoff.dump 已经准备好，包含上一引导实验相同的三笔订单恢复点。需要基本终端操作能力；数据库和连接概念会再次说明。在 Workstation 执行命令，在 Original Shop 查看原服务，在 Restored Copy 操作测试目标。

你只能恢复和重置可丢弃的 shop_copy 数据库。保留源库、所提供的运行程序、备份和无关的 uploads/ 文件。所有数据均为虚构，不涉及支付或邮件操作。同一训练实例上的两个数据库演示逻辑导出与隔离，并不构成完整灾备、硬件冗余或 PITR。

仅向独立的空目标恢复

本步骤将打开截止订单的可用副本。先打开 Original Shop，再进入 Orders。这里有 R-101 至 R-104 四条记录。打开 R-103：Rae 的两件 Print pair 合计 $36.00。R-104 属于 Sol，在已保存恢复点之后添加，必须留在原店，但不能出现在恢复归档中。

打开 Restored Copy。锈红色横幅显示 shop_copy。首页可以访问，但 Orders 会说明独立数据库为空。仅首页有响应不能证明商店已恢复。

切换到 Workstation。pwd 显示当前目录：

pwd

/home/labex/project/shop-backup

./shopctl identity 读取真实连接。保存的服务设置指定数据库、主机、端口和账号：shop-source 以只读 d09_reader 连接 shop_source；shop-copy 以可写 d09_copy 连接 shop_copy。它们共用 127.0.0.1:5432 上的服务器，但副本角色不能连接源库：

./shopctl identity

pg_restore --list 读取自定义归档，不写入数据库。检查源库名和 orders、order_items 条目：

pg_restore --list backups/cutoff.dump

数据库保存结构化记录，订单的商品明细行关联到所属订单。自定义格式归档包含定义、数据、生成新编号的序列，以及维持关联的约束。应使用 pg_restore 恢复，而不是把二进制文件交给 psql。预置的导出和恢复客户端均为 PostgreSQL 14。

辅助工具的 empty 操作打印真实目标身份，并拒绝包含用户表或序列的数据库。非空目标可能保存着应当保留的工作。不要使用 --clean 或 --create：这些选项可能删除已有对象，或采用归档中的原始数据库名称。

以下命令中，&& 只有在空目标检查成功时才执行右侧命令。--dbname=service=shop-copy 显式选择独立目标。--no-owner --no-privileges 避免导入源账号和授权。--single-transaction 将导入视为一个整体，失败会回滚。--exit-on-error 在第一个数据库错误处停止。运行完整的带守卫命令：

./shopctl empty && pg_restore --dbname=service=shop-copy --no-owner --no-privileges --single-transaction --exit-on-error backups/cutoff.dump

应先显示目标身份，再显示 EMPTY: restore may proceed。成功的 pg_restore 通常没有输出。如果重试时出现 REFUSED: target is not empty，上一次导入可能已经成功；重置之前先查看副本。

records copy 读取真实关联的订单与明细：

./shopctl records copy

应看到 R-101、R-102 和 R-103，总额 $98.00，没有 R-104。在 Restored Copy 打开 Orders，再打开 R-103 和收据。必须看到两件 Print pair 与 $36.00。再次查看 Original Shop：Sol 的 R-104 仍在，原店全部订单合计 $124.00。

如果选错归档或需要重试失败恢复，只重置本课程的可丢弃目标。辅助工具会显示身份，并要求输入精确名称。下面是可选纠错命令，成功后无需例行执行：

./shopctl reset-copy shop_copy

它只丢弃 shop_copy。然后重新执行上面的带守卫恢复。绝不要重置或删除原店，也不要使用大范围数据库清理命令。检查只观察你的实际副本，不会代为恢复。

证明副本可写且不会改变原店

本步骤将测试对副本的真实写入。只读页面可能看起来正确，但恢复后的序列、关联或写入连接仍可能有问题。你将在独立副本中下一笔真实测试单，再比较两家店。留在 Restored Copy，打开 Collection 并滚动到表单。提交前阅读 Writing to: shop_copy · RESTORED COPY 和锈红色横幅。不要在 Original Shop 提交此测试。

准确填写：

选择 Place order ↗。生成的 R-901 应有一件商品，总额 $18.00。下载收据，确认其中写着 shop_copy。新订单使用恢复后数据库的序列和外键关联，并不是插入预先写好的页面。重复提交同一编号会返回 Already recorded，不会产生第二笔订单。

在同一个副本中打开 Orders。应包含 R-101、R-102、R-103 和 R-901，没有 R-104。切换到 Original Shop，打开 Orders。原店仍有 R-101 至 R-104，没有 R-901。如果两个应用都写同一个数据库，仅有不同横幅并不足以证明隔离。

切换到 Workstation。显示两边连接身份，再读取两个真实数据集：

./shopctl identity

./shopctl records copy

./shopctl records source

副本合计 $116.00，源库仍为 $124.00。要求每条数据永远相同是不对的：R-104 只属于较晚的源库，R-901 只属于恢复副本。应比较共有的截止记录，以及两边各自允许的差异。

原店表单会拒绝 R-901，不会写入。如果选错标签，阅读 Check the destination 消息，切换到 Restored Copy 后再提交。未知编号同样会被拒绝，修正表单编号后重试即可。如果已有 R-901 的姓名、商品或数量填错，./shopctl correct copy R-901 会显示实际目标，仅把该测试单改为 Copy test / Print pair / 1。副本其他订单与源库全部数据保持不变。如果只是可丢弃副本需要重新开始，使用步骤 1 中精确的 reset-copy shop_copy 恢复方法，重新导入，再添加一次副本测试单。

最终检查会读取两边的现场数据库和网站，保留无关上传文件，并在另一可丢弃数据库中测试归档。它不会创建测试单或修复运行中的副本。现在，你的备份拥有完整数据、明确截止点和独立可写恢复的证据。

总结

你识别了真实源库与目标库，对空目标设置守卫，以事务方式恢复自定义归档，并读取完整订单明细。副本专属的新订单证明恢复服务独立且可写，原店保留了后续订单。本练习验证的是逻辑恢复演练，不是完整的生产恢复策略。