"What if my server dies" gets asked as if it's one question with one answer, and that's the first thing worth fixing. A dead disk and a compromised box both end with the same sentence — the VPS is gone — but they don't call for the same response, and treating them identically means either overreacting to a routine outage or, worse, underreacting to a breach because it superficially looks like ordinary hardware failure. This is the plan, broken out by which of five things actually happened, written down now so it's a checklist during an incident instead of a debate. This is a plan, not a story about something that already happened to me — every scenario below is written as "here's what I'd do," because the value of having it is that it's decided before the fact, not narrated after it.
Scenario one: the provider is having an outage
This is the least dramatic scenario and the one people most often overreact to. A hosting provider's own infrastructure — the hypervisor layer, a network segment, a datacenter — has a problem, and your VPS is unreachable as a result, but nothing about your own data or configuration was touched. The plan here is boring on purpose: check the provider's status page, confirm other users are reporting the same thing, and wait, rather than jumping straight into a from-scratch rebuild that solves a problem you don't actually have. Rebuilding onto new infrastructure while the original provider's outage is still in progress can leave you running two versions of the same app in two places once the original comes back, which is its own kind of mess. For the operations playbook that sits alongside what happens if your VPS dies? my disaster recovery plan, see XenGrowth's revenue operations work.
The one preparation this scenario needs in advance is a status page you actually check, and a communication plan for your own users if downtime stretches past what your SLA (formal or implied) tolerates. Nothing about the server itself needs to change. The one exception worth naming: if an outage stretches on long enough that it starts looking indistinguishable from a genuine loss — hours turning into a day with no provider update at all — that's the point to start treating it as scenario two below and prepare a real restore, rather than waiting indefinitely on a status page that's stopped updating.
Scenario two: the disk actually failed
This one is permanent, and the plan is a genuine restore, not a wait. The important thing this scenario has going for it: the failure was mechanical or storage-layer, not an attack, so there's no reason to distrust your last good backup. Provision a fresh VPS, restore the platform layer, restore Docker volumes, restore the database from the most recent verified dump, re-point DNS if the IP changed, and verify the app actually works before calling it done. None of that is complicated in principle — it's exactly why a tested restore procedure, rehearsed before this day, is worth more here than any amount of general disaster-recovery reading. On the operations side of this specifically, The XenGrowth resource library is worth reading.
What determines how bad this is isn't the failure itself, it's your RPO: how much happened between your last backup and the failure. That's a number you should have decided on deliberately as part of your backup strategy, not one you discover for the first time while staring at how old the last dump is. Disk failure also has a quieter cousin worth naming here: a slow, partial degradation rather than a sudden stop — a drive throwing intermittent read errors, latency creeping up over days before it finally gives out entirely. If your monitoring surfaces disk health at all, that's the signal to start this restore process proactively, on your own schedule, rather than waiting for the drive to make the decision for you at a worse moment.
Scenario three: someone (possibly you) deleted the wrong thing
Mechanically, the fix is the same restore as a disk failure. The part that's different, and that people rush past, is figuring out exactly what was deleted and exactly when, before restoring anything. Restore from a point before the deletion and you're fine. Restore from a point after it, because you grabbed the most recent backup out of habit without checking whether the deletion had already been captured into it, and you've just restored the same mistake. This scenario is the one where taking five extra minutes to confirm the timeline before touching anything actually saves time overall, not costs it. It's also the scenario most likely to repeat if the underlying cause — a destructive migration with no confirmation step, an overly broad delete query, a script with too much access — isn't fixed afterward, not just recovered from.
Scenario | Are your backups still trustworthy? | What the plan requires |
|---|---|---|
Provider outage | Yes — nothing touched them | Wait, monitor, communicate — don't rebuild prematurely |
Disk failure | Yes — mechanical failure, not an attack | Restore onto new hardware from the most recent verified backup |
Accidental deletion | Yes, but pick the restore point carefully | Confirm what and when before restoring, then restore to before the mistake |
Compromised server | No — assume tampered until proven otherwise | Full rebuild on new infrastructure, all credentials rotated, backups audited before trusted |
Account suspension | Only if stored independently of the suspended account | Depends entirely on whether your offsite copy lives outside that provider relationship |
Scenario four: the server was compromised
This is the scenario that changes the shape of the whole plan, not just the steps inside it. Once a server is compromised, nothing on it can be trusted — not the application, not the OS, not necessarily even backups produced after the point of compromise, because an attacker with enough access can plant something in a backup just as easily as anywhere else. The plan here is not 'clean up the old box.' It's provision new infrastructure entirely, rebuild from source and from a backup taken before the compromise (which is exactly why knowing roughly when a compromise started matters), rotate every credential the old server ever held — database passwords, API keys, SSH keys, anything — and only then bring the rebuilt stack online. On AI agents and marketing automation specifically, XenGrowth on governed AI marketing workflows is worth reading.
A disk failure destroys data. A compromise poisons trust. The recovery for the first is a restore. The recovery for the second starts with assuming everything on the old box, including its own backups from after the breach, might be lying to you.
Assume the old server and any credentials it held are burned — don't reuse them, don't reconnect to them for 'just one quick check' before isolating.
Identify, as closely as you can, when the compromise likely began, so you restore from a backup taken before that point rather than one that might already be compromised.
Provision genuinely new infrastructure — a new VPS, not a reformat of the old one, since a sufficiently deep compromise can survive a naive wipe.
Rebuild the platform and application from source, restore data from the pre-compromise backup, and rotate every credential and secret the old box ever had access to before it goes back online.
Only after the rebuilt server is live and verified, investigate the old one for how the compromise happened, so the same door doesn't stay open on the new box.
The instinct to move fast here works against you. A compromise is the one scenario in this whole list where speed is not the priority — figuring out the actual entry point, even approximately, before rebuilding is what prevents the exact same rebuild from being compromised again within days. A server hardened the same way the old one was, with the same open door nobody found, is not actually recovered.
Scenario five: your account got suspended
This is the scenario people plan for least, because it doesn't feel like a technical failure at all — the server might be running perfectly, but you can no longer reach it, manage it, or in some cases even confirm it still exists, because the provider account that controls it has been suspended for a billing dispute, a terms violation, or an automated fraud flag that has nothing to do with reality. If your only backup lives inside that same provider's ecosystem — snapshots tied to the same account, a bucket under the same login — you may have just lost access to your recovery path at the exact moment you need it most.
This is precisely the argument for the 'offsite, independent copy' half of 3-2-1 backup, and it's worth restating here because this scenario is the one that actually tests it: an offsite backup that's independent in name but still authenticated through the same suspended account isn't independent at all. A genuinely separate destination, under separate credentials, is the only version of this backup that survives a suspension of the account it's meant to be independent from. Worth planning for separately: appealing a suspension takes time you don't control, and some providers respond in hours while others take days or longer. The plan can't assume the appeal resolves quickly — if your business genuinely can't tolerate that server being unreachable for an unknown stretch, the honest answer is treating this scenario the same as a full rebuild on new infrastructure, using the independent offsite backup, rather than waiting on a support queue you have no visibility into. There is a longer treatment of AI search, GEO and discovery in XenGrowth on building one SEO and GEO content system.
What to have in place before any of this happens | Which scenarios it actually saves you in |
|---|---|
An offsite backup under separate credentials from your VPS provider account | Account suspension, disk failure, accidental deletion — everything except a compromise that predates the backup |
A written, rehearsed restore procedure | Every scenario — this is what turns a plan into something you can execute under pressure |
A rough timeline sense of when a compromise could have started (audit logs, deploy history) | Compromised server — without this you can't pick a trustworthy restore point |
Credentials and secrets stored somewhere independent of the server itself | Compromised server, disk failure — you need to rotate or restore access without the old box |
A status-page and monitoring habit for your provider | Provider outage — mostly so you don't rebuild prematurely |
What all five scenarios actually have in common
Every one of these plans assumes two things were already true before the incident: a tested, offsite, independently-authenticated backup exists, and someone knows the exact sequence of steps to restore from it without inventing the procedure under pressure. Neither of those is a plan you write during the incident — they're decisions made in advance, exactly like an RPO and RTO you've actually written down rather than discovered by accident. The specific mechanics of restoring — what order to bring services back in, what actually determines how long it takes, and the one setting that's easy to forget until it costs you an afternoon — deserve their own full walkthrough rather than a summary tacked onto the end of this one.
None of this replaces hardening the server in the first place. A compromise scenario you never have is better than a compromise scenario you recover from well, and the baseline security work — SSH configuration, firewall rules, what's actually exposed to the internet — is worth doing before any of the five scenarios above becomes the one you're living through. Revisit this plan itself on a schedule, not just once when it's written. What's running on the server changes, the backup destination and credentials change, and a disaster recovery plan describing a stack from a year ago is a plan for a server that no longer exists.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
Working on what happens if your VPS dies? my disaster recovery plan inside a commercial team? XenGrowth's operator guides publishes operator guides on the revenue side of this work.
Four questions about consequences rather than technology. Recovery planning is mostly deciding how much you're willing to lose, and then buying exactly that.
