VPS Disaster Recovery: A Small Business Checklist

Your shop, booking system or automation runs on one VPS, and one morning it's gone: a failed disk, a deleted server, an attacker or an expired domain. You have backups, but their password sits on that server, the DNS account sends its reset link to a mailbox on that server, and the rebuild steps live in one person's head. A disaster recovery plan closes those gaps in advance. Here's one for a small business, up to the first hour of an outage.

Quick answer: For each service, write down how much recent data you can lose and how long you can be down; those numbers set your backup schedule and rebuild method. Keep three copies on two systems, one off-site and one the VPS can't delete. Keep the runbook, your secrets and 2FA recovery codes in a password manager a second person can open, plus one offline copy. Check that you can reach hosting, registrar and DNS without the server, keep a contact list, rehearse, and follow a fixed order in the first hour.

1. Set Recovery Targets in Plain Words

NIST's contingency planning guide, SP 800-34, defines the recovery point objective as "the point in time to which data must be recovered after an outage" and the recovery time objective as how long a system can stay in recovery before the business suffers. In plain words: how much recent data you can lose, and how long you can be down. Set both per service:

Your real data-loss window is the age of the newest copy that has left the server, because local dumps die with it. With dumps at 03:30 and an off-site copy at 04:30, a server lost at 04:15 loses 24 hours and 45 minutes of data. Too much? Copy more often, or use point-in-time recovery, which takes more work: PostgreSQL's continuous archiving can restore a database "to its state at any time since your base backup was taken", and MariaDB's binary log does the same job.

For downtime, add up the time your last restore drill took, the time to get a new server (ask your provider) and the DNS change. If the total is longer than you can be down, you need a faster method, such as a second server kept ready, not a better backup.

2. Keep Copies by the 3-2-1 Idea

The UK's National Cyber Security Centre sums up 3-2-1 as "at least 3 copies, on 2 devices, and 1 offsite" (NCSC). On a VPS, that's the live data, dumps in /var/backups that undo mistakes but share the disk's fate, and an encrypted copy at another provider or in another building, such as the restic repository from our off-site backup guide.

Keep one copy out of the server's reach, too, because an attacker with root can use your backup job's login to delete the rest. In the NCSC's words: "With at least one backup offline at any given time, an incident cannot affect all of your backups simultaneously." Let a backup machine pull from the VPS, so the VPS holds no login to the copies, or run restic's rest-server with --append-only, which "allows creation of new backups but prevents deletion and modification of existing backups".

3. Write Down How to Rebuild

Our reinstall checklist collects the inventory with a few commands: ports, services, timers, packages, users, crontabs and where your .env files are. Add what commands can't see: which server runs what, with its OS release, IP addresses and plan; the restore order (database, app, then DNS); and every outside service that knows your server's IP, such as payment webhooks, a mail relay or an API allowlist. A new server usually gets a new IP; our migration plan covers the updates.

Then run a restore drill and turn the commands that worked into the runbook, using the template in our drill guide. NIST says a copy of the plan "should also be stored at the alternate site and with the backup media". For you, that's the password manager or a private repository, plus a printed first page.

4. Check That You Can Reach Every Account

List the accounts a rebuild needs: hosting client area, registrar, DNS, email, code hosting, backup storage and payments. For each, check:

• The login email. Resets sent to a mailbox on the lost server lock you out. Use a separate mail provider.
• Recovery codes. Store 2FA backup codes in the password manager. Cloudflare offers them when you set up 2FA, and "each backup code is one-time use only" (Cloudflare).
• A second person. Add a second admin wherever you can.

The domain. For .com and other generic domains, ICANN's expired registration policy has registrars send reminders about a month and a week before expiry, and once within five days after it. They usually go to the registrant by email, so keep that address current and turn on auto-renewal. Before an expired domain is deleted, the registrar interrupts its DNS: your site goes dark while the server runs fine.

The DNS zone. Cloudflare's DNS Records page exports a zone file under Import and Export, with proxied records marked cf-proxied:true (Cloudflare). Elsewhere, save the answers with dig (package bind9-dnsutils), and add other names, such as mail, the way the second line adds www:

for t in A AAAA MX TXT NS CAA; do dig +noall +answer example.com "$t"; done > dns-example.com.txt
dig +noall +answer www.example.com >> dns-example.com.txt

Check your TTLs now; you can't lower them mid-disaster. The TTL "controls how long each record is cached", and Cloudflare's TTL page allows 1 minute (30 seconds on Enterprise) to a day for DNS-only records and fixes proxied ones at 300 seconds. Our website move guide shows how to read the real value.

5. Keep Secrets Where a Dead Server Can't Take Them

The password manager holds whatever opens the backup or can't be recreated: the backup password (restic warns that "Losing your password means that your data is irrecoverably lost", restic docs), logins and API tokens, app encryption keys from .env files, 2FA codes, and the IDs and addresses in the runbook. Without n8n's key, for example, a restored instance can't decrypt its credentials, as our n8n guide shows. SSH keys and TLS certificates can be made again.

Then make sure the vault isn't a single point of failure. Bitwarden's emergency access, on paid plans, lets "trusted emergency contacts" request access, granted when you approve or when a wait time you set runs out. 1Password's Emergency Kit is a PDF with your sign-in address, email and Secret Key, made to print and store safely. Test the way in once from a device that has never logged in.

6. Keep a Contact List

NIST's guide says contact lists need more frequent reviews than the rest of the plan, and that a call tree "should account for primary and alternate contact methods". A small table does it:

Note when each one is reachable. On a self-managed VPS such as Space-Node's, you run the software, so the rebuild is yours; human support answers by live chat, Discord and email from 08:00 to 20:00 UTC. Plan for outages outside those hours.

