{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/recovery-objectives","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/recovery-objectives/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/recovery-objectives/"},"term":{"en":"Recovery objectives (RTO/RPO)","da":"Genopretningsmål (RTO/RPO)"},"aka":{"en":["RTO","RPO","recovery time objective","recovery point objective"],"da":["RTO","RPO","genoprettelsestid","tolereret datatab"]},"domain":["security"],"cluster":"incident-response","layer":"governance","status":"current","summary":{"en":"Two agreed limits for a failure - how long a system may be down (RTO) and how much recent data may be lost (RPO).","da":"To aftalte grænser ved nedbrud - hvor længe et system må være nede (RTO), og hvor meget af de seneste data der må gå tabt (RPO)."},"body":{"formal":{"en":"The recovery time objective (RTO) is the longest a system or process may be unavailable before the harm becomes unacceptable. The recovery point objective (RPO) is the oldest point in time the data may be restored to, which sets how often a backup must be taken.","da":"Recovery time objective (RTO) er den længste tid, et system eller en proces må være ude af drift, før skaden bliver uacceptabel. Recovery point objective (RPO) er det ældste tidspunkt, data må gendannes fra, og afgør dermed, hvor ofte der skal tages backup."},"plain":{"en":"If your phone dies, RTO is how long you can manage without one; RPO is how many days of photos you could stand to lose since your last copy.","da":"Hvis din telefon går i stykker, er RTO, hvor længe du kan klare dig uden; RPO er, hvor mange dages billeder du kan tåle at miste siden din seneste kopi."},"inPractice":{"en":"A Danish web shop decides its order system needs an RTO of four hours and an RPO of fifteen minutes, so it copies orders to a second location every fifteen minutes and practises a switch-over twice a year.","da":"En dansk webshop beslutter, at ordresystemet skal have en RTO på fire timer og en RPO på et kvarter, så den kopierer ordrer til en anden lokation hvert kvarter og øver et skifte to gange om året."},"whyItMatters":{"en":"The two numbers turn a vague wish to \"be back quickly\" into a clear target that decides how much to spend on backup and spare systems.","da":"De to tal gør et vagt ønske om at \"være hurtigt oppe igen\" til et klart mål, der afgør, hvor meget der skal bruges på backup og reservesystemer."}},"deepDive":{"en":"NIST SP 800-34 Rev. 1 (§3.2) defines three related values that come out of the business impact analysis. The maximum tolerable downtime (MTD) is the total time a business process can be disrupted before the impact becomes unacceptable. The recovery time objective (RTO) is the maximum time a system resource can remain unavailable before it affects the processes that depend on it, and must be shorter than the MTD. The recovery point objective (RPO) is the point in time, before the disruption, to which data must be recoverable, in other words the maximum acceptable data loss. A common decomposition is MTD = RTO + WRT, where the work recovery time covers verifying restored systems, re-entering data and clearing backlogs before the business process is fully back. ISO 22301 uses the parallel concept of maximum tolerable period of disruption (MTPD), with RTOs set within it, and adds the minimum business continuity objective (MBCO) for the reduced service level acceptable during the disruption.\n\nRPO drives data protection design. A nightly backup gives an RPO of up to about 24 hours; hourly snapshots or log shipping bring it to minutes; synchronous replication approaches zero but adds write latency that grows with distance and replicates logical corruption and ransomware encryption instantly, so it must be combined with point-in-time copies. RTO drives recovery design: restore throughput, the time to provision infrastructure, dependency order, and staff availability at night or on weekends. For large datasets, restore speed from backup storage or over a WAN link is often the binding constraint, and restoring tens of terabytes can take days even when the backup itself is intact.\n\nObjectives are targets, not measurements. Recovery time actual and recovery point actual are measured in exercises, and the gap between objective and actual is the most useful output of a DR test. A frequent error is setting a single RTO per system without considering the scenario: failover of a VM after hardware failure may take minutes, while rebuilding after domain-wide ransomware requires forensic clearance, clean infrastructure and credential resets that can take weeks. Objectives should therefore be tested against a destructive cyber scenario as well as a technical failure.\n\nRTO and RPO differ from service level objectives. An SLO describes normal-operation reliability, such as 99.9 % availability over a month, and is managed through error budgets, whereas recovery objectives describe tolerable impact once a disruption has already happened. Both must be consistent with contracts: an SLA promising four-hour restoration is meaningless if the DRP's tested recovery time is two days.","da":"NIST SP 800-34 Rev. 1 (§3.2) definerer tre beslægtede værdier, der kommer ud af konsekvensanalysen. Den maksimalt tålelige nedetid (MTD) er den samlede tid, en forretningsproces kan være afbrudt, før konsekvensen bliver uacceptabel. Recovery time objective (RTO) er den længste tid, en systemressource kan være utilgængelig, før det påvirker de processer, der afhænger af den, og den skal være kortere end MTD. Recovery point objective (RPO) er det tidspunkt før afbrydelsen, som data skal kunne gendannes til, med andre ord det størst acceptable datatab. En udbredt opdeling er MTD = RTO + WRT, hvor work recovery time dækker verifikation af gendannede systemer, genindtastning af data og afvikling af efterslæb, før forretningsprocessen er helt tilbage. ISO 22301 bruger det tilsvarende begreb maksimalt tålelig afbrydelsesperiode (MTPD), hvor RTO'erne fastsættes inden for den, og tilføjer det minimale kontinuitetsniveau (MBCO) for det reducerede serviceniveau, der er acceptabelt under afbrydelsen.\n\nRPO styrer designet af databeskyttelsen. En natlig backup giver en RPO på op til omkring 24 timer; snapshots hver time eller log shipping bringer den ned på minutter; synkron replikering kommer tæt på nul, men giver skrivelatens, der vokser med afstanden, og replikerer logisk korruption og ransomwarekryptering øjeblikkeligt, så den skal kombineres med kopier fra bestemte tidspunkter. RTO styrer designet af genopretningen: gendannelseshastighed, tiden til at etablere infrastruktur, rækkefølgen af afhængigheder og medarbejdernes tilgængelighed om natten og i weekender. For store datamængder er gendannelseshastigheden fra backuplageret eller over en WAN-forbindelse ofte den begrænsende faktor, og gendannelse af flere titals terabyte kan tage dage, selv når selve backuppen er intakt.\n\nMålene er mål, ikke målinger. Den faktiske genoprettelsestid og det faktiske gendannelsespunkt måles ved øvelser, og forskellen mellem mål og virkelighed er det mest nyttige resultat af en DR-test. En hyppig fejl er at fastsætte én RTO pr. system uden at tænke på scenariet: failover af en virtuel maskine efter en hardwarefejl kan tage minutter, mens genopbygning efter ransomware i hele domænet kræver forensisk frigivelse, ren infrastruktur og nulstilling af adgangsoplysninger, hvilket kan tage uger. Målene bør derfor testes mod et ødelæggende cyberscenarie og ikke kun mod en teknisk fejl.\n\nRTO og RPO adskiller sig fra service level objectives. En SLO beskriver pålideligheden i normal drift, fx 99,9 % tilgængelighed over en måned, og styres med fejlbudgetter, mens genopretningsmål beskriver den tålelige konsekvens, når en afbrydelse allerede er sket. Begge skal hænge sammen med kontrakterne: en SLA, der lover genopretning inden fire timer, er meningsløs, hvis DRP'ens testede genoprettelsestid er to døgn."},"edges":[{"type":"requires","to":"security/business-impact-analysis","confidence":"high","strength":"normal"},{"type":"requires","to":"security/availability","confidence":"high","strength":"normal"},{"type":"part-of","to":"security/business-continuity-plan","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"platform/service-level-objective","confidence":"high","strength":"normal"}],"depth":4,"sources":[{"title":"NIST SP 800-34 Rev. 1 - Contingency Planning Guide for Federal Information Systems","tier":"standard","publisher":"NIST"},{"title":"ISO 22301:2019 - Business continuity management systems, Requirements","tier":"standard","publisher":"ISO"}],"draft":true}