grammar updates v12 (#134)
* Clarification, update links, organize * add nfs warning, fix debian version * add ENOSPC troubleshooting * add more enospc detail * add note on editing username * Documentation typo/grammar cleanup part 9 * grammar cleanup v10 * grammar editing v10 * grammar updates v11 * Grammar updates v11
This commit is contained in:
parent
2e74f87ae0
commit
95252be5f0
@ -1,35 +1,35 @@
|
||||
# Disaster recovery
|
||||
|
||||
Disaster Recovery (DR) regroups all the means to recover after losing hosts or storage repositories.
|
||||
Disaster Recovery (DR) encompasses all the ways to recover after losing hosts or storage repositories.
|
||||
|
||||
In this documentation, we'll only see the technical aspect of DR, which is a small part of this vast topic.
|
||||
In this guide we'll only see the technical aspect of DR, which is a small part of this vast topic.
|
||||
|
||||
## Best practices
|
||||
|
||||
We strongly encourage you to read some literature on this very topic. Basically, you should be able to recover from a major disaster within appropriate amount of time and minimal acceptable data loss.
|
||||
We strongly encourage you to read some literature on this topic. Basically, you should be able to recover from a major disaster within an appropriate amount of time and minimal acceptable data loss.
|
||||
|
||||
To avoid a potentially very long import process (restoring all your backup VMs), we created a specific feature, made possible thanks to the XO capability to [stream export and import on the same time](https://xen-orchestra.com/blog/vm-streaming-export-in-xenserver/).
|
||||
To avoid a potentially very long import process (restoring all your backup VMs), we implemented a streaming feature. [Streaming allows exporting and importing at the same time](https://xen-orchestra.com/blog/vm-streaming-export-in-xenserver/).
|
||||
|
||||
**The goal is to have your DR VMs ready to boot on a dedicated host. This is also a mean to check if you export was fine (if the VM boots).**
|
||||
**The goal is to have your DR VMs ready to boot on a dedicated host. This also provides a way to check if you export was successful (if the VM boots).**
|
||||
|
||||

|
||||
|
||||
## Schedule a DR task
|
||||
|
||||
Planning a DR task is very similar to plan a backup or a snapshot. The only difference is that you choose a destination storage.
|
||||
Planning a DR task is very similar to planning a backup or a snapshot. The only difference is that you select a storage destination.
|
||||
|
||||
You DR VMs will be visible "on the other side" as soon the task is done.
|
||||
|
||||
### Retention
|
||||
|
||||
Retention, or **depth**, will apply with the VM name. **If you change the VM name for any reason, it won't be rotated anymore.** This way, you can play with your DR VM without fearing to lose it.
|
||||
Retention, or **depth**, applies to the VM name. **If you change the VM name for any reason, it won't be rotated anymore.** This way, you can play with your DR VM without the fear of losing it.
|
||||
|
||||
Also, by default, the DR VM will have a "Disaster Recovery" tag.
|
||||
|
||||
> **Size warning**: high retention number will lead to huge space occupation on your SR.
|
||||
> **Size warning**: A high retention number will lead to huge space occupation on your SR.
|
||||
|
||||
## Network conflicts
|
||||
|
||||
If you boot a copy of your production VM, be careful: if they share the same static IP, you'll have troubles.
|
||||
|
||||
A good way to avoid this kind of problems is to remove the network interface and check if the export is correctly done.
|
||||
A good way to avoid this kind of problem is to remove the network interface on the DR VM and check if the export is correctly done.
|
||||
|
@ -1,19 +1,21 @@
|
||||
# File level restore
|
||||
|
||||
You can restore individual files against a whole VM. And it works on all your existing delta backups.
|
||||
You can also restore individual files inside a VM. It works with all your existing delta backups.
|
||||
|
||||
> You must use the latest XOA release. When you connect with the console, you should see `Build number: 16.12.20`. If you have this or higher (eg `17.*`), it means that's OK! Otherwise, please download your new XOA.
|
||||
> You must use the latest XOA release. When you connect with the console, you should see `Build number: 16.12.20`. If you have this or higher (eg `17.*`), it means that's OK! Otherwise, please update your XOA.
|
||||
|
||||
> Restore files from a SMB remote is not yet possible, but it's planned for the next release!
|
||||
> Restoring individual files from an SMB remote is not yet possible, but it's planned for the future!
|
||||
|
||||
> File level restore **is only possible on delta backups**
|
||||
|
||||
## Restore a file
|
||||
|
||||
Go into Backup/File restore section:
|
||||
Go into the Backup/File restore section:
|
||||
|
||||

|
||||
|
||||
Then, click on the VM where your files are, and follow the instructions:
|
||||
|
||||

|
||||
|
||||
That's it! Your chosen file will be restored.
|
@ -2,10 +2,10 @@
|
||||
|
||||
There are two ways to select which VMs will be backed up:
|
||||
|
||||
1. Multiple VM selector
|
||||
1. Manually selecting multiple VM's
|
||||
1. Smart backup
|
||||
|
||||
Picking VMs manually can be a limitation if you environment is moving fast (i.e. having new VMs you need to backup often), Because you needed to edit the previous job and add it.
|
||||
Picking VMs manually can be a limitation if your environment moves fast (i.e. having new VMs you need to backup often). In that situation you would previously need to constantly go back and edit the backup job to add new VM's.
|
||||
|
||||
But thanks to *smart backup*, you now have more flexibility: you won't select specific VMs, but VMs status/tag/placement **at the time backup job will be executed**. Let's see some examples!
|
||||
|
||||
@ -15,9 +15,9 @@ This job will backup all VMs on a pool "Lab Pool" when scheduled:
|
||||
|
||||

|
||||
|
||||
It means: **every VM existing on this pool at the backup schedule will be backup**. Doesn't matter if you create a new VM, it will be backup too without editing any backup job.
|
||||
It means: **every VM existing on this pool at the time of the backup job will be backed up**. Doesn't matter if you create a new VM, it will be backed up too without editing any backup job.
|
||||
|
||||
**You can now plan a smart backup on a production pool when only important VMs are**.
|
||||
**You now have the ability to intelligently backup VM's in production pools!**
|
||||
|
||||
Want to narrow the job a bit? See below.
|
||||
|
||||
@ -26,9 +26,9 @@ Want to narrow the job a bit? See below.
|
||||
You can also:
|
||||
|
||||
* backup only running (or halted) VMs when the job is executed
|
||||
* backup only VMs with a tag
|
||||
* backup only VMs with a specific tag
|
||||
|
||||
Remember the Prod VMs? I added a tag "prod" for each of them:
|
||||
Remember the Prod VMs? I added a tag "prod" to each of them:
|
||||
|
||||

|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user