NuKVM/xen-orchestra
3
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

remove useless images

Browse Source
This commit is contained in:
Olivier Lambert 2016-09-13 12:20:08 +02:00
parent dc51545583
commit 31846074a2
3 changed files with 8 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/continuous_replication.md
View File

@ -1,12 +1,8 @@
# Continuous Replication
> This feature is released since 4.12
> WARNING: it works only on XenServer 6.5 or later
> WARNING 2: this feature is very new, use it with caution until 4.13
This feature allow continuous replication system for your XenServer VMs without any storage vendor lock-in. You can now replicate a VM every xx minutes/hours on a any storage repository. It could be on a distant XenServer host or just another local storage.
This feature allow continuous replication system for your XenServer VMs **without any storage vendor lock-in**. You can replicate a VM every xx minutes/hours on a any storage repository. It could be on a distant XenServer host or just another local storage.
This feature covers multiple objectives:
@ -26,9 +22,7 @@ If you lose your main pool, you can start the copy on the other side, with very
## Configure it
As you'll see, this is trivial to configure. Inside the "Backup" section, select "Continuous Replication":
![](https://xen-orchestra.com/blog/content/images/2016/01/continuous_replication.png)
As you'll see, this is trivial to configure. Inside the "Backup/new" section, select "Continuous Replication".
Then:
@ -36,19 +30,14 @@ Then:
1. Schedule the replication interval
1. Select the destination storage (could be any storage connected to any XenServer host!)
![](https://xen-orchestra.com/blog/content/images/2016/01/continuous_replication2.png)
> In this case, we'll replicate 2 VMs to "NFS" SR which is a pool called "Other Pool". Replication will happen every 20 minutes.
That's it! Your VMs are protected and replicated as requested.
To protect the replication, we removed the possibility to boot your copied VM directly, because if you do that, it will break the next delta. The solution is to clone it if you need it (a clone is really quick). You can do whatever you want with this clone!
## Initial seed
## Manual initial seed
If you can't transfer the first backup through your network, you can make a seed locally. In order to do this, follow this procedure (until we made it accessible directly in XO):
### Preparation
1. create a cont. rep job to a non-distant SR (even the SR where is currently the VM). Do NOT enable the job at the creation.

14
docs/delta_backups.md
View File

@ -1,10 +1,8 @@
# Continuous Delta backups
> This feature is released since 4.11 and "Continuous" feature since 4.12
> WARNING: it works only on XenServer 6.5 or later
You can export only the delta between your current VM disks and a previous snapshot (called here the *reference*). They are called continuous because you'll **never export a full backup** after the first one.
You can export only the delta between your current VM disks and a previous snapshot (called here the *reference*). They are called *continuous* because you'll **never export a full backup** after the first one.
## Introduction
@ -16,9 +14,7 @@ It means huge files for each backups. Delta backups will only export the differe
![](https://xen-orchestra.com/blog/content/images/2015/12/delta_final.png)
Basically, you'll create "key" backups (full backup) and use delta from those. It's the same principle for [MPEG compression and key frame](https://en.wikipedia.org/wiki/Key_frame#Video_compression).
You can imagine to make a full backup during a weekend, and only delta backups every night. It combines the flexibility of snapshots and the power of full backups, because:
You can imagine to make your first initial full backup during a weekend, and then only delta backups every night. It combines the flexibility of snapshots and the power of full backups, because:
* delta are stored somewhere else than the current VM storage
* they are small
@ -43,8 +39,4 @@ This way we can go "forward" and remove this oldest VHD after the merge:
## Create Delta backup
Just go inside your "Backup" view, and select Delta Backup:
![](https://xen-orchestra.com/blog/content/images/2015/12/delta_menu.png)
Then, create in like a normal backup.
Just go inside your "Backup" view, and select Delta Backup. Then, it's like a normal backup.

12
docs/disaster_recovery.md
View File

@ -1,7 +1,5 @@
# Disaster recovery
> DR is available since 4.9
Disaster Recovery (DR) regroup all the means 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.
@ -16,15 +14,9 @@ To avoid a potentially very long import process (restoring all your backup VMs),
![](https://xen-orchestra.com/blog/content/images/2015/10/newsolution.png)
## 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 pool.
![](https://xen-orchestra.com/blog/content/images/2015/11/DRexample.png)
**Warning**: you should have a default SR configured on your targeted pool.
Planning a DR task is very similar to plan a backup or a snapshot. The only difference is that you choose a destination storage.
You DR VMs will be visible "on the other side" as soon the task is done.
@ -40,4 +32,4 @@ Also, by default, the DR VM will have a "Disaster Recovery" tag.
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 problems is to remove the network interface and check if the export is correctly done.