把 WordPress 备份到 Storage Server：WPvivid 实操指南

和网站放在同一台服务器上的备份，不算备份。硬盘被清空、访问权限被人接管或者整套安装被加密时，它也跟着一起没了。只有放在独立存储上的副本，才是真正的保险。

本指南演示通往那里最快的一条路：一个免费插件，通过 SFTP 把 WordPress 备份到 Storage Server 上，带计划任务和保留规则。配置完只需一刻钟。

为什么选 WPvivid

可选项在一个点上出乎意料地少。真正关键的，是免费版里就有加密传输：

普通 FTP 以不加密的方式传输凭据和内容。对于一份包含完整数据库连用户表的备份来说，这不是个好主意。于是 WPvivid 成了顺理成章的选择，它有超过 900,000 个活跃安装量，最近一次更新是 2026 年 9 月。

第 1 步：在存储上建一个子账户

请在客户中心您的 Storage Server 下面，为备份单独建一个子账户，起始目录设为 /backup/wordpress。这件事比听起来重要：凭据马上就会进到 WordPress 的数据库里，而在那里找到它们的人，除了这一个目录之外不应该还能碰到别的。

在同一步里，请在“访问设置”下检查两个开关：

• SSH / SFTP / SCP / rsync 必须已开放。
• 外部可访问性必须已开启，否则您的 Web 服务器无法通过互联网访问存储。

新订购的服务器上这两项都是开启的。请记下主机名和用户名，本文的示例使用：

第 2 步：在动手配置之前先检查连通性

这能省下后面很多排查功夫。如果您在 Web 服务器上有 Shell 访问权限：

timeout 5 bash -c '</dev/tcp/u123456.storage.kernelhost.net/23' && echo "23 端口可达"

没有 Shell 访问权限时，请在网站目录里放一个文件 pruefen.php，调用一次，之后再把它删掉：

<?php
$f = @fsockopen('u123456.storage.kernelhost.net', 23, $e, $t, 5);
echo $f ? '23 端口可达' : '无法连接：' . $t;

如果连接建立不起来，说明您的主机商封禁了这个端口上的出站连接。在共享主机上这种情况并不少见。那就只剩两条路：问主机商，或者走 WebDAV，它运行在 443 端口上。

第 3 步：安装插件并填写目标

在 WordPress 后台的“插件”、“安装插件”里搜索 WPvivid Backup & Migration，安装并启用。之后左侧会出现菜单项 WPvivid Backup。

在那里切到 Remote Storage 选项卡，并选择 SFTP。各字段这样填：

点 Test and Add，插件会先测试连接再保存。如果测试失败，十次里有九次是端口填错了，或者外部可访问性被关掉了。

第 4 步：手动跑第一次备份

在 Backup & Restore 选项卡上选择 Database + Files (WordPress Files)，目标选 Send backup to remote storage 并指向刚刚建好的那个条目。然后点 Backup Now。

第一次运行按体积大小需要几分钟。期间请让浏览器窗口保持打开，插件是通过反复发起请求来推进进度的。

第 5 步：计划任务与保留份数

在 Schedule 选项卡上启用计划任务。经验证好用的是：

把时间放在主要访客的深夜时段。保留份数在 Settings 里设置，那里还有一个开关，决定远程存储上的旧备份是否一并删除。请把它打开，否则存储迟早会被塞满。

请注意：Storage Server 的快照是额外的一层，和这些设置各自独立工作。按套餐可用 10、20、30 或 40 个手动快照，另外还有同样数量的自动快照。

第 6 步：检查备份到底有没有用

这一步被跳过的次数最多，却是最重要的。看一眼存储上实际放了什么：

sftp -P 23 u123456-sub3@u123456.storage.kernelhost.net
sftp> ls -l
sftp> bye

注意两件事：文件大小必须说得通，而且数据库归档和文件归档都得在。只有几 KB 的归档是失败，不是成功。

然后才是真正的测试：把这份备份在一个测试环境里完整恢复一次。从未验证过的备份只是一种猜测。

恢复，以及那个小障碍

在免费版里，放在远程存储上的备份没法直接回灌，恢复远程备份属于付费版的功能。免费的路子依然走得通，只是多花几分钟：

1. 用 SFTP 把归档从存储上下载下来。
2. 在插件的 Backup & Restore 里打开 Upload 区域，上传这个归档。
3. 上传好的备份会出现在列表中，从那里就能恢复。

请把这段弯路算进您的应急计划里。真出事时才第一次发现中间还夹着一次下载的人，会白白损失时间。

这条路的尽头在哪里

每个备份插件都在 PHP 里面干活，因此会撞上时间和内存限制。总体积到了几个 GB 以上就会变得吃力，而媒体库非常大时，备份跑到某个点就会中断。

这时更好的方式是 rsync 或 BorgBackup，两者都直接从服务器上的计划任务里跑，而且在存储上都原生可用：

rsync -az --delete -e "ssh -p 23" \
      /var/www/example.com/ \
      u123456-sub3@u123456.storage.kernelhost.net:/dateien/

这样只传输变化的部分，也不受 PHP 的限制。不过前提是您有一台带 Shell 访问权限的自有服务器。关于这条路的更多内容见 把 Storage Server 用在自己的网站上。

WordPress 的哪些其他部分可以搬到存储上，也就是媒体库和下载文件，以及其中的边界在哪里，见 把 Storage Server 用在 WordPress 上。

最常见的四个错误

• 填了 22 而不是 23。插件建议 22，我们的存储监听的是 23。
• 外部可访问性被关掉了。这时从客户中心测试是通的，但从 Web 服务器上就不通。
• 用了主账户而不是子账户。凭据之后就躺在网站的数据库里。用主账户的话，所有东西都挂在上面。
• 旧备份从来不删。没有为远程存储打开保留规则，空间就会被填满，到某个时候备份会悄无声息地失败。

哪个套餐合适

给单个 WordPress 网站做备份，1 TB、9.99 欧元的 Storage-1 能用很久。给个参照：一个总体积 5 GB 的中型网站，保留十份备份大约占 50 GB，也就是套餐的百分之五。

所有 Storage Server 都在德国，最多可建 100 个子账户，除了 SFTP 还支持 SMB、WebDAV、rsync 和 BorgBackup，并且免安装费。按预付方式结算，没有最低合约期，所以您可以先小规模起步，等网站多起来再扩容。