Hello, I'd like to announce my PoC for incremental file-based backup for Qubes VMs. It is not a completely new backup system, it just wires together some existing software with Qubes principles to provide convenient and secure way to backup many VMs with minimum overhead and encrypt them by one password. I have tried hard not to expose dom0 to untrusted inputs from VMs. Design is described in README, though I will probably break README to multiple parts. Sources are here:
https://github.com/v6ak/qubes-incremental-backup-poc/ Now, I'd like to collect feedback on this. Whether you want to try it or just discuss or review the design without trying, you are welcome. Even if you think that the design is a complete crap, you are welcome: You might have a good point that I would like to know in this early stage. Short QA: Q: Why should I prefer this way to current Qubes backup mechanism? A: * Efficiency. Incremental backups can lower the backup size dramatically. File-based backups skip unused space, so it is even more efficient. And last but not least, file-based backup allows you to exclude ~/.cache and other stuff you don't want to backup. * Comfort: The builtin backup does not handle storage. My approach allows you to automatically upload it to various storages. Q: How much is it stable? A: Well, I just got it working. Don't rely on it too much, please. The backup format also might change a bit, so using it in production might require reviewing commit messages. Q: How much is it secure? A: There was nontrivial effort to design it securely and implement it securely. In both areas are some improvable places (e.g., non-processing UTF-8 in dom0 or better authentication of files), but I hope it is reasonably secure. There are some potential minor leaks, mostly through error messages. Q: I don't like Duplicity for some reason. Can I use something else instead? A: Well, the code is modular enough, so that implementing some other backup backend should not be hard. On the other hand, no other current backend is implemented at the moment. If you have some suggestion, you are welcome. If you want to write some other backend, you are also welcome, but maybe you will want to wait a while until things are more stable. Q: What backup backends are suitable for this scheme? A: The most crucial part is splitting the backup process into two parts. One process runs in a DVM, but it does not have the access to the backup storage. Second process runs in a BackupStorageVM, but it does not have access to the filesystem you want to backup. Those two processes are connected through qrexec. Q: Can I backup VM that is running? A: If you have LVM-based private.img, you can. (See README for details.) If you have standard file-based private.img, you cannot. I don't plan to implement this feature for file-based private.img, because Qubes 4.0 will use LVM, so they don't seem to have a long future. Q: What is the code quality? A: Short answer: PoC. Long answer: Some parts look like a Bash script rewritten to Python (which is in few cases how it actually has happened), but I believe I can iteratively improve the suboptimal cases. Especially exception handling is something neglected – I am aware of Exceptions and the code expects them to some degree (using finally blocks etc.), but they are rarely reported to user in a friendly way. They usually bubble to the top level, so stacktrace is dumped. Regards, Vít Šesták -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/901b82dc-f781-4c13-ad00-33b4337fc84a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
