存储 VPS 算备份吗？廉价 TB 能保护什么

存储 VPS 是您数据的一份副本

存储 VPS 是一台租用的 Linux 服务器，配备大容量低价磁盘，按 TB 而不是按 CPU 核心计费。它会在另一栋建筑中保存一份数据副本，这是备份的一部分。只有当该副本位于原始数据的故障域之外、保留旧版本、在离开本机前已加密，并且您至少成功恢复过一次时，它才算备份。

德国读者已经有一句适用的表述：RAID ist kein Backup。RAID（独立磁盘冗余阵列）不是备份。对于廉价 TB 存储，这一警告同样成立，原因也相同。冗余只能防止硬件故障，而绝大多数导致数据丢失的情况都不是硬件故障。

存储 VPS 与普通 VPS 的区别主要在磁盘：空间更大、介质更慢、CPU 更少。这个对比能说明您租用的是什么，但不能说明您在其上构建的系统在经历严重故障后是否仍能保留文件。

廉价的 TB 为什么便宜

存储方案之所以便宜，是因为其底层资源成本较低。每个原因都会在恢复过程中带来相应影响。

• 底层介质是机械硬盘。存储方案建立在硬盘之上，有时前面还配有小容量固态缓存。IOPS（每秒输入/输出操作数）较低，因此恢复 1000000 个小文件，所需时间远长于恢复总大小相同的单个大文件。
• 容量采用超额预配。由于大多数方案永远不会用满，服务商销售的 TB 数量会超过客户在任意一天实际写入的数据量。这是正常做法，价格中已经考虑了这一点。这也意味着吞吐量会与同一主机上的其他客户共享。
• 网络端口通常是最先被限制的资源。端口带宽足以支持每晚运行增量备份，但恢复数百 GB 的完整数据通常需要数小时。
• 冗余由服务商负责。方案中的 RAID 及其他复制机制，可在磁盘故障时保持服务商的服务运行。但它们不会保留您文件的昨日版本。

[
  {
    "label": "Managed storage box",
    "eur_per_tb_month": 4
  },
  {
    "label": "Storage VPS, spinning disk",
    "eur_per_tb_month": 5
  },
  {
    "label": "Object storage",
    "eur_per_tb_month": 6
  },
  {
    "label": "Block volume on a server",
    "eur_per_tb_month": 45
  },
  {
    "label": "NVMe inside a compute plan",
    "eur_per_tb_month": 60
  }
]

这些是根据 2026 年 9 月公开价格页面整理的四舍五入数据，按产品类型而不是服务商分组。因此，应将其视为市场的大致形态，而不是正式报价。存储方案中的 1 TB 每月价格约为 €5。作为连接到计算服务器的块存储卷，同样的 1 TB 每月价格约为 €45；作为计算方案中的 NVMe 存储，每月价格约为 €60。两者相差超过 10 倍。较慢的介质和超额预配共同构成了这一价格差异。存储 VPS、块存储和对象存储中廉价 TB 的对比将介绍每种方案在哪些场景下更具优势。

RAID 不是备份：阵列实际保护的内容

RAID 阵列会将数据写入多个磁盘，以便服务在磁盘故障时继续运行。这就是它的全部作用。下面的每个事件都会同时影响阵列中的所有磁盘，因为阵列正是按照指令执行的。

• 在错误路径上执行 rm -rf。删除操作会在同一时刻同时作用于镜像的两侧。
• 同步操作复制了错误。rsync -a --delete /srv/ backup:/srv/ 会在目标端删除源端已删除的内容，因此第二份副本最终也会和第一份一样为空。
• 勒索软件。它会加密文件，而阵列会在每个磁盘上如实保存这些加密文件。
• 迁移或升级操作在原位置重写数据库，但操作出错。
• 应用层损坏。错误的数据字节仍会被正确写入所有磁盘。
• 账户被停用。未支付账单、服务暂停或区域关闭都会使阵列一并不可用，因为同一账户内的冗余无法在该账户失效后继续存在。

这份列表已经说明了原因。VPS 上的 RAID 10 解释了阵列真正能提供什么，也就是在磁盘故障时保持服务运行；意外执行 rm -rf 后的恢复实际涉及什么 则说明，删除操作一旦写入，阵列能提供的帮助非常有限。

