Backup from replicas possible?

john.c

@florent Yes definitely sounds a very amazing idea. Though this may be a bit odd, but there's businesses that still use tape cartridge based backups.

How do you handle those in regards to backup of VMs via XO on XCP-ng?

flakpyro

@florent Thats great news! We use both Borg and Veeam so that's where most of these ideas are coming from. Having GFS backups like you mention for weekly, monthly, yearly would also be awesome to have and something we make use of in Veeam currently.

john.c

@flakpyro said in Backup from replicas possible?:

@florent Thats great news! We use both Borg and Veeam so that's where most of these ideas are coming from. Having GFS backups like you mention for weekly, monthly, yearly would also be awesome to have and something we make use of in Veeam currently.

I have volunteered at organisations where backup are being with this kind of cadence. Though some times the Friday backup would be queued up to run at midnight on Saturday morning, if there's activity planned or happening which would affect the backup proceeding on late night Friday.

florent

@john-c said in Backup from replicas possible?:

@florent Yes definitely sounds a very amazing idea. Though this may be a bit odd, but there's businesses that still use tape cartridge based backups.

How do you handle those in regards to backup of VMs via XO on XCP-ng?

For now we don't support tape backup. We know it is still used, especially since it gives a hardware guaranty of WORM, but regarding the huge work needed to make it work reliably, we plan to do it later. The challenges comes from the sequential nature of tape reading and writing that will mandate a huge code refactor, but also all the handling tools needed to locate the band containing a specific backup.
We're talking of the same scale as our import tool from vmware.

As always, priority can be adjusted, depending on market and user base needs Vs complexity.

john.c

@florent Would it be okay to open it as an issue on GitHub so the community developers can see it, that way can contribute by developing the functionality?

Though there's already libraries developed for developers to use which handle the grunt work of doing at least some of the work required to perform backups (accessing and working with the tape cartridges).

The only pieces of extra code then required to be developed are the NodeJS plugins which can use these libraries (or command line binary tools) and the Xen Orchestra tie ins.

https://packages.debian.org/bullseye/mt-st
https://packages.debian.org/bullseye/mtx
https://packages.debian.org/bullseye/stenc

florent

@john-c said in Backup from replicas possible?:

@florent Would it be okay to open it as an issue on GitHub so the community developers can see it, that way can contribute by developing the functionality?

Though there's already libraries developed for developers to use which handle the grunt work of doing at least some of the work required to perform backups (accessing and working with the tape cartridges).

The only pieces of extra code then required to be developed are the NodeJS plugins which can use these libraries (or command line binary tools) and the Xen Orchestra tie ins.

https://packages.debian.org/bullseye/mt-st
https://packages.debian.org/bullseye/mtx
https://packages.debian.org/bullseye/stenc

without these we wouldn't even be able to start working on it without building a dedicated team. There is still a lot of work to make it work. Especially the part we have to read and write sequentially.
Still, it's in our backlog, and not in the "one day maybe" part

john.c

@florent said in Backup from replicas possible?:

@john-c said in Backup from replicas possible?:

@florent Would it be okay to open it as an issue on GitHub so the community developers can see it, that way can contribute by developing the functionality?

Though there's already libraries developed for developers to use which handle the grunt work of doing at least some of the work required to perform backups (accessing and working with the tape cartridges).

The only pieces of extra code then required to be developed are the NodeJS plugins which can use these libraries (or command line binary tools) and the Xen Orchestra tie ins.

https://packages.debian.org/bullseye/mt-st
https://packages.debian.org/bullseye/mtx
https://packages.debian.org/bullseye/stenc

without these we wouldn't even be able to start working on it without building a dedicated team. There is still a lot of work to make it work. Especially the part we have to read and write sequentially.
Still, it's in our backlog, and not in the "one day maybe" part

@florent Additionally the tapes get listed like Linux block devices at the location of /dev. Though would require a filter to ensure that only tape drives are listed as option choices.

A good way to do it when you do would be as a plugin for Xen Orchestra backup functions. That way the process for performing the backup can occur in a sequential manner, within the plugin. Thus leaving the normal backup functions unaffected - still non-sequential (or abstracted).

At the moment is it possible to have plugins which extend Xen Orchestra's backup feature? If not may be a helpful addition as then plugins can be developed and used to provide functionality like this as well as other backup destination functionality, such as Microsoft Azure blob file storage functionality.

Also if necessary any client and/or customer specific plugins can then be developed, if their backup procedures are specialised in some way which the standard can't handle.

flakpyro

@florent Any news on this being added? I was not able to find anything about it on the Github. We are moving from XO from source to full XOA soon and our DR backup/replication plan will be one of the first things we need to get straightened out before we can totally move off of VMware and Veeam.

florent

@flakpyro said in Backup from replicas possible?:

@florent Any news on this being added? I was not able to find anything about it on the Github. We are moving from XO from source to full XOA soon and our DR backup/replication plan will be one of the first things we need to get straightened out before we can totally move off of VMware and Veeam.

Could you open a github issue to track this, or , if you have a XOA, open a a feature request ticket ?

In this thread I see 2 features :

adding a tag to a replicated VM, this should be quite easy
the lifecycle of the backup / replication , which is more work, but should be done this year

DustinB

replying to follow, FR created: 22844

flakpyro

Think this will make it into XO5 or is more likely to be an XO6 feature?

olivierlambert

It's kind of unrelated to XO 6 (especially point 2).

flakpyro

@olivierlambert Apologies, i thought adding the ability to add a tag to a replicated backup would be a feature added directly into XO as it handles backups in the Vates stack?

We are eagerly awaiting this functionality as it will allow us to do the same thing with XOA that we now do with Veeam. (Replicate to a DR site, then backup those replicas, keeping multiple restore points, onto long term ZFS backed backup repositories.)

Point 2 was not what i originally made this thread about, it came about afterwords from another forum user

olivierlambert

Adding a tag to a replicated backup should be trivial (we need to discuss the entire thing to be sure there's no obvious catch with @julien-f ).

DR automated fallback to the original site (re-sync) is planned for this year.

flakpyro

@olivierlambert we have our refreshed DR storage on order! (Replacing block only storage with another NFS capable array), as we close in on rebuilding our DR site i wonder if there has been any discussion on adding this feature? Being able to append a custom tag to a replication job would allow us to backup said replicas with the new GFS functionality to cheaper long term storage. This would in practice be pretty similar to what Veeam does with backing up from replicated storage snapshots but instead be totally hardware agnostic

florent

@flakpyro for now there is no tag selector , but you can now select the VM list to be replicated