Skip to main content

Mirror Backups

The goal is to replicate a backup from one backup repository (BR, formerly called remote) to another. For instance, you make your backup to in-house NFS storage, and then replicate to bigger, slower and cheaper storage with a longer retention.

The source and destination can have different settings for encryption, VHD storage mode, retention, or compression.

A mirror backup is a backup of your backups: XO reads the archives already stored on the source BR and copies the new ones to the destination BR. The VM and the hosts are never involved in the transfer:

Xen OrchestraorchestratesVMbackup jobSource BRfast storage, short retentionBCDmirrornew backups onlyDestination BRbigger, slower, cheaperABCDlonger retention: keeps more restore points
A mirror backup copies existing archives from one BR to another: the VM is only exported once by its normal backup job, then XO mirrors the archives to a bigger, slower, cheaper BR with a longer retentionbackup archivemirror transferXen Orchestra

Creation​

In the Backup view, create a new backup job and select Mirror backup. Then, choose whether you want to mirror incremental backups or full backups. A mirror backup job has exactly one source repository and one or more destinations. The mirroring speed is limited by the slowest repository.

Most options of the full/incremental backup jobs also apply here, like concurrency (number of VMs transferred in parallel), reports, proxy and speed limit. You can also add a health check on schedules. Please note that only the last transferred backup (if any) will be checked.

tip

If you have full and incremental backups on a repository, you must configure 2 mirror backup jobs, one full and one incremental.

Synchronizing algorithm for full backups​

Any new backup on the source is transferred to the destination. Each side then applies its own retention: the source window slides forward while the destination, with its longer retention, keeps one more restore point before deleting anything.

Source BR (retention 3)Destination BR (retention 4)run 1ABCA, B, CABCrun 2BCDD onlyABCDrun 3CDEE onlyAdeletedBCDErun 3: retention 4 exceeded, A is deleted
Three runs of a full mirror: each run copies only the new archive, the source window slides (retention 3) while the destination accumulates until its own retention of 4 forces the oldest archive outfull backuptransferdeleted on destination

Each letter is a full backup archive. The source has a retention of 3, the destination a retention of 4.

First transfer​

- source : ABC
- destination: empty

XO transfers A, then B, then C. The destination now contains ABC.

warning

Limitation: if the mirror retention is lower than the backup retention on the source repository, more data than necessary may be transferred during the first run, since all the backups of the source will be transferred to the destinations. Then the older backups will be purged on the destinations.

Second transfer​

- source : BCD
- destination: ABC

Only D is transferred. The destination now contains ABCD.

Third transfer​

- source : CDE
- destination: ABCD

Only E is transferred, and A is deleted from the destination because its retention of 4 is now exceeded. The destination now contains BCDE.

If there is too much change on the source​

- source : IJK
- destination:  BCDE

I, J and K are transferred in order, and B, C and D are deleted from the destination. The destination now contains EIJK.

Synchronizing algorithm for incremental backups​

This job only transfers new backups, then runs the same merge algorithm as Incremental Backups on the destination. Since each side applies its own retention, the merges happen independently: the source merges sooner (retention 3), the destination later (retention 4).

Source BR (retention 3)Destination BR (retention 4)run 1AbcA, b, cAbcrun 2BcdA + b merged into Bd onlyAbcdno merge: retention 4 not exceededrun 3CdeB + c merged into Ce onlyBcdeA + b merged into BEach BR merges independently: the destination merges one run later because its retention is longer
Three runs of an incremental mirror: only the new deltas cross the wire, and each BR merges its own chain when its own retention is exceeded, the source after run 1, the destination one run laterkey (full) backupdeltatransfer

Key (full) backups are in uppercase, delta backups in lowercase. The source has a retention of 3, the destination a retention of 4.

First transfer​

- source : Abc # one key, two delta
- destination: empty

XO transfers A, then b, then c. The destination now contains Abc.

warning

Limitation: if the mirror retention is lower than the backup retention on the source repository, more data than necessary may be transferred during the first run, since all the backups of the source will be transferred to the destinations. Then the older backups will be purged on the destinations.

Second transfer​

- source : Bcd # A and b have been merged
- destination:  Abc

Only the delta d is transferred. The destination now contains Abcd (no merge yet: its retention of 4 is not exceeded).

Third transfer​

- source : Cde # B and c have been merged
- destination:  Abcd

Only the delta e is transferred. The destination now contains Bcde (A is merged into b on the destination).

If there is too much change on the source​

- source : Ijk
- destination:  Bcde

The whole chain is transferred in order. The destination now contains EIjk (B, c and d are merged into e).