WordPress backups on the Storage Server: a guide with WPvivid

A backup that sits on the same server as the website is not a backup. If the disk gets wiped, the access taken over or the installation encrypted, the backup is gone with it. Only a copy on separate storage is real insurance.

This guide shows the fastest way to get there: a free plugin that backs up WordPress over SFTP to a Storage Server, with a schedule and a retention rule. Setting it up takes fifteen minutes.

Why WPvivid

The field is surprisingly small in one respect. The point that counts is an encrypted transfer in the free edition:

Plain FTP transfers credentials and contents unencrypted. For a backup that contains the complete database including the user table, that is not a good idea. WPvivid is therefore the obvious choice: it has more than 900,000 active installations and was last updated in September 2026.

Step 1: create a subaccount on the storage

In the customer panel, under your Storage Server, create a subaccount of its own for the backups, with the home directory /backup/wordpress. That matters more than it sounds: the credentials are about to land in the WordPress database, and anybody who finds them there should be able to reach nothing but this one directory.

In the same step, check two toggles under "Access Settings":

• SSH / SFTP / SCP / rsync has to be enabled.
• External Reachability has to be switched on, otherwise your web server cannot reach the storage over the internet.

On newly ordered servers, both are active. Make a note of the hostname and the username. The examples here use:

Step 2: check reachability before you set anything up

This saves a lot of hunting later on. If you have shell access on the web server:

timeout 5 bash -c '</dev/tcp/u123456.storage.kernelhost.net/23' && echo "Port 23 reachable"

Without shell access, put a file pruefen.php into the web directory, call it once and delete it afterward:

<?php
$f = @fsockopen('u123456.storage.kernelhost.net', 23, $e, $t, 5);
echo $f ? 'Port 23 reachable' : 'no connection: ' . $t;

If no connection comes up, your host blocks outgoing connections on this port. On shared hosting that is not unusual. What is left is either a question to the host or the route over WebDAV, which runs on port 443.

Step 3: install the plugin and add the destination

In the WordPress admin area, under Plugins, Add New, search for WPvivid Backup & Migration, install it and activate it. The menu item WPvivid Backup then appears on the left.

There, open the Remote Storage tab and pick SFTP. Fill in the fields like this:

With Test and Add, the plugin checks the connection before it saves it. If that fails, in nine out of ten cases either the port is wrong or external reachability is switched off.

Step 4: the first backup by hand

On the Backup & Restore tab you choose Database + Files (WordPress Files) and, as the destination, Send backup to remote storage with the entry you just created. Then Backup Now.

The first run takes a few minutes depending on the size. Leave the browser window open while it runs, because the plugin drives the progress through repeated requests.

Step 5: schedule and retention

On the Schedule tab you switch the schedule on. What has proven itself:

Put the time into the night hours of your main audience. You set the retention under Settings, where you also find the toggle for whether old backups on the remote storage are deleted as well. Switch it on, otherwise the storage fills up over time.

Keep in mind: the snapshots of the Storage Server are an additional layer and work independently of this. Depending on the plan, 10, 20, 30 or 40 manual snapshots are available, plus the same number of automatic ones.

Step 6: check whether the backup is any good

This step gets skipped most often and it is the most important one. Take a look at what is actually on the storage:

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

Watch for two things: the file size has to be plausible, and both a database archive and a file archive have to be there. An archive of a few kilobytes is a failure, not a success.

And then the real test: restore the backup once onto a test installation. A backup that has never been tested is a guess.

Restoring, and the catch

In the free edition, a backup that sits on the remote storage cannot be restored directly, because restoring remote backups is part of the paid version. The free route still works and takes only a few minutes longer:

1. Download the archive from the storage over SFTP.
2. In the plugin, open the Upload area under Backup & Restore and upload the archive.
3. The uploaded backup appears in the list and can be restored from there.

Factor this detour into your emergency plan. Noticing for the first time in a real incident that a download stands in the way costs time you do not need to lose.

Where this route ends

Every backup plugin works inside PHP and therefore runs into time and memory limits. Past a total size of a few gigabytes it gets sluggish, and with very large media libraries the run breaks off at some point.

The better route is then rsync or BorgBackup, both straight from a schedule on the server and both available natively on the storage:

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

This transfers only the changes and knows no PHP limits. It does require your own server with shell access. More about this route is in Using a Storage Server for your own website.

Which other parts of WordPress can be moved onto the storage, meaning the media library and downloads, and where the limits are, is covered in Using a Storage Server with WordPress.

The four most common mistakes

• Port 22 instead of 23. The plugin suggests 22, our storage listens on 23.
• External reachability switched off. The test from the customer panel then works, but not the one from the web server.
• The main account instead of a subaccount. The credentials end up in the database of the website afterward. With the main account, everything hangs on them.
• Old backups are never deleted. Without the retention rule enabled for the remote storage, the space fills up, and at some point the backup fails silently.

Which plan fits

For the backups of a single WordPress site, Storage-1 with 1 TB for 9.99 EUR lasts a very long time. For scale: a mid-sized site with a total size of 5 GB takes up around 50 GB with ten backups kept, which is five percent of the plan.

All Storage Servers are located in Germany, allow up to 100 subaccounts, speak SMB, WebDAV, rsync and BorgBackup alongside SFTP and come with no setup fee. Billing is PrePaid with no minimum term, so you can start small and grow when more sites come along.