外观
异地副本：远程同步、S3 与磁带
一台 PBS 配上 ZFS 冗余，解决的是"硬盘坏了"。但如果 PBS 本身和 PVE 在同一个机房、会被同一次事故（火灾、水灾、盗窃、整栋楼断电）一起影响，你实际上仍然只有"一份"数据的一个故障域。这篇讲三种把数据搬到"更远"的地方的方式。
先回顾一遍：冗余不是备份，同城也不算异地
一台 PBS 加 ZFS 镜像防的是硬盘坏；PBS 整机没了（被偷、水淹、烧毁）才是这篇要防的。同一栋楼的两个机柜不叫异地——能扛住同一次事故（火灾、水灾、整个机房断电）的地理距离，才算真正的异地。
方式一：PBS 到 PBS 的同步任务（Sync Job）
先在 Configuration → Remotes 里添加另一台 PBS：填它的地址、一个用户账号、以及证书指纹（自签证书用 proxmox-backup-manager cert info 获取）。配置存在 /etc/proxmox-backup/remote.cfg。加好 remote 之后就能配置同步任务了。
Pull 方向（默认）
本地主动向远端"拉"数据，配置存在 /etc/proxmox-backup/sync.cfg。常用选项：
| 选项 | 作用 |
|---|---|
remove-vanished | 远端已经不存在的内容，本地也一并删除（见下方危险提示） |
verified-only / encrypted-only | 限制只同步已校验/已加密的快照 |
group-filter | 按类型、分组 ID 或正则筛选，支持 exclude: |
resync-corrupt | 重新同步之前校验失败过的快照 |
worker-threads（1–32） | 并行处理多个分组，加速高延迟链路 |
rate-in / burst-in | 限速 |
权限要求：对远端要有 Remote.Read，对本地目标数据存储至少要有 Datastore.Backup。
Push 方向
本地主动往远端"推"数据。行为和 pull 不完全一样，因为要走远端的 API：推送上去的内容归属"remote 配置里那个用户"所有。
每个 push 任务用独立的 remote 配置和用户
多个 push 任务如果共用同一个 remote 用户，彼此之间可能删掉或跳过对方刚推上去的快照。给每个方向配一套独立的 remote 和用户。
权限要求：Remote.Audit + Remote.DatastoreBackup；要清理远端过期内容的话，还需要 Remote.DatastorePrune 或 Remote.DatastoreModify。用 rate-out/burst-out 限速。push 任务还能在发送前用服务端配置的密钥，把还没加密的快照就地加密再发送；已经加密的原样传输，部分加密的会被跳过。
remove-vanished 会把一端的备份删掉
不管是 pull 还是 push 方向，只要勾选了清理"已消失"内容的选项，源端一旦有快照被误删或被 prune 清理掉，下一次同步就会把对端对应的快照也删掉。这意味着一次误操作可能同时影响两份拷贝，而这恰恰违背了"异地副本"存在的意义。
预防措施：异地这一份至少保留一个不清理已消失内容的同步策略，或者只增不减，等空间紧张时再人工核对、手动清理。核心原则是：至少留一份"稍微落后"、不会被主库的删除操作直接同步过去的副本。
方式二：S3 兼容对象存储
当前状态（截至 PBS 4.2，2026-04）：S3 支持从 PBS 4.0 起以技术预览形式提供，PBS 4.2 起官方将其列为正式支持的数据存储后端（不再是技术预览）。这个状态请以你实际部署时的官方发布说明为准。
用法：先在 S3 服务商（或自建的 MinIO、Garage 等）那边建好 bucket 和访问密钥，权限至少要有 GetObject/PutObject/ListBucket/DeleteObject；然后在 PBS 的 Configuration → Remotes → S3 Endpoints 里配置端点，创建一个 S3 类型的数据存储。
要点：
- 只支持 HTTPS，自签证书需要额外提供证书指纹。
- 本地缓存是必需的，不能用纯内存缓存，推荐 64–128 GiB、独立的磁盘/分区/ZFS 数据集。
- 一个 S3 数据存储同一时间只能被一台 PBS 实例管理。
- 已有的普通目录型数据存储不能直接转换成 S3 型。
- 会产生持续的存储、请求和流量费用；PBS 4.2 起能统计 S3 的请求量和流量，方便及早发现异常消耗。
- bucket 空间用满时，连清理操作本身都可能失败，需要手动到 S3 那边删除多余对象，再跑一次刷新。
什么时候值得用 S3
更适合当作第二、第三份异地副本（配合同步任务把本地 PBS 的数据同步过去），而不是唯一的主力数据存储——冷存储的恢复速度，以及按请求计费的 GC/verify 开销，通常不如本地磁盘划算。
方式三：磁带备份
PBS 支持 LTO-5 及更新的磁带驱动器（LTO-4 尽力支持，可能需要升级固件或存在功能缺失）。磁带库/机械手通过 SCSI Medium Changer 协议控制，官方说法是"现代磁带库基本都能用"。PBS 用自己写的用户态驱动，不要和 Linux 内核自带的磁带驱动混用。
加密：LTO-4 起磁带驱动器自带 AES-GCM 硬件加密，给 media pool 配一把密钥后，写入的内容会被加密；密钥的密码保护副本会存在每盘磁带上，同样支持导出纸质 paperkey。客户端已经加密过的数据写到磁带上会变成双重加密。
Media pool（介质池）：一组磁带的集合，备份任务实际写入的单位是"介质集（media set）"。集内数据完全去重，这意味着集里任何一盘磁带损坏，都可能导致整个集恢复失败。allocation 策略决定何时开启新的介质集（一直写入当前集、每个任务开新集，或按日历规则）；retention 策略决定磁带何时能被覆盖（总是覆盖、保护一段时间、或永不覆盖，配合 WORM 磁带使用）。
磁带值不值得投入
对家庭和小团队，磁带库和驱动器的前期投入通常不小；它的独特价值在"完全离线、防在线篡改"——如果你的策略里已经有一份异地磁盘或云存储副本，磁带更适合数据量大、有长期归档或合规需求的场景，属于进阶选项。官方文档也提到磁带恢复通常比磁盘恢复慢得多，不适合追求恢复速度的场景。
三种方式怎么选
| 方式 | 解决什么 | 代价 |
|---|---|---|
| PBS 到 PBS（pull） | 本地主动去异地拉取，适合有两台自管 PBS 的场景 | 需要在异地也维护一台 PBS，留好公网或 VPN 通道 |
| PBS 到 PBS（push） | 从生产侧主动推向异地，权限收得更紧 | 每个任务要单独配用户，配置更繁琐 |
| S3 | 利用现成的云存储，不用自己管硬件 | 持续产生费用、恢复较慢、依赖网络 |
| 磁带 | 完全离线，防在线篡改和勒索软件 | 硬件投入高、恢复慢，适合有一定规模的场景 |
检查结果
- 至少一种异地方式已经配置完成，手动跑一次同步或写入，确认成功。
- 在异地那份数据上，实际做过一次 恢复演练——确认"换一台新机器能不能连上这份异地数据"这件事本身没有坑（证书指纹、网络、密钥）。
- 已经确认"清理/覆盖"类选项（
remove-vanished、介质池的覆盖策略）不会让你在一次误操作里同时失去所有副本。
常见问题
同步任务一直连不上 remote。 先检查对端证书是否重新生成过（指纹会变），再检查网络连通性和防火墙规则。
S3 费用突然升高。 检查是不是 verify 或 GC 任务过于频繁地扫描导致大量 API 请求，参考 PBS 4.2 新增的请求统计面板定位。
没有第二台物理机，还能做异地吗？ S3 是更现实的起点，哪怕只当作额外的一个同步目标。