[首页](https://servhidden.com/zh) / [隐私托管指南](https://servhidden.com/zh/guides) / VPS备份完全指南:加密、异地存储与恢复测试 运营管理 # VPS备份:确保真正可恢复 无实名主机拿走的不只是身份信息,还有安全网:不保留备份,服务器终止后24小时内数据被销毁,也没有能找回副本的客服渠道。本文是一份可执行的方案——该复制什么、放在哪里、如何防止攻击者删除它,以及如何证明它真的能恢复。 [阅读指南](#guide-body) [常见问题](#guide-faq) ## 本页内容 - [指南](#guide-body) - [常见问题](#guide-faq) - [相关指南](#guide-related) - [推荐页面](#guide-cta) 无需KYC 仅限加密货币 零日志 忽略 DMCA 完整Root权限 NVMe固态硬盘 16 分钟阅读 更新于 Aug 2026 本页内容 [01服务器真正是怎么丢的](#服务器真正是怎么丢的) [02快照不是备份,你的主机也不是](#快照不是备份你的主机也不是) [033-2-1原则,写给从未提交过身份证明的人](#3-2-1原则写给从未提交过身份证明的人) [04推送、拉取,以及让一个坏夜晚吞掉两份副本的那个错误](#推送拉取以及让一个坏夜晚吞掉两份副本的那个错误) [05先在源端加密,再决定密钥交给谁保管](#先在源端加密再决定密钥交给谁保管) [06一张表选出合适的工具](#一张表选出合适的工具) [07只要还在运行,就不是一个文件](#只要还在运行就不是一个文件) [08该备份什么,以及所有人都会忘记的部分](#该备份什么以及所有人都会忘记的部分) [09没测试过的恢复只是个传闻](#没测试过的恢复只是个传闻) [10把它自动化,让它持续发生](#把它自动化让它持续发生) [11浓缩版](#浓缩版) [FAQ常见问题](#guide-faq) [→推荐页面](#guide-cta) 备份方案从来不是在服务器出事的那一晚才接受检验,而是在几周之前,由三个没人写下来的静默决定所决定:副本放在哪里、谁有权删除它,以及是否真的有人把它读回来验证过。 从不询问你身份的主机服务,换来的代价也要老实说清楚:没有客户经理可以联系,没有工单能让被清空的硬盘复活,[我们自己的数据保留政策](https://servhidden.com/zh/privacy)也说得很直白:服务器终止后24小时内数据即被销毁,硬盘经过加密擦除而非简单格式化,并且**不保留任何备份**。这正是让这个平台值得使用的同一个特性,只是从另一个角度看而已。任何你希望在糟糕的一夜之后还能找回的东西,都必须提前存在别处,而把它放到那里的人只能是你自己。 ## 服务器真正是怎么丢的 几乎没有人是以自己想象的方式丢掉服务器的。灾难性硬件故障确实存在,但很罕见,而且这恰恰是靠谱主机早已针对性防范的一种情况。真正会发生的损失往往更平淡,而且每一种都会打败某一类特定的副本——这就是为什么"我有备份"本身不是答案,除非你能说清楚它能扛住下面哪几种情况。 | 出了什么问题 | 通常是怎么发生的 | 什么能让你找回来 | | --- | --- | --- | | **自己手滑** | Shell变量为空导致的一次rm -rf、指向生产环境的迁移脚本、误删错误表的一次部署 | 任何在失误*之前*就已存在的异地副本——这意味着保留时间必须比你发现问题所需的时间更长 | | **悄悄发生的损坏** | 一块正在报废的NVMe、重启过程中被截断的写入、连续一周写入错误行的数据库 | 版本足够深、能追溯到已知良好状态的多版本副本。单一镜像副本只会忠实地把损坏也镜像一遍 | | **入侵** | 被盗的密钥、未打补丁的应用、被投毒的依赖——然后,攻击者会刻意对你的备份下手 | 一份被入侵的机器根本无权删除的副本。这里只有这一种才算数 | | **服务商或国家层面的事件** | 硬件损毁、数据中心遭遇的法律行动、一个你再也登录不了的账号或令牌 | 一份不在该服务商、也不受该司法辖区管辖的副本 | | **丢失密钥** | 忘记的密码短语、随所保护服务器一起被清除的密钥文件、没人导出过的LUKS头 | **无法挽回。**这是唯一一行没有"找回方式"的情况,而且它比硬件故障更常见 | 把这张表当作检查清单来读,而不是恐惧清单。每晚复制到同一台机器第二块硬盘的做法,只能应对第一行,别的都不行。同一面板里的快照能应对第一、二行。只有存放在服务器触及不到的地方、且你仍持有密钥的副本,才能应对全部五种情况。 备份目标需要的是硬盘和一个地址,不是核心数。位于不同司法辖区、最便宜的第二台服务器就是一个称职的端点——也是唯一能在第一个服务商出事后依然存活的副本。 ## 快照不是备份,你的主机也不是 快照擅长做的事情它确实做得很好:几秒钟内、无需任何传输就能回滚一次失败的升级。但它做不到的是,扛过夺走整台服务器的那种事件,因为它和服务器共享同一个故障域——同一个服务商、同一个账号、同一个支付令牌、同一个国家,往往还是同一个存储集群。快照保护你不受*自己*所害,备份保护你不受其他一切所害。 在这里,这个区别比在主流主机那里更重要,因为通常的安全网是被故意拆掉的。没有人会登录客户的服务器,所以也没有人会注意到你的备份任务从三月起就一直在失败。账号没有绑定任何身份信息,所以也不存在"证明你是谁,我们就帮你恢复"这种人工路径。而终止账户是真正意义上的终局:余额耗尽是一次数据丢失事件,而不只是一次账单事件。 **24小时条款就是全部论点所在。**在这个平台上,被终止的服务器数据会在一天之内被销毁,硬盘经过加密擦除而非简单格式化。没有撤销删除,没有悄悄保留的冷存储层,也不存在"我们找到了一份旧副本"这种客服结果——因为保留一份就意味着在你要求我们删除之后仍然持有你的数据。安全网和隐私,本质上是同一笔交易,而且只做一次。 ## 3-2-1原则,写给从未提交过身份证明的人 经典法则是:三份副本,两种介质,其中一份异地存放。这条规则诞生于磁带和机械硬盘的年代,如今"介质"这一条已经悄悄失去了意义:你的生产盘是NVMe,备份目标的盘也是NVMe,把这称为"两种介质"不过是自我安慰的说法。真正值得保留的是关于"距离"的那一条,而对离岸基础设施来说,距离从来不是用公里数衡量的。 把它改写成**三份副本、两个服务商、两个司法辖区**。同时摧毁两份副本的事件几乎从来不是物理层面的——它们通常是一个你失去访问权限的账号、一个状态不佳的服务商,或者一份能覆盖某个国家却管不到另一个国家的法律文件。同一机架里的两台服务器,不过是多绕了一圈的一份副本;处在同一法律辖区下的两台服务器,也好不到哪里去。我们的[司法辖区选择指南](https://servhidden.com/zh/guides/choosing-an-offshore-jurisdiction)介绍了如何挑选第二个辖区,让它不至于和第一个承担同样的风险。 实际操作起来成本很低。备份目标不需要核心数,几乎也不需要网络带宽——它需要的只是硬盘和一个地址。最小的[VPS套餐](https://servhidden.com/zh/vps),只要选在我们[七个机房位置](https://servhidden.com/zh/locations)中不同的一个,就是一个称职的restic或Borg端点;而对于以TB计的归档数据,一台带真实硬盘的[独立服务器](https://servhidden.com/zh/dedicated),每TB成本比任何对象存储都低。当数据量确实很大、又很少被读取时,裸金属在经济性上有明显优势。 有一件事人们在生产环境上做对了,却在备份目标上做错了:付款方式应该一致。用你自己名下的银行卡买第二台服务器,会悄悄把你在第一台上费尽心思摆脱的身份重新绑定回去,而且这台服务器现在还保存着第一台的完整副本。如果生产服务器是[用门罗币支付](https://servhidden.com/zh/guides/how-to-pay-for-hosting-with-monero)的,备份服务器也应该同样对待。 第三份副本是大多数人会跳过的一份,却是唯一能同时扛住所有远程故障的一份:一块你亲手持有、偶尔更新、平时离线保存的硬盘。对大多数人来说,每月更新一次就够了。它花费的不过是一杯咖啡钱的注意力,却是唯一能扛住前两份副本共同弱点的那一份。 ## 推送、拉取,以及让一个坏夜晚吞掉两份副本的那个错误 下面是几乎所有人最先搭建起来的方案。生产服务器上的一个任务每晚运行,持有备份目标的密钥或令牌,连接过去,然后推送数据。它能用,也很简单,但它有一个特性,只有在服务器最糟糕的那一天才会显现出来:**谁控制着生产服务器,谁就控制着备份。** 这不是假设。在正式发难之前先删除或加密受害者的备份,是所有商业化攻击者的标准操作——凭证就摆在某个cron任务或环境变量文件里,找到它们只需要一分钟。一份攻击者能删除的副本,根本不算第二份副本,它只是第一份带延迟的镜像。 有两种干净的解决办法,而且和你本该已经做好的[基础加固](https://servhidden.com/zh/guides/first-hour-vps-hardening-checklist)配合得很好。 - **只追加写入的目标。**两款主流工具都支持一种模式:客户端只能新增数据,不能删除数据。Borg的做法是把目标端的SSH密钥锁定为borg serve --append-only;restic的做法是启动带--append-only参数的REST服务器。生产服务器每晚写入,但从结构上就没有能力销毁历史记录。清理旧快照的操作随后在目标端进行,而这是一个生产服务器无法发起的会话。 - **用拉取代替推送。**把方向反过来:由备份主机连接生产服务器,读取数据并存储。生产端根本不持有目标端的任何凭证,也就没有什么可偷的。在生产端使用的密钥上加上restrict和强制的command=限制,这样被盗的备份密钥也无法变成一个可用的shell。 拉取模型更强,运行起来也稍微麻烦一点;如果你已经在用Borg或restic,只追加写入几乎是零成本的。这两种做法都能把"攻击者删除了我的备份"从一个既成事实变成一次未遂的尝试。如果你只从本文里记住一件事,那就记住这一节。 ## 先在源端加密,再决定密钥交给谁保管 两款正经的工具都会在被备份的机器上、在任何数据越过网络之前完成加密。备份目标存储的是它自己无法解读的数据块——这正是跨服务商副本安全的原因所在。你的第二台主机不需要可信,甚至不需要友好;它只需要能连上、有硬盘就够了。正是这一个特性,把"一台在陌生国家的服务器"从风险变成了基础设施。 这和给服务器自身硬盘加密是不同的机制,两者回答的是不同的问题——我们关于[VPS全盘加密](https://servhidden.com/zh/guides/full-disk-encryption-on-a-vps)的指南详细讲解了磁盘加密在机器运行时能保护什么、不能保护什么。备份加密是两者中更简单也更有价值的一种,因为它的威胁模型很诚实:数据处于静止状态,存放在你不掌控的硬件上,而密钥从未去过那里。 这就把全部风险转移到了密钥保管上。密码短语现在是唯一的全损失点,而且比人们预期的更糟,因为丢失它的过程是无声的——什么都不会报错,备份照常运行,而你恰恰会在最需要它的那一刻才发现问题。三个习惯可以解决这个问题: - 密码短语在服务器上只以一份仅root可读的文件形式保存,通过--password-file引用,这样它就永远不会出现在进程列表或shell历史记录里。 - 在所涉及的每一台机器之外,保留一份人可读的副本。抽屉里的一张纸,确实胜过一个同步到你也可能失去访问权限的账号的密码管理器。 - 给仓库再添加一把密钥——restic key add,或者一份导出的Borg密钥——这样忘记一个密码短语就只是麻烦,而不是整个归档的终结。 三条习惯背后的同一条规则:**如果密钥唯一的副本就存放在备份原本要替代的那台机器上,那你就没有备份。**你只有一堆加密的数据块,和一个关于它们的故事。 ## 一张表选出合适的工具 工具的选择,重要性其实不如连接方向和密钥状态,这也是为什么它排在第六位而不是第一位。话虽如此,工具之间的差异是真实存在的,选错形状会给以后带来麻烦。 | 工具 | 离开前是否加密 | 是否去重 | 支持只追加目标 | 适用场景 | | --- | --- | --- | --- | --- | | **restic** | 是,整个仓库 | 是 | 是,通过其REST服务器 | 默认之选。支持SFTP、对象存储和自带服务器,目标端几乎可以是任何东西 | | **BorgBackup** | 是,整个仓库 | 是,同类中最强 | 是,原生支持SSH | 通过SSH连接的单个Linux目标。数据量大且重复度高时无可匹敌 | | **带轮换的rsync** | 否——目标端能看到一切 | 部分支持,通过硬链接 | 否 | 镜像到一台你完全掌控的机器,适合即时局部恢复比隐私更重要的场景 | | **rclone** | 仅在使用rclone crypt时 | 否 | 取决于存储服务商 | 把已存在的归档搬进对象存储,或在服务商之间迁移 | | **ZFS复制** | 仅在使用加密数据集时 | 是,块级别 | 通过快照权限实现 | 在两台ZFS机器之间复制。速度很快,但对两端要求都很严格 | | **tar配合age或GPG** | 是,如果你加密归档文件 | 否 | 不适用 | 体量小、不常做、永久保存的归档,简单胜过效率 | 对单台服务器来说,用restic备份到第二台VPS是通向正确方案最短的路径。对于种子机、媒体归档,或者大量相似的大文件,Borg的去重能力决定了硬盘是被塞满还是留有余地——[种子机搭建指南](https://servhidden.com/zh/guides/seedbox-setup-guide)更详细地讲解了这类负载的存储部分。 ## 只要还在运行,就不是一个文件 世界上最常见的损坏备份,就是对一个正在运行的数据库做直接文件拷贝。它完成时不会报错,体积也刚刚好,可一旦拿去恢复,存储引擎却拒绝打开这张表。拷贝进行时数据库正处于写入过程中;你保存下来的,只是一张正在翻页瞬间的照片。 有三种解法,按投入的精力递增排列。转储它:mysqldump --single-transaction能在不锁定写入方的情况下给出一致的InnoDB转储,PostgreSQL则用pg_dump做同样的事。快照它:冻结文件系统,或者做一次LVM或ZFS快照,从快照里拷贝,再释放它——数据量大到没法每晚转储时,就靠这一招。或者直接停掉它:对一个小型服务来说,凌晨4点停机两分钟是完全站得住脚的一致性策略,也是唯一没有边界情况的一种。 同样的逻辑不止适用于数据库。容器的可写层是可以随意丢弃的,但它的数据卷不是,旁边的docker compose文件和环境变量同样不是——一份只恢复数据、不恢复定义的备份,会让你只能凭记忆重建整套技术栈。消息队列、开启了持久化的Redis,以及MTA正在写入的邮件队列,都应该获得同样的对待:先静置、快照或转储,永远不要直接拷贝然后祈祷。 ## 该备份什么,以及所有人都会忘记的部分 大多数人只备份最显眼的部分——数据库和应用目录——然后在压力之下手工重建剩下的一切。真正耗费时间的正是这个重建过程。一份能让你恢复到一个可用系统、而不只是一堆正确数据的备份,还应该包括这些不起眼的部分: - 完整的/etc目录,加上你自己写的systemd单元和定时器,以及任何存放在它之外的crontab。 - TLS证书及其私钥,至少也要有ACME账户密钥,这样证书才能续期,而不用从零开始。 - 防火墙规则和软件包列表,这两者合在一起,能比任何记忆都更快地重建出这台机器的样子。 - 应用密钥和环境变量文件——那些被特意排除在代码仓库之外的东西,也因此不会出现在别的任何地方。 - 以文本形式导出的DNS记录,包括反向DNS和PTR记录,这些信息存放在服务商那里,而不在服务器上。 **有些密钥不是数据,而是身份。**一个Tor onion服务的私钥*就是*它的地址:丢了它,无论你恢复了多少别的东西,站点都无法在同一个[.onion地址](https://servhidden.com/zh/guides/how-to-host-a-tor-hidden-service)上重新上线。一把WireGuard服务器密钥意味着要给你发放过的每一份客户端配置重新签发。邮件服务器的DKIM密钥意味着要换一个新的选择器,在[送达率](https://servhidden.com/zh/guides/offshore-mail-server-setup)上从头开始积累。闪电网络节点的种子和通道状态关乎的可能是资金,而不只是文件——[节点托管指南](https://servhidden.com/zh/guides/crypto-node-hosting-guide)对此说得很明确。把这些分开存放,离线保存,并且把它们看得比它们所保护的数据更宝贵。 ## 没测试过的恢复只是个传闻 备份软件会自己报告状态,而且它老老实实报告的往往是错的那件事。"快照已完成"的意思是数据被写进了仓库,它完全没说这个仓库能不能在另一台机器上、被一个已经不记得十一个月前是怎么配置的人读出来。 先从便宜的完整性检查做起——定期运行restic check --read-data-subset=5%或borg check --verify-data——但要清楚它们验证的是归档本身,而不是你使用它的能力。真正的演练完全不同,只需要花一个下午,做一次就够。按小时租一台你平时不用的地区的全新服务器。只凭仓库地址、密码短语和你自己的笔记,把它恢复上去。把服务跑起来,给整个过程计时,然后销毁这台机器。总花费不过几美元,而这是唯一能产出一个你可以信任的数字的演练。 它稳定暴露出来的从来不是数据本身,而是没人记录下来的缺失软件包、活在备份路径之外的配置、只存在于你正打算替换的那台服务器shell历史里的密码短语,以及能读懂你仓库格式的工具版本。这些问题每一个都能提前轻松修好,却会在故障期间让人痛苦不堪。 把演练给出的两个数字写下来:一次恢复花了多久,以及这个备份计划能承受损失多少工作量。这两个数字才是真正的备份策略,上面的一切都只是为它们服务的实现细节。 ## 把它自动化,让它持续发生 用systemd定时器来运行这个任务,而不是cron。你能获得集中在一处的日志、一份关于最近一次运行的真实记录,以及一个能扛过重启的计划——这些cron如果不额外花功夫都给不了你。别把密码短语放进unit文件本身,因为任何有shell访问权限的人都能直接用systemctl cat把它读出来。 接下来要解决真正坑人的失败模式,它不是一个错误,而是沉默。一个六周前就已经停止运行的备份,和一个运行得完美无缺的备份看起来一模一样,因为两者都不产生任何输出。**要为"没有发生"而报警,而不是为"失败"而报警。**让任务在成功时ping一个监控器,由监控器在ping没有按时到达时报警——并且把这个监控器放在被监控服务器之外的任何地方,因为一台已经宕机的机器没法报告自己宕机了。 刻意设置保留策略,而不是用默认值。类似--keep-daily 7 --keep-weekly 4 --keep-monthly 6这样的设置,既能覆盖你今晚就会发现的失误,也能覆盖你到了春天才发现的损坏,而且不会无限增长。如果你已经采用了只追加写入,就在目标端做清理,这也正是采用只追加写入的意义所在。传输流量在我们的网络上几乎从不构成瓶颈——每个套餐的带宽都不限量——所以排期时优先考虑一致性,而不是配额,并对照你自己的空闲时段来核对时间。围绕这一切更广泛的习惯,在[服务器反侦察指南](https://servhidden.com/zh/guides/server-opsec-staying-anonymous)里有介绍。 ## 浓缩版 如果这篇文章你只打算做一件事,那就按大致这个顺序做完这六件事: - 在第二个服务商、第二个司法辖区放一份副本,付款方式和第一份一样私密。 - 让那份副本只能追加写入,或者由目标端主动拉取,这样被攻破的服务器就无法销毁它。 - 让工具在源端完成加密,并把密钥放在两台机器之外。 - 转储数据库,停掉或快照任何正在运行的东西;永远不要对运行中的状态直接拷贝。 - 把身份密钥单独备份——onion、WireGuard、DKIM、节点种子——因为这些东西无法重新生成。 - 找一台一次性服务器实际恢复一次,给它计时,并写下缺失了什么。 这些都不是什么稀奇的操作,也都用不了一个周末。只需要一个下午的搭建和一次演练,就能对抗那类足以终结项目的损失。在一个刻意不保留你任何信息的平台上,你自己做的那份副本,是唯一真正存在的副本——这是这种安排的代价,也是公平的代价。在不同于第一台的司法辖区[开一台第二服务器](https://servhidden.com/zh/vps),让今晚的备份有个地方可以落脚。 常见问题 ## VPS备份常见问题 ### 01 ServHidden会帮我备份VPS吗? 不会,而且这是刻意为之,不是疏漏。我们的保留政策明确写着:不保留任何备份,服务器数据在终止后24小时内被销毁,硬盘经过加密擦除而非简单格式化。如果在你要求我们删除数据之后还保留一份副本,就违背了这个平台存在的初衷。任何你希望在服务器之外还能留存的东西,都必须由你自己复制出去,最好是复制到第二个司法辖区的另一个服务商那里。 ### 02 快照和备份是一回事吗? 不是。快照和它所属的服务器共享所有故障域——同一个服务商、同一个账号、同一个国家,往往还是同一套存储。它非常擅长撤销一次搞砸了的升级,但对账号丢失、服务商出问题或整台机器没了这种情况完全无能为力。把快照当成撤销按钮,把备份当成保险,它们解决的是不同的问题,而你两个都需要。 ### 03 restic和BorgBackup该选哪个? 如果目标可能是对象存储、SFTP,或者你还没决定用什么,就选restic,因为它支持的后端最多。如果目标是通过SSH连接的单台Linux机器,而且数据量大、重复度高,就选BorgBackup,因为它的去重能力是同类中最强的。两者都会在数据离开机器之前先在源端加密,也都支持只追加写入的目标,而这一点远比两者之间怎么选更重要。 ### 04 如何防止攻击者删除我的备份? 要拿走能力,而不是指望消除动机。要么让目标只能追加写入,这样生产服务器上的凭证只能新增数据、永远无法删除;要么反转连接方向,让备份主机主动从生产环境拉取数据,使生产服务器根本不持有任何凭证。在正式发难之前先删除备份,是所有商业化攻击者的标准操作,一份攻击者能删除的副本根本不算第二份副本。 ### 05 第二份副本应该放在哪里? 放在不同的服务商、不同的司法辖区,而且付款方式要和生产服务器一样私密。能同时摧毁两份副本的事件很少是物理层面的——通常是丢失访问权限的账号、状态不佳的服务商,或者一份能覆盖某个国家却管不到另一个国家的法律文件。同一机架里的两台服务器,不过是多绕了一圈的一份副本。由于工具在源端就完成了加密,第二台主机不需要是你信任的那种。 ### 06 多久备份一次比较合适? 从你愿意重做多少工作量倒推。一个博客丢一天的内容可能没人会注意到,但一个商店丢一个小时的订单就不行。对大多数单服务器架构来说,每晚备份是合适的默认选择,如果写入的数据很宝贵,数据库转储可以更频繁。比频率更重要的是保留深度:损坏往往要几周后才被发现,所以历史记录要足够长,能回溯到问题发生之前。 ### 07 备份放在我不掌控的服务器上加密安全吗? 就内容而言是安全的——restic和Borg在数据离开源端之前就完成了加密,所以目标端存储的是它无法解读的数据块,密钥也从未传输过去。目标端确实能了解一些元数据:大致的数据量、数据是如何变化的,以及你的任务什么时候运行。这通常是可以接受的。如果不能接受,就把计划错开一些,并把仓库放在一台归属关系和生产服务器无关联的机器上。 ### 08 备份密码丢了怎么办? 归档就永久丢失了,没有任何人能帮你找回。这是整个主题里最常见的彻底丢失场景,也是唯一没有恢复路径的失败。把密码短语保存在所涉及的每一台机器之外,纸质记录确实胜过一个你也可能失去访问权限的账号里的密码管理器,并且给仓库再加一把密钥,这样忘记一个密码就只是麻烦,而不是整个归档的终结。 相关指南 ## 继续阅读 [### 2026 年如何选择离岸托管司法管辖区 购买前 选择离岸司法管辖区的实用决策框架：数据留存法规、MLAT 风险敞口、DMCA 立场、司法效率与现实执法力度——逐国深度分析。 6 个常见问题](https://servhidden.com/zh/guides/choosing-an-offshore-jurisdiction) [### VPS 与独立服务器：哪种更适合隐私敏感工作负载 购买前 何时 VPS 已经足够，何时共享租用是一种风险，何时裸金属才是唯一诚实的答案。硬件隔离、虚拟机监控程序风险，以及成本与威胁模型的匹配。 6 个常见问题](https://servhidden.com/zh/guides/vps-vs-dedicated-for-privacy) [### 无 KYC VPS 上的自托管 VPN：WireGuard 与 OpenVPN 运营管理 为什么自托管 VPN 优于商业服务商，以及 WireGuard 和 OpenVPN 在 2026 年隐私、性能和运营风险方面的真实对比。 6 个常见问题](https://servhidden.com/zh/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090对比H100 SXM5用于AI推理（及RTX 5090的定位） 购买前 购买决策指南：2026年自托管LLM、图像、视频、语音和微调工作负载选择哪款NVIDIA GPU。RTX 4090 vs RTX 5090 vs H100 SXM5 vs 双H100——显存、吞吐量、每token价格，以及各自的胜出场景。 6 个常见问题](https://servhidden.com/zh/guides/rtx-4090-vs-h100-for-ai-inference) [### 面向MT4 / MT5 / cTrader外汇交易的离岸Windows RDP 运营管理 完整指南：为何使用Windows RDP进行外汇交易、如何选择低延迟离岸司法管辖区、MT4 / MT5 / cTrader / Expert Advisor设置、到经纪商服务器的延迟，以及免KYC结账路径。 6 个常见问题](https://servhidden.com/zh/guides/offshore-windows-rdp-for-forex-trading) [### DMCA豁免托管详解：2026年的真实含义 购买前 "DMCA豁免"托管究竟能给你什么保障、哪些司法管辖区真正背书、哪类业务确实需要它——以及你必须了解的陷阱。 6 个常见问题](https://servhidden.com/zh/guides/dmca-ignored-hosting-explained) [### 加密货币匿名域名注册：2026年WHOIS隐私完全指南 隐私与支付 2026年实用指南：如何注册域名而不暴露身份——各TLD的WHOIS制度、注册商选择、代币支付方案，以及真正能在压力下成立的匿名堆栈。 6 个常见问题](https://servhidden.com/zh/guides/anonymous-domain-registration-with-crypto) [### 托管加密支付：Monero、Bitcoin 与 USDT 对比 隐私与支付 支付币种如何影响主机对你的了解程度。XMR、BTC 和 USDT 的隐私性、手续费、确认终局性和链上分析风险敞口——附清晰推荐。 6 个常见问题](https://servhidden.com/zh/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### 离岸主机真的匿名吗?诚实的答案 隐私与支付 离岸、无KYC主机去除了普通主机商收集的身份信息,但"匿名"与否还取决于支付方式、服务商的日志政策,以及您自身的操作安全(opsec)。以下是真正可被追踪的内容。 6 个常见问题](https://servhidden.com/zh/guides/is-offshore-hosting-truly-anonymous) [### VPS加固的第一个小时:清单 运营管理 一份具体、按顺序排列的清单,帮您在一小时内加固一台新VPS:SSH密钥、防火墙、fail2ban、自动更新,以及能阻止大多数机会主义攻击的攻击面缩减措施。 6 个常见问题](https://servhidden.com/zh/guides/first-hour-vps-hardening-checklist) [### 什么是 No-KYC 主机托管？定义、合法性与运作方式 隐私与支付 No-KYC 主机托管让您无需任何身份验证即可租用服务器——无需姓名、邮箱或证件。以下是其确切含义、技术原理、合法性说明，以及如何甄别真正的 No-KYC 服务商。 6 个常见问题](https://servhidden.com/zh/guides/what-is-no-kyc-hosting) [### 境外托管合法吗？2026年的诚实解答 购买前 境外托管对您和服务提供商而言都是合法的。本文将解释这一术语的真正含义、法律边界究竟在哪里、值得摒弃的误区，以及如何负责任地使用境外托管。 6 个常见问题](https://servhidden.com/zh/guides/is-offshore-hosting-legal) [### 如何使用 Monero（XMR）支付主机费用——分步指南 隐私与支付 使用 Monero（XMR）支付 VPS 或独立服务器费用的分步指南：为什么 XMR 是隐私性最强的支付方式、如何获取 XMR，以及从生成账单到服务器上线的完整结账流程。 6 个常见问题](https://servhidden.com/zh/guides/how-to-pay-for-hosting-with-monero) [### 如何匿名托管网站——2026年实用指南 隐私与支付 一份系统、分层的实用指南，教你如何在不暴露任何身份信息的前提下托管网站——涵盖账户注册、支付方式、域名选择、司法管辖、连接安全与内容管理，每一层逐一详解。 6 个常见问题](https://servhidden.com/zh/guides/how-to-host-a-website-anonymously) [### 如何在 VPS 上搭建 WireGuard VPN — 分步指南 运营管理 使用 WireGuard 在 VPS 上构建私有 VPN：为何自托管 VPN 优于商业服务、从安装到客户端连接的完整配置流程，以及安全加固方法。 6 个常见问题](https://servhidden.com/zh/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### 如何在 GPU 服务器上自托管 LLM — 2026 年完整指南 运营管理 在租用的 GPU 服务器上运行自己的大语言模型：为何自托管优于 API 调用、如何选择 GPU 与模型、使用 Ollama 或 vLLM 的部署方式，以及实际成本分析。 6 个常见问题](https://servhidden.com/zh/guides/self-host-an-llm-on-a-gpu-server) [### 防弹主机与离岸主机——两者有何区别？ 购买前 防弹主机与离岸主机常被混为一谈，但两者截然不同。本文厘清真正的区别、说明其重要性，并指出你实际需要的是哪一种。 6 个常见问题](https://servhidden.com/zh/guides/bulletproof-vs-offshore-hosting) [### 如何用 Bitcoin 购买 VPS — 分步详解（2026） 购买前 面向初学者的 Bitcoin 购买 VPS 全流程指南：获取 BTC、选择套餐、支付账单，以及你将得到什么——一台无需绑卡、无需实名的运行中服务器。 6 个常见问题](https://servhidden.com/zh/guides/how-to-buy-a-vps-with-bitcoin) [### 2026年最佳DMCA忽略托管国家 购买前 当您需要将服务器部署在美国式版权投诉难以触及的地方时，该如何选择：哪些司法管辖区真正有效，DMCA忽略托管究竟意味着什么，以及如何做出明智的选择。 6 个常见问题](https://servhidden.com/zh/guides/best-countries-for-dmca-ignored-hosting) [### 如何托管 Tor 隐藏服务（.onion 站点）—— 2026 年完整指南 运营管理 在 VPS 上搭建 Tor 洋葱服务：了解隐藏服务的概念、为何它是匿名托管的最强形式、完整配置流程，以及如何保持真正的匿名性。 6 个常见问题](https://servhidden.com/zh/guides/how-to-host-a-tor-hidden-service) [### 离岸邮件服务器搭建指南——2026年如何自托管私人电子邮件 运营管理 在离岸 VPS 上搭建属于自己的私人邮件服务器：为什么要自托管电子邮件、所需条件、使用一体化邮件系统的实际搭建流程，以及如何保证邮件送达率。 6 个常见问题](https://servhidden.com/zh/guides/offshore-mail-server-setup) [### 加密货币节点托管指南 — 在 VPS 上运行区块链节点 运营管理 如何在服务器上托管区块链节点：为何要运行自己的节点、如何为 Bitcoin、Ethereum、Monero 等链配置服务器规格、部署流程，以及如何保护节点隐私。 6 个常见问题](https://servhidden.com/zh/guides/crypto-node-hosting-guide) [### Stable Diffusion GPU托管 — 运行您自己的图像服务器 运营管理 在您自己的GPU服务器上运行Stable Diffusion：为何选择自托管图像生成、如何挑选GPU、配合Web界面的部署方法，以及与托管服务的费用对比。 6 个常见问题](https://servhidden.com/zh/guides/gpu-hosting-for-stable-diffusion) [### 服务器 OpSec — 运营匿名服务器时保持匿名 隐私与支付 为运营匿名服务器的用户提供的操作安全指南：揭露身份的常见错误、预防这些错误的习惯，以及如何将真实身份与匿名活动彻底隔离。 6 个常见问题](https://servhidden.com/zh/guides/server-opsec-staying-anonymous) [### Seedbox 搭建指南——2026年打造您的专属私人 Seedbox 运营管理 如何在服务器上搭建自己的 seedbox：什么是 seedbox、如何选配硬件、安装带有 Web 界面的 BitTorrent 客户端，以及如何保障私密性与安全性。 6 个常见问题](https://servhidden.com/zh/guides/seedbox-setup-guide) [### 如何用自己的 VPS 绕过 DPI 审查(2026 指南) 隐私与支付 VPN 突然失灵?如何用自己的 VPS 绕过 DPI 审查:深度包检测(DPI)究竟能识别出什么、2026 年仍然有效的五种协议各自能突破哪类封锁,以及一份完整的 VLESS+REALITY 部署演示。 6 个常见问题](https://servhidden.com/zh/guides/bypass-dpi-censorship-with-your-own-vps) [### VPS 全盘加密:LUKS 配置与它真正能防住什么 运营管理 如何用 LUKS 给 VPS 加密:日常数据适用的加密数据卷、配合 dropbear 远程解锁的全盘 root 加密,或安装时整机加密的裸机服务器,三种方案怎么选;小型 VPS 上 Argon2id 内存参数为何会让解锁失败;以及磁盘加密到底能防住哪些威胁、又对哪些威胁完全无效的坦率说明。 8 个常见问题](https://servhidden.com/zh/guides/full-disk-encryption-on-a-vps) [### 隐藏源站 IP:CDN、反向代理与仍会泄露的部分 隐私与支付 要不要在离岸服务器前面挂一个 CDN,是买下服务器后最先冒出来的问题:它到底能隐藏什么、你会因此继承来一个什么样的投诉窗口、源站 IP 依然会泄露的六种常见方式、如何锁死源站只让前端可达,以及如何用十分钟自查你自己的服务器有没有已经暴露。 8 个常见问题](https://servhidden.com/zh/guides/hiding-your-origin-server-ip) [### 自建 Matrix 服务器：联邦、元数据与端到端加密盲区 运营管理 自建 Matrix 服务器到底改变了什么：Synapse 与 Conduit 怎么选、永远无法更改的 server_name、吃满硬盘的媒体缓存，以及联邦协议依然会暴露哪些信息。 8 个常见问题](https://servhidden.com/zh/guides/self-host-a-matrix-server) [### 网站迁移离岸主机指南:零停机切换与痕迹清理 运营管理 让主机迁移变得平淡无奇的顺序:提前几天调低DNS TTL、新旧服务器并行运行、把写入冻结控制在几分钟而不是几小时——外加清理这次搬迁留下的被动DNS、Certificate Transparency和WHOIS痕迹。 8 个常见问题](https://servhidden.com/zh/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server 运营管理 Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8 个常见问题](https://servhidden.com/zh/guides/self-host-a-crypto-payment-gateway) ## 让今晚的备份有地方可以落脚 七个司法辖区,每个套餐都不限流量带宽,服务器最低$7.50/月起,足以撑起一个称职的restic或Borg端点。无需实名认证,无需邮箱,只收加密货币——备份目标和生产服务器,标准同样严格。 [查看VPS方案](https://servhidden.com/zh/vps) [独立服务器](https://servhidden.com/zh/dedicated) [所有位置](https://servhidden.com/zh/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "7 个隐私友好司法管辖区的离岸 VPS 和独立服务器。无KYC、无日志、仅加密货币支付。隐私即架构。", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "VPS备份完全指南:加密、异地存储与恢复测试", "description": "主机不提供任何备份,终止后24小时内数据即被清除。看清哪些操作真正会毁掉服务器、快照为何不是备份、restic与Borg怎么选,以及如何验证备份真能恢复。", "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-20T00:00:00+00:00", "dateModified": "2026-08-20T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy", "inLanguage": "zh", "keywords": "VPS备份, 服务器异地备份, VPS加密备份, restic对比BorgBackup, 3-2-1备份原则, 无实名VPS备份, 只追加写入备份, 备份恢复演练", "articleSection": "运营管理", "wordCount": 3039 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "ServHidden会帮我备份VPS吗?", "acceptedAnswer": { "@type": "Answer", "text": "不会,而且这是刻意为之,不是疏漏。我们的保留政策明确写着:不保留任何备份,服务器数据在终止后24小时内被销毁,硬盘经过加密擦除而非简单格式化。如果在你要求我们删除数据之后还保留一份副本,就违背了这个平台存在的初衷。任何你希望在服务器之外还能留存的东西,都必须由你自己复制出去,最好是复制到第二个司法辖区的另一个服务商那里。" } }, { "@type": "Question", "name": "快照和备份是一回事吗?", "acceptedAnswer": { "@type": "Answer", "text": "不是。快照和它所属的服务器共享所有故障域——同一个服务商、同一个账号、同一个国家,往往还是同一套存储。它非常擅长撤销一次搞砸了的升级,但对账号丢失、服务商出问题或整台机器没了这种情况完全无能为力。把快照当成撤销按钮,把备份当成保险,它们解决的是不同的问题,而你两个都需要。" } }, { "@type": "Question", "name": "restic和BorgBackup该选哪个?", "acceptedAnswer": { "@type": "Answer", "text": "如果目标可能是对象存储、SFTP,或者你还没决定用什么,就选restic,因为它支持的后端最多。如果目标是通过SSH连接的单台Linux机器,而且数据量大、重复度高,就选BorgBackup,因为它的去重能力是同类中最强的。两者都会在数据离开机器之前先在源端加密,也都支持只追加写入的目标,而这一点远比两者之间怎么选更重要。" } }, { "@type": "Question", "name": "如何防止攻击者删除我的备份?", "acceptedAnswer": { "@type": "Answer", "text": "要拿走能力,而不是指望消除动机。要么让目标只能追加写入,这样生产服务器上的凭证只能新增数据、永远无法删除;要么反转连接方向,让备份主机主动从生产环境拉取数据,使生产服务器根本不持有任何凭证。在正式发难之前先删除备份,是所有商业化攻击者的标准操作,一份攻击者能删除的副本根本不算第二份副本。" } }, { "@type": "Question", "name": "第二份副本应该放在哪里?", "acceptedAnswer": { "@type": "Answer", "text": "放在不同的服务商、不同的司法辖区,而且付款方式要和生产服务器一样私密。能同时摧毁两份副本的事件很少是物理层面的——通常是丢失访问权限的账号、状态不佳的服务商,或者一份能覆盖某个国家却管不到另一个国家的法律文件。同一机架里的两台服务器,不过是多绕了一圈的一份副本。由于工具在源端就完成了加密,第二台主机不需要是你信任的那种。" } }, { "@type": "Question", "name": "多久备份一次比较合适?", "acceptedAnswer": { "@type": "Answer", "text": "从你愿意重做多少工作量倒推。一个博客丢一天的内容可能没人会注意到,但一个商店丢一个小时的订单就不行。对大多数单服务器架构来说,每晚备份是合适的默认选择,如果写入的数据很宝贵,数据库转储可以更频繁。比频率更重要的是保留深度:损坏往往要几周后才被发现,所以历史记录要足够长,能回溯到问题发生之前。" } }, { "@type": "Question", "name": "备份放在我不掌控的服务器上加密安全吗?", "acceptedAnswer": { "@type": "Answer", "text": "就内容而言是安全的——restic和Borg在数据离开源端之前就完成了加密,所以目标端存储的是它无法解读的数据块,密钥也从未传输过去。目标端确实能了解一些元数据:大致的数据量、数据是如何变化的,以及你的任务什么时候运行。这通常是可以接受的。如果不能接受,就把计划错开一些,并把仓库放在一台归属关系和生产服务器无关联的机器上。" } }, { "@type": "Question", "name": "备份密码丢了怎么办?", "acceptedAnswer": { "@type": "Answer", "text": "归档就永久丢失了,没有任何人能帮你找回。这是整个主题里最常见的彻底丢失场景,也是唯一没有恢复路径的失败。把密码短语保存在所涉及的每一台机器之外,纸质记录确实胜过一个你也可能失去访问权限的账号里的密码管理器,并且给仓库再加一把密钥,这样忘记一个密码就只是麻烦,而不是整个归档的终结。" } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://servhidden.com/zh/" }, { "@type": "ListItem", "position": 2, "name": "隐私托管指南", "item": "https://servhidden.com/zh/guides" }, { "@type": "ListItem", "position": 3, "name": "VPS备份完全指南:加密、异地存储与恢复测试", "item": "https://servhidden.com/zh/guides/vps-backup-strategy" } ] } ```