Skip to content

Commit 355d40f

Browse files
committed
Merge branch 'main' into sto2hs
2 parents 862a23e + 4357683 commit 355d40f

40 files changed

Lines changed: 135 additions & 80 deletions

docs/background/.pages

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,6 @@ nav:
44
- "CCMP vs. OpenStack API": gui-vs-api.md
55
- "Deleting projects": project-deletion.md
66
- "Object storage": object-storage.md
7-
- "Disaster recovery": disaster-recovery.md
7+
- "Recovery service": recovery-service.md
88
- kubernetes
99
- Marketplace: marketplace.md
10.9 KB
Loading
-222 KB
Loading
198 KB
Loading

docs/background/disaster-recovery.md

Lines changed: 0 additions & 41 deletions
This file was deleted.
Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,58 @@
1+
---
2+
description: What is the recovery service feature and why you want it
3+
---
4+
# Recovery service
5+
6+
When you [create a new server](../howto/openstack/nova/new-server.md) in {{brand}} you will notice an option named **Recovery service**, which is enabled by default.
7+
8+
![Recovery service is enabled by default for new servers](assets/disaster-recovery-option-on-by-default.png)
9+
10+
Even if you choose to disable it for a particular server, keep in mind that you have the option to enable it at a later time.
11+
12+
![The recovery service feature can be manually activated for any server](assets/disaster-recovery-option-manual-activation.png)
13+
14+
In the following, we explain what this option does, how it works in the background, and why you should consider enabling it.
15+
16+
## What it is
17+
18+
The *recovery service* feature is available via the {{gui}} and applies to servers and volumes that use our [Ceph](https://docs.ceph.com/) backend.
19+
That would be **all** servers but the ones of the `s` [flavor](../reference/flavors/index.md#compute-tiers).
20+
21+
## How it works
22+
23+
As soon as you enable the recovery service for a server or a single volume, you start getting snapshots for the corresponding [*RADOS Block Device* (RBD)](https://docs.ceph.com/en/latest/glossary/#term-Ceph-Block-Device) image.
24+
25+
Those snapshots are created automatically once per day.
26+
By default, you have the snapshots of the last 10 days.
27+
Optionally, you may choose to keep snapshots for the past 30 days.
28+
The cost of a 30-day snapshot retention is 2× (**not** 3×) the cost of a 10-day snapshot retention.
29+
30+
You can also make the snapshots immutable.
31+
In that case, you will not be able to delete snapshots during the retention period manually.
32+
33+
Keep in mind that you cannot delete a volume with snapshots.
34+
So, as an example, if you have chosen a retention period of 30 days and also enabled immutability, then you will not be able to delete the volume before 30 days have passed.
35+
36+
At any time, you may disable the recovery service, modify the retention period, or disable immutability for snapshots.
37+
38+
![Recovery service, retention period, and immutability controls](assets/recovery-service-controls.png)
39+
40+
Let's say, for instance, that you have enabled the recovery service and also the immutability feature for snapshots.
41+
At some point, you want to change the retention period or disable immutability altogether;
42+
you can do any of that.
43+
Later on, you decide you do not need the volume anymore;
44+
you disable the recovery service, wait for 10 or 30 days, and then delete the volume.
45+
46+
## Why enable it
47+
48+
Provided snapshots are available, you can restore a server or a single volume to any of those snapshots.
49+
For instance, you may discover that due to faulty application logic or simply a bug, you are now experiencing data corruption.
50+
Then, one of your options would be to [go back in time](../howto/openstack/nova/restore-srv-to-snap.md) by restoring one of the available snapshots and keep going from there.
51+
52+
## Restoration time
53+
54+
You should know that the recovery service feature creates *point-in-time* snapshots on the storage level.
55+
The time required to restore a server to a particular snapshot depends on its size.
56+
During restoration, the server is shut off.
57+
After the restore, you need to power the server back on manually.
58+
Although this whole process takes time analogous to volume size, as we pointed out, we should also note that it only takes seconds to complete on average.
297 KB
Loading
45 KB
Loading
202 KB
Loading
93.8 KB
Loading

0 commit comments

Comments
 (0)