快照与备份的边界

快照是由服务商自己的存储层创建并保留的卷在某个时间点的映像。快照可在几分钟内恢复，成本几乎为零，因此每次执行高风险更改前都应创建快照。但快照仍不是备份，因为它存储在受其保护的系统内部。快照依赖服务商的控制平面才能存在和恢复，费用计入与服务器相同的账户；一旦该账户不可用，快照也会立即无法访问。快照与备份的完整对比逐项说明两者分别保存哪些内容。

备份副本必须满足的条件

• 独立的故障域。使用不同的服务提供商、不同的账户，或至少使用位于另一栋楼且账单独立的存储。与原始数据共享单一故障点的副本，会与原始数据同时失效。
• 保留历史版本，而不是简单镜像。版本历史必须足够长，能够覆盖延迟发现的问题。例如在第 9 天发现勒索软件，而只保留 7 天历史记录，就只能恢复已经受损的数据。
• 在上传前完成加密。任何人在存储服务器上拥有 root 权限，都可以读取以明文发送的内容；入侵存储服务器的人也一样可以读取。
• 由您亲自执行过恢复。在亲自完成一次恢复之前，您拥有的只是关于数据可恢复性的假设，而不是备份。

存储 VPS 如何纳入 3-2-1 备份策略

3-2-1 是一条经典规则，至今仍然适用：保留 3 份数据副本，使用 2 种不同类型的存储介质，其中 1 份存放在异地。对于一台小型生产服务器，实际可以这样安排。

1. 生产服务器上的实时数据。这是第 1 份副本，但它本身不构成任何备份。
2. 存储 VPS 上的 restic 仓库，通过 SFTP（SSH file transfer protocol）写入。服务器不同，建筑物不同，并且数据会在传输前加密。这正是存储 VPS 真正适合承担的部分。
3. 其他位置的第 2 个仓库：办公室中的磁盘、对象存储 bucket，或另一家服务商提供的存储。保留两个 restic 仓库介绍了如何在两个仓库之间复制数据，因此第 3 份副本无需再次从生产服务器完整上传。

下面是人们经常忽略的部分。如果生产 VPS 和存储 VPS 使用同一个账户、同一家服务商，并且位于同一座城市，那么第 1 份和第 2 份副本属于同一个故障域。这种配置仍然有价值，但不符合该规则所说的异地备份；一个账户丢失会同时影响两份副本。将 VPS 用作异地备份目标和将存储 VPS 与主 VPS 配对分别介绍这两种选择。

sudo apt update && sudo apt install -y restic
sudo install -d -m 700 /etc/restic
sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /etc/restic/repo.key'

现在就将该密钥复制到密码管理器中，不要等到首次备份运行后再操作。restic 仓库的密码一旦丢失，按设计就无法恢复，restic 也明确说明了这一点：Fatal: wrong password or no key found。提交支持工单也无法逆转此结果。

export RESTIC_REPOSITORY="sftp:backup@storage.example.net:/srv/restic"
export RESTIC_PASSWORD_FILE=/etc/restic/repo.key
sudo -E restic init
sudo -E restic backup /srv /etc --exclude-caches
sudo -E restic snapshots

restic snapshots 现在应输出一行信息，其中包含今天的日期、主机名以及要备份的路径。SFTP 后端会以调用它的用户身份运行系统的 ssh 客户端，因此在 sudo 下，它读取的是 root 的 ~/.ssh，而不是你的文件。用于登录用户的 SSH 密钥如果从未为 root 安装，是首次 init 挂起或被拒绝的最常见原因。在 VPS 上完成 restic 配置介绍了用于确定备份数据量的包含和排除规则。

sudo -E restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

保留足够长的历史，以覆盖延迟发现的问题。7 个每日快照看似充足，但如果后来才发现某个损坏的表已经损坏了 3 周，就远远不够了。按 TB 计费的方案通常具有较低的快照存储成本，因此不应在这里节省空间。

[Unit]
Description=Nightly restic backup

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@storage.example.net:/srv/restic
Environment=RESTIC_PASSWORD_FILE=/etc/restic/repo.key
ExecStart=/usr/bin/restic backup /srv /etc --exclude-caches
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

