The problem I am addressing: Currently `qvm-backup` does not support making backups without encryption. It is obviously was made intentionally, like 5 years ago. I hope for a discussion should it be reconsidered, for these reasons:
1. The most important point - encryption prevents both **de-duplication** and proper **compression** (see example below). 2. If backup is already stored on encrypted partition or disk mounted to offline target/output VM, then the password used in `qvm-backup` is not adding much of additional security, only makes everything slower and adds battery-drain. 3. Even worse, if user uses automatic backup process, they **have** to store the password somewhere in file in **plain-text**. In the best case it is some temporary password just because Qubes OS needs it, but it also can be some actually important password that user may be using in other places (users tend to do this). In this case it even reduces security, passwords must be kept in password manager, not plain-text. User case-example for bad compression with current `qvm-backup`: * Let consider, that user has several qubes with Windows for different purposes, e.g. 10 VMs. Let's say, compressed Windows VM takes like 10 GiB. * Currently, if user makes backup of all 10 VMs one by one they get 100 GiB backup (**10 * 10 GiB**). * I checked that making backup of all 10 VMs together will make a 100 GiB backup. So, compression is completely not using similar parts of these VMs! And these VMs are like 90% the same. So, it could be like 15 GiB for all 10 qubes. => If there were not obligatory encryption, the user would make backup in any of these 2 ways and than pack it with `lzma` with huge dictionary as whole or some deduplication tool, making it ~ 12-15 GiB in total, so **making the backup almost 10 times smaller**. At least as I see it. And it is a case not only for Windows VMs, but for all data and all qubes, including fedora-based templates and hvms, and even common user data in all qubes. Over all, I think the points are quite convincing. I see no strong reasons why it has to be obligatory in the first place. Maybe we can discuss this decision and reconsider if possible? ### The solution I'd like * Make encryption in `qvm-backup` optional again. * Still keep it on by default, but allow to disable it. Nothing will be changed nor broken for users. * Maybe GUI program `qubes-backup` should still force encryption, because it targets less advanced users. ### The value to a user, and who that user might be * Proper compression (multiple times better backup size), * De-duplication by third-party tools, * People on forum request it from time to time, too, e.g.: https://forum.qubes-os.org/t/making-qubes-os-backups-more-efficient/18680/2 Best regards, jamke -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/NZPQRld--3-9%40tutanota.com.