Holding customer data? Add your data protection authority. The European Data Protection Board counts an "accidental or unauthorised loss of access to, or destruction of, personal data" as an availability breach, and repeats the GDPR rule that a breach is notified "without undue delay and, where feasible, not later than after 72 hours" (EDPB). In its ransomware example with a working backup and no data taken, no notification was needed, but "as all data breaches, it should be documented".

7. Rehearse With a Drill and a Tabletop Session

A restore drill tests the technical side, as our drill guide shows. A tabletop exercise tests the people: "a facilitator initiates the discussion by presenting a scenario and asking questions based on the scenario", in NIST's words. Take an hour at a table and one scenario per session:

• The domain stopped resolving on a Friday evening.
• There's a ransom note in your web root, and the person with the backup password is on a plane.

Ask who notices, who decides, which login you need and where it is, and what you tell customers. Every "we'd have to look that up" goes on a fix list. NIST says to review the plan "at least annually" and after significant changes, such as a new app or someone leaving, whose access you then remove.

8. The First Hour of an Outage

Minutes 0 to 10: find the layer. Start a log with UTC times, then run these from your own computer (Linux, macOS or WSL) or the backup machine, not from the server:

curl -sS -o /dev/null -w '%{http_code}\n' -m 15 https://example.com/
dig +short example.com A
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
ssh -o ConnectTimeout=10 admin@203.0.113.10 uptime

• curl: (6) Could not resolve host or no dig answer: DNS or the domain. Check the registrar and the DNS provider.
• dig shows a wrong IP: DNS was changed or points at an old server. Behind Cloudflare's proxy you see Cloudflare's addresses and certificate, so check the dashboard.
• curl: (60) SSL certificate problem: certificate has expired and a past notAfter= date: renew it. Let's Encrypt has ended its expiry emails, so watch expiry yourself.
• curl: (28) and ssh times out: the server or its network. Check the client area and your provider's status page, then contact support.
• ssh prints the uptime but curl shows a 5xx code: your software failed. A short uptime means the server rebooted.

If you can log in:

systemctl is-system-running
systemctl --failed
df -h /
free -h
sudo journalctl -p err -b --no-pager -n 50

degraded means a unit failed, and --failed names it. Look for a full disk or almost no available memory, then at the errors since boot. Our guides to Cloudflare error 521, nginx 502 and when to upgrade go further.

Minutes 10 to 30: protect and report. No reinstall, no restore over the only copy, no deleting unknown files to free space. After a break-in, copy the logs off first, change passwords from a clean device, and read the break-in section of our reinstall checklist before restoring. Send support your service ID, server IP, start time and the output above. Tell users on a channel that doesn't run on the broken server: a status page hosted elsewhere (Uptime Kuma can serve several), social accounts or a mailing list at another provider. Say what's affected and when the next update comes.

Minutes 30 to 60: set the decision time. Your downtime target, minus the drill time, the time to get a server and the DNS TTL, is the latest moment to start rebuilding; log it. With six hours, a two-and-a-half-hour drill, half an hour for a server and a five-minute TTL, start rebuilding by 2 hours and 55 minutes in, unless support has a firm answer. You can stop a rebuild if the old server returns, but you can't win back hours spent waiting.

Afterwards, NIST advises a full backup "as soon as reasonable following reconstitution". Take one, note what went wrong, and update the plan.

If It Still Fails

• The backup password fails. Try every copy: vault, offline kit, second person. Failing that, use any other copy: dumps on a surviving server, a developer's laptop, provider exports.
• You're locked out of an account. Use the recovery codes, or start the provider's account recovery at once, because identity checks take time.
• The domain expired. Renew it at the registrar; the ICANN policy lets you renew while its DNS is interrupted. After deletion, most generic domains still have a 30-day Redemption Grace Period.
• The newest backup is old. Restore it to get running, rebuild the gap from order emails or provider exports, and find out why the backups stopped.

FAQ

Do I need a plan for one small VPS? Yes, but two pages will do: the targets, where the copies are, how to reach every account, who to call and the runbook, each tested without the server.

Are provider snapshots enough? No. They're good for rolling back an update, but they often sit on the server's own storage system, as our snapshot guide explains, and in the same account, so one incident can take both. They don't count as off-site.

How often should I test and update the plan? NIST says to review it at least annually and after significant changes, and the contact list more often. Add restore drills a few times a year and a tabletop session once or twice a year.

Are backups included with a Space-Node VPS? Not in the plan price; you can arrange them through a support ticket. Ask how a restore works and how far back the copies go, and write the answers into your plan.

Sources

All opened on 31 October 2026:

• NIST: SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, glossary entries recovery point objective, recovery time objective and tabletop exercise
• UK National Cyber Security Centre: Offline backups in an online world
• restic: Preparing a new repository, rest-server
• Databases: PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery, MariaDB: Binary Log
• Domains and DNS: ICANN Expired Registration Recovery Policy, Cloudflare: Import and export records, Time to Live (TTL), Proxy status, Two-factor authentication
• Password managers: Bitwarden emergency access, 1Password Emergency Kit
• Data protection: EDPB Guidelines 01/2021 on Examples regarding Personal Data Breach Notification
• Certificates and status pages: Let's Encrypt Expiration Emails and Ending Support for Expiration Notification Emails, Uptime Kuma
• Commands: curl man page; Debian 12 man pages dig(1), ssh(1), ssh_config(5), openssl-s_client(1ssl), openssl-x509(1ssl), systemctl(1), journalctl(1), df(1), free(1), uptime(1); bind9-dnsutils file lists for Debian 12 and Ubuntu 24.04