[Unit]
Description=Run the restic backup nightly

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers 'restic-backup*'

在数据离开您的机器前加密

restic 使用从仓库密码派生的密钥加密每个数据块，因此存储 VPS 上只保存密文。主机仍可看到仓库大小、包含的对象数量，以及您写入数据的时间。主机无法读取数据内容。正是这一点使租用的 1 TB 存储空间足以用于存放个人数据，因为机密性问题不再取决于提供商的基础设施，而取决于您如何管理密钥。

如果改用普通的 rsync 将数据备份到已挂载的共享目录，文件会以可读形式存放在那里。拥有该机器上 root 权限的任何人都能读取这些文件，包括入侵该机器的攻击者。在存储 VPS 上加密数据介绍了另一种方案：在文件下方使用加密容器或文件系统层。restic 和 borgbackup 都在客户端加密，因此二者的选择取决于仓库格式和工作流，而不是主机能否读取文件。

这里还有一个重要特性。生产服务器可以删除的备份，勒索软件也可以删除，因为恶意软件使用的是备份任务持有的凭据。为生产主机提供指向仓库的仅追加路径。rest-server 提供了专为此设计的 --append-only 模式，因此遭入侵的客户端可以添加新快照，但无法删除旧快照；清理操作则从另一台使用不同凭据的机器上运行。VPS 遭入侵后的处理方法以一个前提开始：攻击者已经获得服务器拥有的一切。

本周要执行的恢复测试

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /var/tmp/restore-test --include /etc/nginx
sudo diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

单独运行 check 可验证存储库结构和索引。--read-data-subset=5% 会下载一部分实际数据块并验证它们，因此可以发现已经悄悄损坏的存储。diff -r 不输出任何内容才表示通过。任何输出都表示恢复的副本与原数据并非逐字节一致。现在发现这个问题，总比真正需要恢复时才发现好得多。

该测试只能证明写入存储库的那台机器可以读取存储库。更重要、也更困难的测试是：将存储库恢复到另一台机器。准备一台全新的 VPS，只使用存储库 URL 和密码管理器中的密码，并保持生产服务器关闭。记录整个恢复过程的耗时。这个时间就是 RTO（恢复时间目标）。它通常远高于预期，因为机械硬盘方案重新组装小文件的速度很慢。存储 VPS 磁盘速度的预期可帮助您在承诺恢复时间窗口前了解这些耗时的大致范围。

要恢复单个已删除的文件，可使用 sudo -E restic mount /mnt/restic（需要安装 fuse3 软件包）。它会将每个快照作为普通目录树提供，您可以直接从中复制文件。对于小型故障，这是最快的恢复方式，而大多数故障都属于这种情况。

DSGVO 第 32 条：服务商的 RAID 不会免除您的义务

如果您处理欧盟居民的个人数据，就必须遵守 DSGVO（Datenschutz-Grundverordnung），这是 GDPR（通用数据保护条例）的德语名称。第 32(1) 条直接规定了技术措施。第 (a) 项要求对个人数据进行加密。第 (b) 项要求持续确保处理系统的机密性、完整性、可用性和恢复能力。第 (c) 项要求在发生物理或技术事件后，能够及时恢复个人数据的可用性和访问权限。第 (d) 项要求定期测试和评估这些措施是否确实有效。

将 (c) 和 (d) 放在一起看，法律要求与工程要求实际上是同一项要求：您必须能够执行恢复，并按照计划证明恢复确实可行。服务商的 RAID 只是其自身基础设施内部的一项措施。它无法说明您是否能够恢复自己的数据，因此不能作为您需要提供的任何证明。如果服务商代表您处理个人数据，您还需要 AVV（Auftragsverarbeitungsvertrag，即第 28 条规定的处理者合同），而控制者的责任无论如何仍由您承担。这不是法律建议，您的 Datenschutzbeauftragter（数据保护官）会要求您记录恢复测试，并注明测试日期。

数据实际存储在哪些物理位置，也应记录在同一份文件中。欧盟数据驻留及其成本介绍了其中的权衡，德国存储 VPS 服务商介绍了您可以选择的市场。这里常见的名称包括 Hetzner、Contabo、netcup 和 IONOS，它们都提供存储服务器或存储 VPS 类产品。任何一家服务商对持久性作出的承诺，都以其当前条款为准。因此，请阅读您实际购买的套餐条款，不要只看数月前编写的摘要。

