... | ... | @@ -290,7 +290,7 @@ failure occurrence to the last valid backup. |
|
|
|
|
|
- To protect against accidental data loss/deletion/service failure: implement
|
|
|
data versioning, perform regular backup, depending on the tiering of the
|
|
|
data criticality (for example customer data \<5min)
|
|
|
data criticality (for example customer data \<X min)
|
|
|
|
|
|
- Understand how you generate your backup (completeness, consistency of data),
|
|
|
and validate it can be restored (requires drills)
|
... | ... | @@ -309,19 +309,6 @@ The recovery metrics associated with IT Service Continuity are: |
|
|
|
|
|
![749c218eac6d9be71f41c5d493326d4a](uploads/bf1c9404ba2d66db218059ff92c61ef1/749c218eac6d9be71f41c5d493326d4a.png)
|
|
|
|
|
|
Examples
|
|
|
|
|
|
- Petrotechnical Suite:
|
|
|
|
|
|
- In case of data center failure. RPO = 24h. RTO = 9h.
|
|
|
|
|
|
- In case of data delete. RPO = 5min. RTO = instant. (5 min is relatively
|
|
|
high considering this relates to customer data)
|
|
|
|
|
|
- Portal/CFS
|
|
|
|
|
|
- In case of data center failure. RPO = 24h. RTO = 5min. (5 min is
|
|
|
acceptable considering the type of data (subscription definitions))
|
|
|
|
|
|
**SLI** (Service Level Indicators). Instrument the DDMS with service level
|
|
|
indicators driving the understanding of availability of the service.
|
... | ... | |