RTO (Recovery Time Objective)
Also known as: Recovery Time
RTO defines the maximum time a system is allowed to stay down before it must be back up and running after a failure.
RTO, the Recovery Time Objective, sets the maximum amount of time a system may be down before it has to be restored. It exists because not every system is equally urgent - a point-of-sale system has a different time pressure than an internal archive that is opened once a month.
In practice, RTO is set per system: the order server must be back within four hours, the archive can stay down for two days. That target directly determines the technical solution needed - a standby server that takes over automatically, or a backup that first has to be restored by hand.
The most common mistake is never setting an RTO at all and only asking how much time there actually is once the outage has already happened. As an example of the distinction that trips people up: RTO is the time until restoration, how long the business is down, while RPO is the data lost since the last backup point, how much disappears.
What it means in practice
For a business this means: without a defined RTO, nobody knows during an actual outage whether restoring overnight is fine or whether production has to resume within the hour. NDVDL sets RTO values together with the business, system by system, before any backup or disaster-recovery setup is planned.
Is this handled properly at your site?
We look at how it actually stands with you — and say honestly whether anything needs doing.
Related terms
All termsA term from your quote missing here?
Send us the passage you do not follow. We will explain it — with no obligation to order anything.