Editing IT disaster recovery (section)

==IT service continuity==
{{see also|Business continuity and disaster recovery auditing}}
'''IT service continuity (ITSC)''' is a subset of BCP,<ref>{{cite web
|website=ForbesMiddleEast.com
|title=Defending The Data Strata
|url=https://www.forbesmiddleeast.com/en/defending-the-data-strata
|date=December 24, 2013
}}{{Dead link|date=August 2024 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> which relies on the metrics (frequently used as [[key risk indicators]]) of recovery point/time objectives. It encompasses '''IT disaster recovery planning''' and the wider '''IT resilience planning'''. It also incorporates IT infrastructure and [[IT service|services]] related to [[telecommunications|communications]], such as [[telephony]] and [[data communications]].<ref>{{cite web
  |website=[[Association for Computing Machinery|ACM]].com (ACM Digital Library)
  |title=Information systems continuity process   |author1=M. Niemimaa |author2=Steven Buchanan
  |date=March 2017 |url=https://dl.acm.org/citation.cfm?id=3062955}}</ref><ref>{{cite magazine
  |magazine=Disaster Recovery Journal
  |url=https://www.drj.com/images/journal/fall-2017-volume30-issue3/2017_ITServiceDir.pdf
  |title=2017 IT Service Continuity Directory
  |access-date=2018-11-30
  |archive-date=2018-11-30
  |archive-url=https://web.archive.org/web/20181130084451/https://www.drj.com/images/journal/fall-2017-volume30-issue3/2017_ITServiceDir.pdf
  |url-status=dead
  }}</ref>

===Principles of backup sites===
{{Main|Backup site}}
Planning includes arranging for backup sites, whether they are "hot" (operating prior to a disaster), "warm" (ready to begin operating), or "cold" (requires substantial work to begin operating), and standby sites with hardware as needed for continuity.

In 2008, the [[British Standards Institution]] launched a specific standard supporting Business Continuity Standard [[BS 25999]], titled BS25777, specifically to align computer continuity with business continuity. This was withdrawn following the publication in March 2011 of ISO/IEC 27301, "Security techniques — Guidelines for information and communication technology readiness for business continuity."<ref>{{Cite web|website=Business Continuity Forum|date=2012-05-03|title=ISO 22301 to be published Mid May - BS 25999-2 to be withdrawn|url=https://www.continuityforum.org/content/news/165318/iso-business-continuity-standard-22301-replace-bs-25999-2|access-date=2021-11-20|language=en}}</ref>

[[ITIL]] has defined some of these terms.<ref>{{Cite web|url=https://www.axelos.com/resource-hub/glossary/|title=Browse the Resource Hub for all the latest content &#124; Axelos|website=www.axelos.com}}</ref>

===Recovery Time Objective===
The '''Recovery Time Objective (RTO)'''<ref name=Forb.En>{{cite magazine
  |magazine=[[Forbes]] |date=April 30, 2015
  |url=https://www.forbes.com/sites/sungardas/2015/04/30/like-the-nfl-draft-is-the-clock-the-enemy-of-your-recovery-time-objective
  |title=Like The NFL Draft, Is The Clock The Enemy Of Your Recovery Time}}</ref><ref name=Forb.R3>{{cite magazine  |magazine=[[Forbes]] |date=October 10, 2013
  |url=https://www.forbes.com/sites/sungardas/2013/10/29/three-reasons-you-cant-meet-your-disaster-recovery-time-objectives
  |title=Three Reasons You Can't Meet Your Disaster Recovery Time}}</ref> is the targeted duration of time and a service level within which a [[business process]] must be restored after a disruption in order to avoid a break in business continuity.<ref name=druva>{{cite web 
   |url=http://www.druva.com/blog/2008/03/22/understanding-rpo-and-rto
   |title=Understanding RPO and RTO
   |publisher=DRUVA   |date=2008  |access-date=February 13, 2013}}</ref>

According to business continuity planning methodology, the RTO is established during the [[business impact analysis]] (BIA) by the owner(s) of the process, including identifying time frames for alternate or manual workarounds.

[[File:RPO RTO example converted.png|thumb|500px|<small>Example showing longer 'actual' times that do NOT meet either RPO or RTOs ('objectives'). Diagram provides schematic representation of the terms [[Recovery Point Objective|RPO]] and RTO.</small>]]

RTO is a complement of RPO. The limits of acceptable or "tolerable" [[IT service continuity|ITSC]] performance are measured by RTO and RPO in terms of time lost from normal business process functioning and data lost or not backed up during that period.<ref name="druva" /><ref name="TTdiff">{{Cite web
   |url=https://searchstorage.techtarget.com/feature/What-is-the-difference-between-RPO-and-RTO-from-a-backup-perspective
   |title=How to fit RPO and RTO into your backup and recovery plans
   |website=SearchStorage |access-date=2019-05-20}}</ref>

====Recovery Time Actual====
'''Recovery Time Actual (RTA)''' is the critical metric for business continuity and disaster recovery.<ref name=Forb.En/>

The business continuity group conducts timed rehearsals (or actuals), during which RTA gets determined and refined as needed.<ref name=Forb.En/>

=== Recovery Point Objective ===
A '''Recovery Point Objective (RPO)''' is the maximum acceptable interval during which [[transactional data]] is lost from an IT service.<ref name=druva/>

For example, if RPO is measured in minutes, then in practice, off-site mirrored backups must be [[Continuous data protection|continuously maintained]] as a daily off-site backup will not suffice.<ref>{{cite web 
   |author=Richard May |title=Finding RPO and RTO
   |url=http://www.virtualdcs.co.uk/blog/business-continuity-planning-rpo-and-rto.html|url-status=dead
   |archive-url=https://web.archive.org/web/20160303224604/http://www.virtualdcs.co.uk/blog/business-continuity-planning-rpo-and-rto.html|archive-date=2016-03-03}}</ref>

====Relationship to RTO====
A recovery that is not instantaneous restores transactional data over some interval without incurring significant risks or losses.<ref name=druva/>

RPO measures the maximum time in which recent data might have been permanently lost and not a direct measure of loss quantity. For instance, if the BC plan is to restore up to the last available backup, then the RPO is the interval between such backups.

RPO is not determined by the existing backup regime. Instead BIA determines RPO for each service. When off-site data is required, the period during which data might be lost may start when backups are prepared, not when the backups are secured off-site.<ref name=TTdiff/>

===Mean times===
The recovery metrics can be converted to/used alongside [[failure]] metrics. Common measurements include [[mean time between failures]] (MTBF), [[mean time to first failure]] (MTFF), [[mean time to repair]] (MTTR), and [[mean down time]] (MDT).

===Data synchronization points===
A data synchronization point<ref>{{cite web  |date=May 14, 2013
   |title=Data transfer and synchronization between mobile systems
   |url=http://www.freepatentsonline.com/8442943.html}}</ref> is a backup is completed. It halts update processing while a disk-to-disk copy is completed. The backup<ref>{{cite web
   |title=Amendment #5 to S-1   |website=SEC.gov
   |url=https://www.sec.gov/Archives/edgar/data/1519917/000119312512125661/d179347ds1a.htm
   |quote=real-time  ... provide redundancy and back-up to ...}}</ref> copy reflects the earlier version of the copy operation; not when the data is copied to tape or transmitted elsewhere.

===System design===
RTO and the RPO must be balanced, taking business risk into account, along with other system design criteria.<ref>{{cite book|chapter=Setting the Maximum Tolerable Downtime -- setting recovery objectives|pages=19–22
|title=IT Disaster Recovery Planning For Dummies
|author=Peter H. Gregory  |publisher=Wiley  |isbn=978-1118050637
|chapter-url=https://books.google.com/books?id=YC49DXW-_60C&pg=PA20|date=2011-03-03
}}</ref>

RPO is tied to the times backups are secured offsite. Sending synchronous copies to an offsite mirror allows for most unforeseen events. The use of physical transportation for tapes (or other transportable media) is common. Recovery can be activated at a predetermined site. Shared offsite space and hardware complete the package.<ref>{{cite book|title=Information Security for Managers |page=177|url=https://books.google.com/books?isbn=1349101370  |isbn=1349101370|author1=William Caelli  |author2=Denis Longley  |year=1989|publisher=Springer }}</ref>

For high volumes of high-value transaction data, hardware can be split across multiple sites.