Recovery time objective (RTO) is the longest a system can stay down after a failure before the outage starts doing real damage to the business. Recovery point objective (RPO) is the most data you can afford to lose, measured in time: an RPO of one hour means you can lose up to the last hour of writes. RTO is how fast you come back, and RPO is how far back you come back to.
Both are business decisions first. Your backup software doesn’t pick them. Someone who knows what an hour of lost orders costs should set them, and then the infrastructure has to be built and tested to hit them. These are the same definitions NIST uses in its contingency planning guide, SP 800-34 Rev. 1.
RTO vs RPO at a glance
| RTO (recovery time objective) | RPO (recovery point objective) | |
|---|---|---|
| What it measures | Time from the failure until the service works again | Time between your last good copy of the data and the failure |
| The question it answers | How long can we be down? | How much recent work can we afford to lose or redo? |
| What drives it | How fast you can get hardware, restore data and move traffic | How often data leaves the server: backup schedule, snapshot interval, replication |
| What it costs to shrink | Standby capacity: spare servers, pre-built environments, people on call | Storage, bandwidth and tooling to copy data more often |
A worked example: one shop, one dedicated server
This is a hypothetical, and the numbers are round on purpose.
A small online store runs on a single dedicated server. Web server, application and MySQL database all live on the same box, with about 200 GB of data. To keep the math simple, assume a flat 10 orders an hour at $60 each, so about $600 an hour in sales. At 6 p.m. on a weekday, the RAID controller dies and takes the array with it.
How the backup method sets your RPO
- Nightly backup at 2 a.m., copied offsite. The newest good copy is 16 hours old, so about 160 orders, plus every new account and stock change since 2 a.m., are gone. If the failure hits at 1:59 a.m. instead, you lose almost a full day. Your real RPO is 24 hours, whatever the plan says.
- Hourly snapshots shipped off the server. Worst case you lose an hour plus the time the copy takes to land offsite. Call it 60 to 75 minutes, or 10 to 12 orders.
- Database replication to a second server. The replica trails the primary by seconds. RPO is close to zero for a hardware failure.
One catch with replication: it copies mistakes as fast as it copies good data. A bad migration or a stray DROP TABLE hits the replica a second later. It shrinks RPO for dead hardware but doesn’t replace backups you can roll back to.
Your payment processor still has the charges. What you can’t easily rebuild is who ordered which size and what your stock counts should be.
How the recovery method sets your RTO
Restore from backup. Walk through what actually has to happen:
- Notice the outage and decide it’s a disaster, not a blip: 30 minutes.
- Get a working server, by replacing the controller or provisioning a new box and installing the OS: 1 to 3 hours.
- Pull 200 GB back from offsite storage. At a full 1 Gbps that’s about 27 minutes of pure transfer, but plan on 1 to 2 hours.
- Reinstall the stack, restore the database and fix the config nobody wrote down: 1 to 2 hours.
- Point DNS at the new IP if it changed, then test checkout: 30 minutes.
That’s 4 to 8 hours, if the person who knows the setup answers the phone.
Warm standby. A second server, ideally in a different facility, already runs the same stack and receives database replication. Recovery means promoting the replica, switching DNS (with a short TTL you set in advance) and checking checkout. That’s 15 to 30 minutes, and most of it is a human deciding to pull the trigger.
The standby costs a second server every month, plus the effort of keeping it in step with every change you make to the primary. At $600 an hour, a few hours down on a Tuesday is annoying but survivable, while the same outage during a holiday sale could eat the month’s margin. That’s the real decision.
Set targets per system, not per company
One RTO for the whole company is a mistake. Systems hurt differently when they’re down, so tier them. A reasonable starting point for a small business:
- Tier 1, revenue and customer-facing: checkout, the order database, the customer portal. RPO in minutes, RTO of an hour or two.
- Tier 2, needed to run the business: email, admin tools, the CMS. RPO of a day, RTO of a day.
- Tier 3, nice to have: staging, analytics, old logs. RPO of a week, RTO of “when we get to it”.
To place a system, ask the person who owns that process two questions. If this is down for four hours, what breaks and what does it cost? If we lose its last day of data, can we rebuild it, and from where? Then check dependencies. A Tier 1 app that can’t start without a Tier 3 license server means you actually have a Tier 1 license server.
Test them, because the RTO you have is the one you measured
A target in a document is a wish. Your real RTO is how long the last real restore took, start to finish, timed.
For the shop above, a drill looks like this. Restore last night’s backup onto a spare server (never production), bring the app up and place a test order. Time it from “we’ve declared a disaster” to “the test order went through”. For RPO, pretend the failure happened when the drill started, then find the newest order in the restored database. The gap between the two is your measured RPO.
Write both numbers down. The first drill almost always finds something, like a missing config file or a backup job that’s been failing quietly since someone changed a password. Run Tier 1 drills at least quarterly and after any big change to the stack.
Common mistakes
Backups on the same server
A backup on the same disk, array or server as production protects you from an accidental rm and not much else. Dead hardware or ransomware takes the copy along with the original. RAID isn’t a backup either, since it mirrors deletions just as faithfully as writes. Get at least one copy off the server and out of reach of its credentials.
Never testing restores
Backup jobs report success when they finish writing. That isn’t the same as a restore working. Untested backups are how teams find out, mid-outage, that the database dump has been zero bytes for three months.
Letting the backup schedule set the RPO
This one is backwards and very common. Someone set up a nightly job years ago, so the RPO quietly became 24 hours, and nobody asked whether losing a day of orders was acceptable. Start from the business answer, then pick the backup method that meets it.
Where GigeNET fits
If you’re on one of our dedicated servers, start with what you already have: every GigeNET dedicated server includes R1Soft automated backups with 1 TB of storage at no charge, and if R1Soft doesn’t support your OS we use Veeam instead. For a single server with modest data, that’s a working RPO on day one. The two services below are for bigger environments and tighter targets.
We run two Veeam-based services that map onto the two halves of this post.
Veeam Cloud Connect backups cover the RPO side. Your Veeam jobs send backups over an SSL-encrypted connection to a repository in our data centers that we manage. It supports VMware and Hyper-V, and Veeam Agent covers Windows and Linux machines with no hypervisor, like the bare-metal shop above. Restores can be at the file, volume or full-machine level, and because the copies sit offsite, ransomware that encrypts your server and its local backup volumes doesn’t reach them.
Veeam DRaaS covers the RTO side for VMware and Hyper-V environments. Replication keeps a warm copy of your VMs in our data centers that can be powered on in minutes, instead of restored from backup over hours. You can run the DR side on dedicated servers or your own colocated hardware with us, or replicate into our Cloud Connect platform with no DR hardware to manage. Replication schedules and RPO targets can be set per workload, and failback syncs your data back to production.
On bare metal, the warm standby from the example is a second dedicated server running database replication, ideally in another of our regions (Ashburn, Chicago or Los Angeles). We won’t quote you an RTO or RPO in the abstract, because the real numbers depend on your data, your stack and how often you test.
Your RPO is only real if last night’s backup actually restores, so test it. Tell us what you’re running and our engineers will help you set RPO and RTO targets, then configure and test the environment before you need it. Veeam backups · Disaster recovery
Not ready to order yet?
Tell us what you need protected and how much data, and we’ll email you the options and the price. Rather talk it through? Call (800) 561-2656.
FAQ
What’s the difference between RTO and RPO in disaster recovery?
RTO is time to recover: how long until the service works again. RPO is data: how old your last good copy is when the failure hits. A nightly backup with a four-hour restore gives you roughly a 24-hour RPO and a four-hour RTO.
What is a good RTO for a small business?
There’s no universal number. For many small businesses, a few hours for customer-facing systems and a day for internal ones is a sensible start. If you sell online, price out an hour of downtime on your busiest day and work back from that.
Can RPO be zero?
Close to it, for hardware failure, with synchronous replication, where a write isn’t confirmed until both copies have it. That adds latency to every write and needs a second full environment. It does nothing about bad deletes, which replicate too, so you still need point-in-time backups.
Do snapshots count as backups for RPO?
Only once they’re copied somewhere else. A snapshot on the same storage as production dies with that storage. They’re great for rolling back a bad update, but for disaster recovery they need to leave the server.
