Off-site backups: set up and restore

Off-site backups copy your server's whole disk once a day to object storage run by another company, encrypted before it leaves our host. If the server is broken, deleted by mistake or compromised, you can restore any of those copies to the same server or into a new one.

They are a paid add-on, priced per plan: by default 20% of the plan's monthly price, and 10 times that for a yearly term. The server's Backups tab, and the plans page while backups are on sale, show the exact price for each plan.

How they differ from snapshots#

Snapshots live on the same disks as the server. They are quick to take and revert, but they go away with the server and don't protect you from a failed host. Backups are kept elsewhere:

• Another provider. The copies sit in object storage outside our servers, so a lost host, a reinstall or a deleted server doesn't take them with it.
• No downtime. A running server keeps running while it is backed up: its writes go to a temporary layer that is merged back when the copy is done. A snapshot shuts the server down for about a minute; a backup doesn't.
• Crash-consistent. A backup is the disk as it was at one instant, like after a power cut. Journaling filesystems recover from that. For databases, also keep the database's own dumps (see Back up your server) or stop writes for the minute the backup starts if you need a clean copy.
• Encrypted and deduplicated. Each server's backups have their own encryption key, made when you turn backups on and never shown or sent anywhere but our hosts. After the first backup only the changed parts of the disk are stored, compressed.

Turn them on#

Open the server, go to Backups and choose turn on. An add-on invoice covers the rest of the current period, paid from your account credit first. Backups start as soon as it is paid, and the add-on renews with the server: monthly, or 10 times the monthly price on a yearly term.

You can also order a new server with backups already on (--backups with the CLI, addons.backups: 1 with the API).

When they run and how many are kept#

Backups run once a day at the hour you pick, in your time zone, starting within 30 minutes after it (servers on one host take turns, one backup at a time per host). Under Schedule and retention:

• Daily backups kept: the newest backup of each of the last 1 to 14 days (7 by default).
• Weekly backups kept: after those, the newest backup of each of 0 to 8 earlier weeks (4 by default).

The newest backup is always kept. Back up now takes one at once, up to 3 times a day; the daily one still runs.

While a backup runs, the server's other actions (reboot, resize and so on) wait for it, usually a few minutes. A suspended server, or one in rescue mode, is skipped that day. When a backup fails we tell you by email and in the panel's notifications, with the reason, and the page shows it:

Restore a backup to the same server#

This replaces the server's current disk. Next to a backup, choose restore… and type the server's hostname. The server is shut down, its disk is replaced by the backup, and it starts again. Everything written since that backup is lost. Restore time depends on the backup size and download speed; the server page shows that the restore is running until it finishes.

If the disk grew since the backup (extra NVMe), it keeps its size; grow the partition and filesystem as after a snapshot revert.

Restore into a new server#

Choose new server… next to a backup. The order form opens with a note saying which backup the new server will get. Pick a plan whose disk is at least as big as the backup's, pay, and once the server is built it is restored from the backup and started. The new server is billed like any other and gets its own addresses: update DNS and anything that points at the old one.

This works for backups of a deleted server too, while they are kept (below).

How we tested it#

On 31 October 2026 we backed up one of our own running servers on our New York hardware and restored it into a new server. The server kept running during the backup, which took about 9 minutes and stored 23.4 GB. The restore into the new server took about 25 minutes (about 17 MB/s from the storage provider), and the new server booted with the original's files and settings. That was one server, with one restore; a bigger disk takes longer, and a database's files in a backup are crash-consistent, as above, not a clean dump.

The CLI and the API#

rack4 backups web-1                 # the list, newest first
rack4 backups web-1 status          # schedule, last run, stored size
rack4 backups web-1 on              # turn on (an add-on invoice)
rack4 backups web-1 now             # back up now
rack4 backups web-1 schedule --at 2 --tz Europe/Amsterdam --daily 7 --weekly 4
rack4 backups web-1 restore bkp_q4m2x7abcdefgh3k
rack4 servers create --plan standard --image debian-12 --hostname web-2 --key key_m2q7x4abcdefgh2s --restore-from bkp_q4m2x7abcdefgh3k

The API has the same under /servers/:id/backups, and restoreFrom on POST /servers. Webhooks can subscribe to backup.failed and backup.restored (webhooks).

When backups end#

Turning backups off takes effect at the next renewal; until then they keep running. After the add-on ends, or after the server is deleted for good, its backups are kept for 14 days and then deleted for good. Turning backups on again within those 14 days keeps them.

While a deleted server is in the recycle bin, no backups run and the 14 days haven't started: they start when the bin is emptied. If you restore the server from the bin, its backups are still there; turn backups on again on its Backups tab to keep them and keep taking new ones.

What a backup can't do: it doesn't copy memory, and it isn't a replacement for keeping the data that matters most somewhere you control as well.