备份与恢复
你的应用已在生产环境运行。立即备份。rdc 会把整个仓库、应用本身、它的数据库、文件和配置，一并复制到第二台机器上；第一台机器消失后，再从那里把它取回来。
本教程不只是讲讲而已，而是在两台真实机器上实际操作一遍,最后把数据读出来确认。
三个步骤
- 将仓库复制到你自己掌控的机器上。
- 把这份副本恢复成一个独立的仓库。
- 通过读回数据来验证结果。
第一步：必须留存下来的数据
rdc term connect my-app --command 'cat orders.txt'先从正在运行的 repository 中读取数据。一个文件里的一条记录，这样最后的证明才是你能亲眼看到的东西，而不是只能凭信任接受的东西。
下面的每一步都要用这一行数据来检验。第 7 步再来核对一次。
第二步：把仓库复制到第二台机器
rdc repo push my-app --to machine-12把 repository 复制到第二台机器上。第一次推送会传输整个加密镜像，在这批机器上大约两吉字节，用时三十到四十秒，之后每次推送只发送发生变化的块。到达目标端的是一个备份产物，而不是第二个正在运行的 repository。
增量传输教程现场演示了这个过程中增量传输的那一半。
一个产物（artifact）还不是正在运行的仓库,这正是第 5 步存在的意义。
第三步：备份机器已经拿到数据
rdc repo list --machine machine-12查看备份机器上保存了什么。副本以从你的 config 中解析出的名字出现。带有原始标识符的第二行，是保留下来的增量基准，正是它让下一次推送到这台机器变成增量传输。
第四步：灾难发生
rdc repo down my-app --unmount让主机器下线：停止它的服务，卸载加密卷。从这里开始，一切都在另一台机器上的副本上进行。
第五步：把产物变回一个仓库
rdc backup restore my-app@machine-12 --as my-app-restored --machine machine-12 --yesrestore 是把推送过去的副本变成 repository 的命令。用 --as 命名，用 --machine 指定位置，用 --yes 确认。以新名字恢复不会覆盖任何东西，这也是为什么可以放心在正在使用的机器上练习。
在真正需要之前,请对每台机器都先做一次这个演练。一台从未完整走过这个来回流程的机器,无论它的推送看起来多顺利,都不能算是有备份;而用新名字恢复,即使在正在承载流量的机器上也是安全的。
第六步：挂载它
rdc repo up my-app-restored --no-start挂载恢复出来的 repository。容器故意保持关闭状态：这里要证明的是数据，而不是应用。
第七步：数据留存了下来
rdc term connect my-app-restored --command 'cat orders.txt'和第一步一样的命令，这次针对的是两条命令之前还不存在的 repository 运行。这条记录逐字节完整地回来了，而且是从一台从来都不是原始机器的机器上回来的。
把两者放在一起对比。第 1 步,取自主机器上的原始仓库:
order-1042 paid 2026-08-16第 7 步,取自两条命令之前根本还不存在的仓库,而且是在不同的硬件上:
order-1042 paid 2026-08-16这就是本教程的核心:不是一份”备份成功”的报告,而是那一行数据本身,从另一台机器上被原样读了回来。
第八步：可以随时回溯的备份
rdc backup snapshot my-app复制到另一台机器，得到的是 repository 此刻的样子。要获得可以回溯的历史记录，快照会发送到分块存储：第一次运行上传写入的块，之后每次运行只上传变更的部分，任何快照都可以单独恢复。这条命令这里只是写出来，并未执行，因为上传需要账户服务器和已授权的 repository，而录制环境两者都没有。在你自己的安装环境中，拥有账户后，这就是需要输入的命令。
在你自己的安装环境中,配合账户使用时,完整流程是:
rdc backup snapshot my-app
rdc backup manifests my-app
rdc backup restore my-app --as my-app-yesterday --at <snapshot-id> --up备份与恢复指南完整介绍了快照、保留策略和校验。
下一篇：网络与域名。