backup-vm
backup-vm copied to clipboard
milkey-mouse
Alternative backup engines
I'm currently evaluating a couple of other backup engines which implement public key crypto e.g. https://github.com/dpc/rdedup and I'd like to adapt backup-vm to work with this.
This could either be a fork which shares some of the same code (but no longer supports borg), or a version of backup-vm which supports both backup systems (probably more work in the short term, but better in the long term). It's not really clear to me which would be preferable.
Any thoughts?
I hadn't thought of that when building the Borg "engine," but it seems like it would be pretty easy to do. In its current state backup-vm essentially does the snapshot, builds a folder full of symlinks to the disks, and runs borg in that directory:
https://github.com/milkey-mouse/backup-vm/blob/442ce385ca66fb254105ce566dfcdf3fe36da7b8/backup_vm/backup.py#L49-L54
So ostensibly you could replace the call to multi.assimilate on line 54 with something that can control another backup program, which could be as simple as for location in archives: subprocess.run(["backup", str(archive)]).
One thing that would need refactoring is that assimilate takes Location objects (the definition of which was pretty much copied straight out of the Borg source) for CLI validation. A more general approach could be an abstract base class for backup locations that can be validated.
I would not be opposed to merging a PR that adds this feature; I don't think a fork is needed.
OK, thanks. I'm currently knocking up a rough proof of concept.
The biggest stumbling block is that both rdedup and restic don't have equivalents to the --read-special option, both support reading block device data from stdin only, so I'm looking at a couple of different workarounds for that...
Why can't you just let them loose on the folder full of symlinks it creates? I don't think I'm even using --read-special at the moment, block devices are treated the same as files. (Such direct reading would only be implemented as part of #18).