VPS Snaps

Recovering a lost server: recovery servers, standby and failover

Build a replacement server from your backups, keep one ready, or have traffic moved to it automatically.

Each server can have a recovery plan, on its page under Recovery. It needs a DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine connection: recovery servers are created on your account and billed to it while they exist. The plan picks the account the server is on when one of yours has it.

What a recovery server holds

  • From a snapshot, when the server has a snapshot job on the same account: the whole machine as it was when the snapshot was taken.
  • From backups otherwise: a fresh Ubuntu server with the database engines and Docker installed, each database created with the same name, user and password as before, and the newest backup of each of the server's database, file and Docker jobs restored onto it. A file backup of /etc comes back too, but the new server keeps what makes it itself — its disks, network, name, host keys and system accounts — and root's keys from the backup are added to its own.
  • A recovery from backups also brings back the server's software, once it has been recorded: with a recovery plan saved, each backup of the server records the packages its admin installed, its services and accounts, and its web server, PHP, TLS certificate, cron and systemd configuration (kept in your own storage, at most twice a day). The recovery installs the same — from Ubuntu, and from the repositories the server had added (a PPA, NodeSource, Docker's), moved to the new server's Ubuntu release — puts the configuration back and starts the services. What it could not do — a repository that no longer answers, a newer PHP — is listed on the page.
  • Its data is as old as the oldest backup it was built from. The page says how old before you build anything.

On demand

Save the plan, then press Recover now. You get the new server's address when it is ready, and point your domain at it — or, with a reserved or floating IP, or your DNS on a connected Cloudflare account, press Switch traffic here.

Warm standby

Keeps a recovery server built and ready, and rebuilds it from newer backups at most as often as you set. The new one is ready before the old one is destroyed. It runs all the time, so it costs what a server of its size costs.

Automatic failover

Checks the server every minute: its SSH port, and a health URL if you give one. When they fail, it asks from inside your account too — the warm standby if you keep one, otherwise a small probe machine it starts beside the server for the outage (a few cents on your bill, removed afterwards) — and an outage counts only if that cannot reach the server either. When both have failed for as long as you choose, while our own connection is working, it moves the server's reserved IP (a floating IP on Hetzner, an Elastic IP on AWS EC2, a static public IP on Azure, the server's own IP on Linode) — or points the DNS records you chose on Cloudflare at it — to the standby, or to a recovery server it builds. It can tell you first and wait for you to stop it.

Failover moves a reserved IP (DigitalOcean, Vultr), a floating IP (Hetzner), an Elastic IP (AWS EC2), a static public IP (Azure) or a static external IP (Google Compute Engine), so create one, assign it to the server and point your domain at it before switching failover on. On Google Compute Engine, reserve the address the instance already has as static (VPC network → IP addresses → Reserve): it stays the same, so your domain needs no change, and the recovery server is built in a zone of the same region. On Azure and Google Compute Engine the recovery server takes the IP in place of its own address. On Linode it is the server's own IP, swapped with the recovery server's, which then restarts to take it (about a minute); a Linode connection made before 27 September 2026 needs reconnecting to allow it. On Hetzner and Vultr the server must also be configured to answer on the IP: a recovery server built from backups is configured for you, and one built from a snapshot keeps whatever the old server had. On AWS Lightsail, and on any cloud without a movable IP, move traffic by DNS instead: connect the Cloudflare account your domain is on (Providers → Cloudflare), and choose the A records pointing at the server in its recovery plan. When traffic is switched those records point at the recovery server — proxied ones at once, DNS-only ones as caches expire — and nothing else in the zone is touched. AAAA (IPv6) records are not moved.

Failover moves your traffic to data as old as the last backup: anything written to the old server after that is not there. If the old server was not really down, both could take writes. It never switches back on its own, and stays off until you re-arm it.

Plans

Recovery servers are on the Standard, Pro and Agency plans. The warm standby and automatic failover are on Pro and Agency.

Still stuck?

Open the failed run under Backup History and copy the error text out of the log — pasting that into your first message is usually the difference between one reply and four.