故障模式及你将看到的字符串

仓库路径不是你以为的路径。 restic 会输出 Fatal: unable to open config file: Stat: file does not exist，随后输出带 URL 的 Is there a repository at the following location?。这表示 init 从未运行，路径错误，或者 SSH 用户登录后进入的主目录与编写路径时假定的目录不同。

手动运行正常，但从定时器运行失败。 日志显示 Host key verification failed.。交互式运行使用了你的用户 known_hosts，而定时器以 root 身份运行；root 从未连接过该主机。运行一次 sudo ssh backup@storage.example.net 并接受密钥，或者手动将密钥写入 /root/.ssh/known_hosts。

某次运行被终止后，下一次运行被阻塞。 unable to create lock in backend: repository is already locked exclusively by PID 1234 表示之前的 restic 进程退出时未完成清理。确认没有进程正在运行，然后执行 sudo -E restic unlock。

存储计划空间已满，所有备份都失败。 存储端返回 no space left on device。这几乎总是因为 forget 策略在没有 --prune 的情况下运行，导致旧快照被遗忘，但其数据仍保留在磁盘上。存储 VPS 容量规划介绍 prune 步骤需要多少可用空间才能运行。

恢复结果正确，但速度太慢。 在采用机械硬盘的存储计划上恢复数百万个小文件时，速度可能远低于预期。应将数据库转储备份为单个文件，而不是恢复在线数据目录树，并在发生事故前实际测量恢复时间，不要让事故来决定你的截止时间。

本周要做什么

1. 选择一个丢失后会造成实际影响的目录，并在 restic snapshots 中找到它。
2. 将该目录从存储 VPS 恢复到 /var/tmp，但不要在生产服务器上执行。
3. 对原目录运行 diff -r，并阅读输出，不要想当然地认为输出为空。
4. 记录日期和耗时，并将其写入列出 Art. 32 措施的同一份文档。存储 VPS 检查清单 是一个合适的位置，可以将其与计划详情放在一起。

FAQ

存储 VPS 是备份吗？

单独来看，不是。存储 VPS 是租用硬件上的一份数据副本，只能算备份的一部分。只有在它位于原始数据故障域之外、保留足够的版本历史以覆盖延迟发现的问题、在上传前已加密使主机提供商无法读取，并且你至少成功执行过一次恢复时，它才算备份。如果没有进行恢复测试，你拥有的只是未经测试的副本。

RAID 是备份吗？

不是。德语简写 RAID ist kein Backup 的含义完全正确。RAID 的作用是在磁盘发生故障时保持服务运行。它会同时将每项更改写入所有磁盘，包括 rm -rf，包括勒索软件执行的操作，也包括会把你的错误同步到副本中的 rsync --delete。RAID 还会随着计费账户一同消失。RAID 是可用性措施，不是恢复措施。

提供商快照算不算 3-2-1 备份中的一份副本？

不能算异地副本。快照位于提供商的存储层中，与它所创建快照的卷相邻；恢复时依赖提供商的控制平面；费用也计入与服务器相同的账户。它非常适合在几分钟内回滚有问题的升级。应将其视为真实备份之上的便捷层，并至少在其他账户或其他提供商处保留一份副本。

应多久测试一次恢复？

小型环境应每季度测试一次；每次更改备份内容或备份目标后，也应进行测试。DSGVO Art. 32(1)(d) 要求定期测试和评估相关措施，因此测试需要记录日期和书面结果，不能只凭记忆确认曾经成功。至少应按计划运行 restic check --read-data-subset=5%，并手动将数据完整恢复到另一台机器。

应将 restic 仓库密码存放在哪里？

不要只存放在被备份的服务器上。restic 仓库的密码一旦丢失，任何人都无法打开该仓库，包括提供商；restic 会返回 Fatal: wrong password or no key found。请将密钥存入密码管理器，并在一个离线位置保留一份，例如将打印件放在保险箱中。如果唯一的密钥副本存放在你正尝试恢复的那台机器上，那么你没有备份。