RTO (recovery time objective) is how long a system may be down after a failure; RPO (recovery point objective) is how many hours of data you may lose. A system with a 4-hour RTO and a 1-hour RPO must work again within four hours of an incident, with at most the last hour of work missing. Both numbers are business decisions made per system, and together they decide what your backup and disaster recovery cost.
RTO and RPO in one example
A wholesale company of 40 people runs its ERP on one server, with a database backup every night at 23:00. On Tuesday at 15:00 the server's storage fails.
- Data lost: everything entered since 23:00 on Monday, 16 hours of orders and invoices. Had the failure come just before 23:00, it would have been almost 24 hours. So the RPO this setup really delivers is 24 hours.
- Time down: an hour to prepare a replacement server, two hours to copy and restore the 400 GB backup, one more to check the database and reconnect users. The ERP is back at 19:00: an RTO of four hours, and only if the person who knows the steps is at work that day.
If management wants at most one hour of lost orders and work again within two hours, neither target is met. A one-hour RPO needs copies at least hourly, for a database usually transaction log backups every 15 minutes. A two-hour RTO usually needs a standby server that is already installed. Note that the RTO clock starts at the failure, not when someone notices it: an outage at 02:00 found at 08:00 has already used six hours.
RTO vs RPO vs backup retention
A third number is often confused with the first two: how long backups are kept.
| Number | Question it answers | What sets it | Example |
|---|---|---|---|
| RPO | How much recent data can we lose? | How often copies are made and how fast they leave the server | Hourly copies: up to one hour lost |
| RTO | How long can we be down? | Where you restore to, how much data there is, how practised the team is | Standby server: under an hour; new server and full restore: several hours |
| Retention | How far back can we go? | How many copies are kept, and for how long | Daily copies kept 7 days: back up to a week |
Retention matters when damage is found late. Ransomware often waits in a network for days, and a deleted folder may be missed for weeks. If backups are kept for 7 days and the problem started 10 days ago, every copy contains it, however good the RPO. Keep daily copies at least as long as problems usually go unnoticed, plus weekly or monthly ones.
You will also meet maximum tolerable downtime (MTD): the point after which an outage seriously harms the business. The RTO must sit safely below it. Latvian Cabinet Regulation No. 397 asks NIS2 subjects to write down RPO, RTO and maximum tolerable downtime for every system; see our NIS2 checklist for Latvia.
How to choose targets for each system
- List the systems and their dependencies. An ERP also needs its database, logins, DNS and the VPN. A chain is back only when its slowest part is back.
- Ask the business two questions per system. What does an hour of downtime cost in lost sales, idle staff and penalties? What does an hour of lost data cost, including orders paid online that cannot be re-created? If 30 people lose half their productive time at 30 EUR an hour each, an hour of downtime costs about 450 EUR; see our five-year server cost comparison.
- Check outside requirements. Contracts with your clients, NIS2, sector rules and record-keeping duties can set a minimum for you.
- Put each system in a tier and price it. If protection costs more per year than the damage it prevents, relax the target; if it costs far less, tighten it.
- Write the targets down and test them. A number nobody has tested is a wish.
These tiers are a starting point for a small or mid-sized company, not a standard:
| Tier | Typical systems | RPO | RTO | Usual method |
|---|---|---|---|---|
| 1. Critical | ERP or accounting database, online shop checkout, payments | 15 minutes or less | 1 to 4 hours | Replication or frequent log backups to a prepared standby server, plus ordinary backups |
| 2. Important | Email, file server, CRM, company website | 1 to 4 hours | The same working day | Hourly snapshots or backups, a documented restore to a spare server |
| 3. Normal | Intranet, wiki, development and test servers | 24 hours | 1 to 3 working days | Nightly backup, restored when needed |
| 4. Archive | Closed accounting years, old projects, audit logs | A week, or one copy if nothing changes | Days to weeks | Weekly or one-off immutable copies on low-cost storage |
What drives the cost
- RPO sets the technique. Nightly backups are cheap; hourly snapshots, log shipping and continuous replication each add traffic, storage and one more system to watch.
- RTO sets what is waiting for you. Restoring onto new hardware takes hours to days. A warm standby, installed and kept up to date, takes tens of minutes to a few hours. A hot standby takes over automatically within minutes, at roughly twice the hardware and licences.
- Data volume sets the restore time. 2 TB over a 1 Gbit/s link takes about four and a half hours at full speed, before any checks.
- Retention and immutability cost storage. Copies that cannot be deleted before a set date stop ransomware, but they cannot be cleaned up early either.
- Licences and people. Check what your licences allow on a standby server, and who can run the recovery at the weekend.
The curve gets steep near zero: moving an RPO from 24 hours to 1 hour is usually affordable, moving it from 1 hour to almost nothing often is not.
Backup is not disaster recovery
A backup is a copy of data. Disaster recovery is the plan and infrastructure that bring a service back after a serious event: where you restore to, in what order, who decides, how users and DNS are switched, and where the passwords are when the password manager was on the failed server. Backups give you the RPO; disaster recovery gives you the RTO.
RAID, replication and snapshots are often mistaken for backups. RAID survives one failed disk, not deletion or encryption; replication copies mistakes and ransomware within seconds; snapshots on the same storage disappear with it. Disaster recovery as a service (DRaaS) packages replication and a standby environment into a subscription, and bought or built, the questions are the same: which systems, which targets, where the second site is and how often it is tested.
The 3-2-1 rule, briefly
Keep three copies of your data, on two different systems or media, with one copy off site. The modern 3-2-1-1-0 adds one offline or immutable copy that ransomware holding admin passwords cannot delete, and zero errors in restore tests. More in the 3-2-1 rule for business data and the step-by-step guide how to back up a server with the 3-2-1 rule. For RTO, remember that the off-site copy is usually the slowest to restore: keep a local copy for everyday restores and the off-site one for disasters.
Test restores, or the numbers are guesses
- Restore tier 1 systems at least every quarter, the rest at least once a year.
- Time the test until users can work: that is your real RTO. Check the newest restored record: that is your real RPO.
- Test the whole chain: the database opens, the application starts, a user logs in.
- A failed backup must raise an alert a person reads, and production credentials must not be able to delete backups.
- Write the steps down so someone else can follow them, and once a year rehearse losing the main site.
What CloudHosting offers today
Our standard services have fixed backup parameters. In the terms of this article:
- VPS: daily backups kept for 7 days, stored separately from the server and restored from the client panel: an RPO of up to 24 hours with 7 days of retention. Hourly snapshots and a copy in the other region, Riga or Amsterdam, are available on request and priced for your setup.
- Web hosting: daily off-site backups with 14 days of restore points; a file, a database or the whole account can be restored from cPanel at any time.
- S3 object storage: an off-site target for Veeam, rclone and other backup tools, in the EU, replicated across several independent data centres, with Object Lock for immutable copies. From 10 TB, from 186.15 EUR a month.
- Dedicated servers and colocation: you configure the servers, so the backup scheme is your own or one we design with you.
- Company infrastructure: we agree RPO and RTO for each system in writing, design backups, a standby server or a failover pair to meet them, and test recovery with you.
Contractual RTO and RPO figures are agreed in the contract for each project. We publish no single number, because an honest RTO depends on your systems, data volume and budget. The 99.9% we name for standard services is an availability target, not a contractual guarantee. Nor do we sell a boxed DRaaS subscription: a standby environment is designed as part of an infrastructure project.
Our Riga data centre, which we run ourselves, has N+1 power with UPS and a diesel generator, N+1 cooling and two uplinks. It is guarded and closed to visitors: equipment is handed over at our office and installed by our engineers, and only a limited number of our specialists have access. Monitoring and incident response run 24/7; engineers answer on working days 9:00-17:00 Riga time. To have backups on your current servers run and tested, use our IT support, from 50 EUR an hour or a fixed monthly fee. To see where you stand first, an IT audit from 200 EUR includes a check of your backups and recovery. Or send your list of systems through the contacts page.