Additional Backup Strategies

[truelai]

Feature request for and additional backup strategy

Currently, there is only one choice: Backup & Import

I request you consider 2 additional options: Backup on Remote (only backup on remote host) Import Latest Remote Backup (if remote tarball hash does not match already imported tarball hashes)

Reasoning

Scenario 1 - Multiple LxdMosaic instances

If users are running multiple instances, they may want to schedule an import of a remote backup that was triggered by another Mosaic instance. In my case, mosaic1's scheduler triggers an export on lxd1 of c1. mosaic1 imports that tarball per the scheduler. mosaic2, an offsite instance (used for disaster recovery) also wants the same tarball but doesn't need or want to trigger a new gzip event with the associated io on lxd1. I would like mosaic2 to be able to schedule the importation of lxd1's latest tarball of c1. Currently, I cannot use the gui to do this.

Additionally, different mosaic servers may have different purposes (onsite backup, offsite backup, production, dev, special projects, etc.) Using a single instance to only schedule remote backups makes sense if multiple hosts may want to import those backups. For example, c1 is a production container on lxd1. On mosaic1, mosaic3, mosaic5, and mosaic6 I would want to schedule only import of the latest tarball available (provided the mosaic host doesn't already have it). In this case, I want to use mosaic0 to schedule remote backups (without import) instead of having the schedules be fragmented across the mosaic instances.

Scenario 2 - Export schedules controlled by hosts themselves

Let's assume Mosaic is being used in an enterprise where LXD hosts or groups of hosts in an LXD project are controlled by different workgroups. Allowing each team to use their own scripts/crons/management system to schedule their own exports on their hosts may be desirable as the export is generally more costly than the transfer (import). In this case, where teams are scheduling local backups on the hosts they use, while there may be tarballs for mosaic to import, there is no way to use the gui to schedule the importation of those tarballs.

[turtle0x1]

Honestly the setup doesn't sound quite right, LXDMosaic is a "1 per datacenter" product, but I think the lack of permission models is letting it down in this use case,

Would it be fair to say, if the permission models were correct you would add production, dev, special projects & others to one LXDMosaic instance? (having all those users on different severs must be painful - you must want #171 quite bad)

If I added the permission models & a "backup copy job" (a server LXDMosaic can rsync to) would I solve 90% of the problems here?

[truelai]

Heh. Well, permissions would be great. But I didn't think to ask for such a feature when there isn't yet a "logout" function/

For the enterprise scenario, this would suffice, I'm sure.

For my scenario, I'd still want separate backup strategies. The reason is space.

For a number of containers, my backups are not often and are only there for real disaster (DC burns to the ground). In my offsite mosaic, I am holding all images of all servers (offsite is built with more storage because of this). Onsite, I keep backups for quick up and downs of certain containers across local hosts. I have smaller storage onsite.

For "where to store what" problem, another approach would be to have more than one backup path (where I'd have one path on the local filesystem and have the other on a mounted remote filesystem).