Closed AJRepo closed 9 years ago
Hi @AJRepo. That's a good point. Originally, I wanted to keep backup files linked as I wanted to consolidate them before restoring them. The restoring part/script has never been implemented, tho... So it's now pointless.
Cool. I submitted commit 2e33677249998eb5eae2a53cbbea1782edaf9207 to remove that command. I'll do a pull request in a bit.
In looking at restore procedures I found libvirt ( http://wiki.apparmor.net/index.php/Libvirt ) changes /etc/apparmor.d/libvirt/libvirt-DOMID.files to deny writes to the backing file and updates apparmor to only allow writes to the current disk image. So a restore under a system that uses apparmor would need to keep the file naming and structure as-as, or modify the apparmor files. If it's ok, I'll play around with some restore and consolidation tests and let you know what I find, but you can close this issue.
That'd be great. Thanks @AJRepo .
Thanks again for a nice program. If I've read the code right, I see that there is a rebasing of the backing files in the backup directory which stores the full path to that source in the backup directory.
So you currently have
I think that would make sense if you ran the VM in the backup directory, but in the case of a disaster recovery (DR) you'd put the backup files back in their original location, not run from the backup directory (which might potentially cause an issue anyway as this script would then be backing up the VM from and to the same directory).
So I think it might make more sense to not rebase the backup files. What do you think?