{"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://atlas.maintz.dev/)"},"id":"security/recovery-objectives","url":{"en":"https://atlas.maintz.dev/en/terms/security/recovery-objectives/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["Start from the business impact analysis and have each process owner state how long the process can be disrupted before the harm is unacceptable and how much recent data it can lose.","Translate that into an RTO and an RPO for each supporting IT system, keeping the RTO short enough to leave time for checking data and clearing the backlog before the process limit is reached.","Align the objectives of systems that exchange data, so a system is not restored to a different point in time than the systems it depends on or feeds.","Have management approve the objectives, since they decide the budget for backups, replicas and spare capacity.","Choose backup frequency, replication and restore design to meet each RPO and RTO, and keep point-in-time or offline copies so ransomware or corrupted data cannot reach every copy.","Write the objectives into the IT recovery plans, and into contracts and SLAs for systems that suppliers run.","Test restores against both a technical failure and a destructive cyberattack, and measure the actual recovery time and data loss in each test.","Close gaps between objective and result by improving the setup or by getting management to accept a longer objective, and review the objectives every year and after major changes."],"da":["Tag udgangspunkt i konsekvensanalysen (BIA), og lad hver procesejer angive, hvor længe processen kan være afbrudt, før skaden bliver uacceptabel, og hvor meget af de seneste data den kan undvære.","Omsæt det til en RTO og en RPO for hvert understøttende it-system, og hold RTO så kort, at der er tid til at kontrollere data og indhente efterslæbet, før processens grænse er nået.","Afstem målene for systemer, der udveksler data, så et system ikke gendannes til et andet tidspunkt end de systemer, det afhænger af eller leverer data til.","Få ledelsen til at godkende målene, fordi de afgør budgettet til backup, replikering og reservekapacitet.","Vælg backupfrekvens, replikering og gendannelsesdesign, så hver RPO og RTO kan nås, og behold kopier fra bestemte tidspunkter eller offline, så ransomware eller korrupte data ikke kan nå alle kopier.","Skriv målene ind i it-beredskabsplanerne og i kontrakter og SLA'er for de systemer, som leverandører driver.","Test gendannelse både efter en teknisk fejl og efter et ødelæggende cyberangreb, og mål den faktiske genoprettelsestid og det faktiske datatab ved hver test.","Luk hullet mellem mål og resultat ved at forbedre opsætningen eller ved at få ledelsen til at acceptere et længere mål, og gennemgå målene hvert år og efter større ændringer."]},"pitfalls":{"en":["Letting IT set RTO and RPO alone, without the business deciding how much downtime and data loss it can tolerate.","Setting one RTO per system based on a hardware failover, when rebuilding after ransomware can take weeks.","Promising an RTO in contracts or SLAs that has never been met in a restore test.","Relying on replication alone, which copies corrupted and encrypted data straight to the second site."],"da":["At lade it fastsætte RTO og RPO alene, uden at forretningen beslutter, hvor meget nedetid og datatab den kan tåle.","At fastsætte én RTO pr. system ud fra en failover efter hardwarefejl, når genopbygning efter ransomware kan tage uger.","At love en RTO i kontrakter eller SLA'er, som aldrig er nået ved en gendannelsestest.","At stole på replikering alene, som kopierer korrupte og krypterede data direkte til den anden lokation."]},"guides":[{"title":"NIST SP 800-34 Rev. 1 - Contingency Planning Guide for Federal Information Systems","url":"https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final","publisher":"NIST","tier":"standard"},{"title":"Architecture strategies for defining reliability targets - Azure Well-Architected Framework","url":"https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics","publisher":"Microsoft","tier":"official-doc"},{"title":"Vejledning i it-beredskab","url":"https://sikkerdigital.dk/Media/638000655159015474/Vejledning-i-it-beredskab-september-2022.pdf","publisher":"Digitaliseringsstyrelsen","tier":"official-doc","lang":"da"},{"title":"Vejledning til test af reetableringsplaner for samfundskritiske it-systemer","url":"https://sikkerdigital.dk/Media/638817808200206255/Vejledning%20i%20test%20af%20reetableringsplaner%20for%20samfundskritiske%20it-systemer.pdf","publisher":"Styrelsen for Samfundssikkerhed","tier":"official-doc","lang":"da"}]},"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}