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/policy-incident.adoc
+7-9Lines changed: 7 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -44,6 +44,8 @@ The following activities can trigger notifications:
44
44
== Backup and recovery
45
45
All {product-title} clusters are backed up using cloud provider snapshots. Notably, this does not include customer data stored on persistent volumes. All snapshots are taken using the appropriate cloud provider snapshot APIs and are uploaded to a secure object storage bucket (S3 in AWS, and GCS in Google Cloud) in the same account as the cluster.
46
46
47
+
//Verify if the corresponding tables in rosa-sdpolicy-platform.adoc and rosa-policy-incident.adoc also need to be updated.
48
+
47
49
[cols= "3a,2a,2a,3a",options="header"]
48
50
49
51
|===
@@ -52,10 +54,10 @@ All {product-title} clusters are backed up using cloud provider snapshots. Notab
52
54
|Retention
53
55
|Notes
54
56
55
-
.2+|Full object store backup, all SRE-managed cluster persistent volumes (PVs)
57
+
.2+|Full object store backup, all cluster persistent volumes (PVs)
56
58
|Daily
57
59
|7 days
58
-
.2+|This is a full backup of all Kubernetes objects like etcd, as well as all SRE-managed PVs in the cluster.
60
+
.2+|This is a full backup of all Kubernetes objects like etcd, as well as all PVs in the cluster.
59
61
60
62
|Weekly
61
63
|30 days
@@ -73,14 +75,10 @@ All {product-title} clusters are backed up using cloud provider snapshots. Notab
73
75
74
76
|===
75
77
76
-
* Red Hat SRE rehearses recovery processes quarterly.
77
78
* Red Hat does not commit to any Recovery Point Objective (RPO) or Recovery Time Objective (RTO).
78
-
* Customers should take regular backups of their data.
79
-
* Backups performed by SRE are taken as a precautionary measure only. They are stored in the same region as the cluster.
80
-
* Customers can access SRE backup data on request by opening a support case.
81
-
* Red Hat highly encourages customers to deploy multi-AZ clusters with workloads that follow Kubernetes best practices to ensure high availability within a region.
82
-
* In the event an entire cloud region is unavailable, customers must install a new cluster in a different region and restore their apps using their backup data.
83
-
79
+
* Customers are responsible for taking regular backups of their data
80
+
* Customers should deploy multi-AZ clusters with workloads that follow Kubernetes best practices to ensure high availability within a region.
81
+
* 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.
Copy file name to clipboardExpand all lines: modules/rosa-aws-provisioned.adoc
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -50,7 +50,7 @@ Up to two Network Elastic Load Balancers (ELBs) for API and up to two Classic EL
50
50
51
51
[id="rosa-s3-storage_{context}"]
52
52
== S3 storage
53
-
The image registry and Elastic Block Store (EBS) volume snapshots are backed by AWS S3 storage. Pruning of resources is performed regularly to optimize S3 usage and cluster performance.
53
+
The image registry is backed by AWS S3 storage. Pruning of resources is performed regularly to optimize S3 usage and cluster performance.
== Backup and recovery for ROSA clusters without STS
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:
50
51
51
-
All {product-title} clusters are backed up using AWS snapshots. Notably, this does not include customer data stored on persistent volumes (PVs). All snapshots are taken using the appropriate AWS snapshot APIs and are uploaded to a secure AWS S3 object storage bucket in the same account as the cluster.
52
+
//Verify if the corresponding tables in rosa-sdpolicy-platform.adoc and policy-incident.adoc also need to be updated.
52
53
53
54
[cols= "3a,2a,2a,3a",options="header"]
54
55
@@ -58,34 +59,31 @@ All {product-title} clusters are backed up using AWS snapshots. Notably, this do
58
59
|Retention
59
60
|Notes
60
61
61
-
.2+|Full object store backup, all SRE-managed cluster PVs
62
+
.2+|Full object store backup, all cluster persistent volumes (PVs)
62
63
|Daily
63
64
|7 days
64
-
.2+|This is a full backup of all Kubernetes objects, such as etcd, and all SRE-managed PVs in the cluster.
65
+
.2+|This is a full backup of all Kubernetes objects like etcd, as well as all PVs in the cluster.
65
66
66
67
|Weekly
67
68
|30 days
68
69
69
70
70
71
|Full object store backup
71
72
|Hourly
72
-
|24-hour
73
-
|This is a full backup of all Kubernetes objects, such as etcd. No PVs are backed up in this backup schedule.
73
+
|24hour
74
+
|This is a full backup of all Kubernetes objects like etcd. No PVs are backed up in this backup schedule.
74
75
75
76
|Node root volume
76
77
|Never
77
78
|N/A
78
-
|Nodes are considered to be short-term. Do not store anything critical on a node's root volume.
79
+
|Nodes are considered to be short-term. Nothing critical should be stored on a node's root volume.
79
80
80
81
|===
81
82
82
-
- Red Hat rehearses recovery processes periodically.
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
-
- Backups performed by the SRE are taken as a precautionary measure only. They are stored in the same region as the cluster.
86
-
- Customers can access the SRE backup data on request through a support case.
87
-
- Red Hat encourages customers to deploy multiple availability zone (multi-AZ) clusters with workloads that follow Kubernetes best practices to ensure high availability within a region.
88
-
- In the event an entire AWS region is unavailable, customers must install a new cluster in a different region and restore their apps using their backup data.
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.
Copy file name to clipboardExpand all lines: modules/rosa-sdpolicy-platform.adoc
+17-15Lines changed: 17 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -19,34 +19,36 @@ It is critical that customers have a backup plan for their applications and appl
19
19
====
20
20
21
21
Application and application data backups are not a part of the {product-title} service.
22
-
All Kubernetes objects and persistent volumes (PVs) in each {product-title} cluster are backed up to facilitate a prompt recovery in the unlikely event that a cluster becomes irreparably inoperable.
22
+
The following table outlines the cluster backup policy.
23
23
24
-
The backups are stored in a secure object storage, or multiple availability zone, bucket in the same account as the cluster.
25
-
Node root volumes are not backed up, as Red Hat CoreOS is fully managed by the {product-title} cluster and no stateful data should be stored on a node's root volume.
24
+
//Verify if the corresponding tables in policy-incident.adoc and rosa-policy-incident.adoc also need to be updated.
26
25
27
-
The following table shows the frequency of backups:
28
-
[cols="4",options="header"]
29
-
|===
26
+
[cols= "3a,2a,2a,3a",options="header"]
30
27
28
+
|===
31
29
|Component
32
30
|Snapshot frequency
33
31
|Retention
34
32
|Notes
35
33
36
-
|Full object store backup, all cluster PVs
37
-
|Daily at 0100 UTC
34
+
.2+|Full object store backup, all cluster persistent volumes (PVs)
35
+
|Daily
38
36
|7 days
39
-
|This is a full backup of all Kubernetes objects, as well as all mounted PVs in the cluster.
37
+
.2+|This is a full backup of all Kubernetes objects like etcd, as well as all PVs in the cluster.
40
38
41
-
|Full object store backup, all cluster PVs
42
-
|Weekly on Mondays at 0200 UTC
39
+
|Weekly
43
40
|30 days
44
-
|This is a full backup of all Kubernetes objects, as well as all mounted PVs in the cluster.
41
+
45
42
46
43
|Full object store backup
47
-
|Hourly at 17 minutes past the hour
48
-
|24 hours
49
-
|This is a full backup of all Kubernetes objects. No PVs are backed up in this backup schedule.
44
+
|Hourly
45
+
|24 hour
46
+
|This is a full backup of all Kubernetes objects like etcd. No PVs are backed up in this backup schedule.
47
+
48
+
|Node root volume
49
+
|Never
50
+
|N/A
51
+
|Nodes are considered to be short-term. Nothing critical should be stored on a node's root volume.
0 commit comments