Disaster recovery planning

A recovery plan that checks itself

Most recovery plans are written once and wrong by the next quarter. This one is built from your backups, checked against real restores, and signed off every year.

How a plan is built

Four steps, most of them already done by what VPS Snaps knows about your servers.

Step 1
List what has to come back
One click lists everything VPS Snaps already sees: servers, applications, managed databases, clusters, DNS zones, WordPress sites. Add anything it can't see, such as a payment provider.
Step 2
Set a target for each
Rank each system critical, important or standard, and set how much data you can afford to lose (recovery point) and how long it can be down (recovery time).
Step 3
See where reality falls short
Each target is checked against what your backups have actually done. Every gap says why, and links to the fix, or applies it in one click where that is safe.
Step 4
Sign it off, review it yearly
The plan becomes a document with your people, your procedures and the evidence. Signing it off freezes that version; you're reminded when the next review is due.

What every system is checked for

Readiness comes from what your backups have done, not from what the plan says. A system is ready, needs attention or is at risk.

Backed up

Every system has a backup job that is switched on, and an application has both its files and its database backed up.

Schedule and newest backup

The schedule backs up at least as often as the recovery point target, and the newest backup is within it right now.

Proven to restore

A restore, a test restore, a recovery server build or a recorded exercise within 90 days for a critical system, 180 for important, 365 for standard.

Restore time measured

How long recovery really took, from real restores, never estimated, and compared with the recovery time target.

A way back if the server is gone

A critical server has a recovery server set up, so a replacement can be built on your own cloud account.

Kept somewhere else, and alerting

A copy is kept with a different company from the one that runs the system, and every failed backup sends an alert.

Starting targets for each tier. Every system's targets are yours to change.
Tier	Recovery point	Recovery time	Proven within
Critical	1 hour	4 hours	90 days
Important	1 day	1 day	180 days
Standard	7 days	3 days	365 days

Evidence mapped to the controls auditors ask about

The plan document's appendix lists, for each control, which evidence the plan holds and what is still missing, with numbers.

SOC 2

A1.2 Backup processes and recovery infrastructure
A1.3 Testing recovery plan procedures
CC7.5 Recovering from identified security incidents
CC9.1 Mitigating risks from business disruption

ISO/IEC 27001:2022

5.29 Information security during disruption
5.30 ICT readiness for business continuity
8.13 Information backup
8.14 Redundancy of information processing facilities

HIPAA Security Rule

164.308(a)(7)(ii)(A) Data backup plan
164.308(a)(7)(ii)(B) Disaster recovery plan
164.308(a)(7)(ii)(C) Emergency mode operation plan
164.308(a)(7)(ii)(D) Testing and revision procedures
164.308(a)(7)(ii)(E) Applications and data criticality analysis

This plan records evidence that supports these controls. It is not a certification or an audit opinion. VPS Snaps does not hold a SOC 2, ISO 27001 or HIPAA certification, and does not sign Business Associate Agreements. Your auditor decides whether a control is met.

Where it stops

Said plainly, because a recovery plan is the wrong place for a surprise.

It records evidence; an auditor decides

The written parts are yours

Who declares a disaster, how customers are told, how the business runs while systems are down: VPS Snaps gives you plain templates and flags any blanks left, but it can't check what you write.

Some things are proven only by your exercises

A provider snapshot is restored in the provider's own console, and VPS Snaps can't see a system outside it. Those are proven, and their recovery time measured, by a restore you run, time and record in the plan.

Test restores run on your cloud bill

Turning on test restores builds a small server on your own cloud account for a few minutes each time, usually a few cents, then deletes it. The one-click fix says which account before it does anything.

FAQs

Can’t find the answer you’re looking for? Reach out to our support team.

Does this make us SOC 2, ISO 27001 or HIPAA compliant?

No tool can do that: an auditor decides whether a control is met. What the plan does is collect the evidence those controls ask about, such as backup schedules, restore tests, measured recovery times, a signed-off plan and its review history, and show which control each piece supports. VPS Snaps itself holds no SOC 2 report or ISO 27001 certificate.

Which plans include it?

Pro includes one continuity plan for your account. Agency includes as many as you need, one per client, each with its own systems, people and document.

Does VPS Snaps contact the people named in the plan?

No. Their names and contact details appear in your plan and its signed-off versions, and nowhere else. Review reminders go only to the workspace owner.

What happens when a backup stops meeting its target?

The plan's readiness changes as soon as the evidence does: a missed backup, a failed test restore or a schedule slower than the target turns that system from ready to needs attention or at risk. The signed-off version keeps what was true when it was approved.

Do you sign a Business Associate Agreement?

Not at the moment. Backups are written to your own storage, so the plan's HIPAA section maps your evidence to the contingency plan standard, 164.308(a)(7), without VPS Snaps acting as your business associate.

It builds on

The parts of VPS Snaps a continuity plan reads its evidence from.

Know you can recover, before you need to.

Back up your first server free. Continuity plans come with Pro and Agency.

No credit card required. Cancel anytime.