You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/rosa-policy-incident.adoc
+28-31Lines changed: 28 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,49 +41,46 @@ The following activities can trigger notifications:
41
41
- Upgrade scheduling
42
42
43
43
[id="rosa-policy-backup-recovery-sts_{context}"]
44
-
== Backup and recovery for ROSA clusters with STS
44
+
== Infrastructure and data resiliency
45
+
Customers are responsible for taking regular backups of their data and should deploy multi-AZ clusters with workloads that follow Kubernetes best practices to ensure high availability within a region. If an entire cloud region is unavailable, customers must install a new cluster in a different region and restore their apps using their backup data.
45
46
46
-
There is no backup method available for ROSA clusters with STS.
47
+
There is no Red Hat-provided backup method available for ROSA clusters with STS. Red Hat does not commit to any Recovery Point Objective (RPO) or Recovery Time Objective (RTO).
47
48
48
-
[id="backup-recovery_{context}"]
49
-
== Backup and recovery
50
-
All Red Hat OpenShift Service on AWS cluster metadata from OpenShift Cluster Manager is securely backed up by Red Hat. The following table outlines backup and recovery strategies:
49
+
//Note: The following content will be used again in the future (per OSDOCS:4654)
50
+
//[id="backup-recovery_{context}"]
51
+
//== Backup and recovery
52
+
//All Red Hat OpenShift Service on AWS cluster metadata from OpenShift Cluster Manager is securely backed up by Red Hat. The following table outlines backup and recovery strategies:
51
53
52
54
//Verify if the corresponding tables in rosa-sdpolicy-platform.adoc and policy-incident.adoc also need to be updated.
53
55
54
-
[cols= "3a,2a,2a,3a",options="header"]
56
+
//[cols= "3a,2a,2a,3a",options="header"]
55
57
56
-
|===
57
-
|Component
58
-
|Snapshot frequency
59
-
|Retention
60
-
|Notes
58
+
//|===
59
+
//|Component
60
+
//|Snapshot frequency
61
+
//|Retention
62
+
//|Notes
61
63
62
-
.2+|Full object store backup, all cluster persistent volumes (PVs)
63
-
|Daily
64
-
|7 days
65
-
.2+|This is a full backup of all Kubernetes objects like etcd, as well as all PVs in the cluster.
64
+
//.2+|Full object store backup, all cluster persistent volumes (PVs)
65
+
//|Daily
66
+
//|7 days
67
+
//.2+|This is a full backup of all Kubernetes objects like etcd, as well as all PVs in the cluster.
66
68
67
-
|Weekly
68
-
|30 days
69
+
//|Weekly
70
+
//|30 days
69
71
70
72
71
-
|Full object store backup
72
-
|Hourly
73
-
|24 hour
74
-
|This is a full backup of all Kubernetes objects like etcd. No PVs are backed up in this backup schedule.
73
+
//|Full object store backup
74
+
//|Hourly
75
+
//|24 hour
76
+
//|This is a full backup of all Kubernetes objects like etcd. No PVs are backed up in this backup schedule.
75
77
76
-
|Node root volume
77
-
|Never
78
-
|N/A
79
-
|Nodes are considered to be short-term. Nothing critical should be stored on a node's root volume.
78
+
//|Node root volume
79
+
//|Never
80
+
//|N/A
81
+
//|Nodes are considered to be short-term. Nothing critical should be stored on a node's root volume.
80
82
81
-
|===
82
-
83
-
* Red Hat does not commit to any Recovery Point Objective (RPO) or Recovery Time Objective (RTO).
84
-
* Customers are responsible for taking regular backups of their data
85
-
* Customers should deploy multi-AZ clusters with workloads that follow Kubernetes best practices to ensure high availability within a region.
86
-
* If an entire cloud region is unavailable, customers must install a new cluster in a different region and restore their apps using their backup data.
0 commit comments