Imagine your accounting server fails at 3 p.m. Two questions come up right away. When was the last backup, and how much of today’s work is gone? And how long until the accounting team can work again? If you don’t know the answers ahead of time, your backup plan is built on guesswork, not on what the business actually needs.
RPO and RTO are two simple concepts that turn these questions into numbers.
What is RPO?
RPO (Recovery Point Objective) is the maximum amount of data, measured in time, that you can afford to lose. If the RPO for your finance database is 4 hours, you accept that in the worst case the last 4 hours of work must be re-entered. Anything more is not acceptable.
RPO directly sets how often you back up. A nightly backup means an RPO of about 24 hours. If the business can only tolerate losing one hour of data, nightly backups are not enough, and you need frequent backups, database log backups or replication.
What is RTO?
RTO (Recovery Time Objective) is the maximum time a system can be down before it must be working again. The clock starts the moment the problem occurs, and it covers more than copying files. Detecting the problem, making decisions, preparing replacement hardware, restoring and testing all count.
RTO determines the infrastructure you need. If the RTO for your email server is one day, restoring from a regular backup onto a new server is enough. But if the RTO for your sales system is one hour, you probably need a ready virtual machine on a second host, a replica, or features such as running a VM directly from the backup.
RPO looks back (how much data is lost) and RTO looks forward (how long until we are back). The two are independent; a system can have a short RPO and a long RTO.
How do you set RPO and RTO?
IT should not set these numbers alone. It is a management decision that IT carries out. A simple approach:
- List your core systems: finance software, file server, email, office automation, website and phones.
- Ask the head of each department: if this system went down today, after how many hours would work truly stop, and what would it cost? How much re-entry of data is tolerable?
- Turn the answers into numbers and group the systems into a few priority tiers.
- Estimate the cost of reaching each number. Shorter RPO and RTO mean more equipment, licenses and bandwidth.
- If the cost doesn’t fit the budget, revise the number with management’s knowledge rather than quietly dropping it.
A simple example
For a mid-sized trading company, the end result might look like this:
- Finance and inventory software: RPO of one hour and RTO of four hours; a nightly full backup with hourly log backups and a standby host for recovery.
- File server: RPO of four hours and RTO of one business day; several backups a day plus Shadow Copy for quickly restoring individual files.
- Archive of old documents: RPO of one day and RTO of several days; a nightly backup is enough.
Common mistakes
- One number for every system. This either drives costs up for no reason or leaves critical systems unprotected.
- Ignoring dependencies. Finance software won’t start without the domain, DNS and network, so their RTO cannot be longer than the finance software’s RTO.
- Setting an RTO without testing. Until you have timed a real restore, you don’t know whether you can hit the target.
- Forgetting the offsite copy. Restoring from a remote copy is usually slower and must be factored into the RTO.
Checklist
- Your core systems and the business owner of each are clearly identified.
- Each system has a written RPO and RTO approved by management.
- Backup frequency matches each system’s RPO.
- You have tested actual recovery time and compared it with the RTO.
- The recovery order is documented based on system dependencies.
Once RPO and RTO are clear, choosing software, equipment and backup schedules is no longer a matter of taste. ITPlus724 engineers can help your company set these numbers and design a backup that actually meets them.