Reconsider obligatory encryption for qvm-backup to make backups much smaller

[jamke]

How to file a helpful issue

The problem you're addressing (if any)

Currently qvm-backup does not support making backups without encryption.
It is obviously was made intentionally.
I propose to reconsider this approach, for these reasons:

1. The most important point - encryption prevents both de-duplication and proper compression (see example below).
2. If backup is stored on encrypted partition or disk - the password used in qvm-backup is not adding any 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 "dummy"/simple password just because Qubes OS needs it, but it also can be some actually important password that user may be using in other places. In this case it is even reducing security, passwords must be kept in password manager, not plain-text.

User case-example for bad compression of 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 reasons why it has to be obligatory in the first place. Maybe we should discuss this decision and reconsider if possible?

The solution you'd like

• Make encryption in qvm-backup optional.
• 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

[rustybird]

See #4308 (comment), especially this part:

right now encryption and integrity protection is done in the same step (using scrypt tool). And we definitely don't want to allow not integrity protected backups.

[jamke]

@rustybird thank you for the link. If was 5 years ago, maybe it is time to reconsider.
The decision of connecting integrity and encryption is not such a good design for multiple reasons I provided in the first post. At least not optimal, not from security point of view, nor saving user's disk space.

Maybe, it is a good thing to allow users to compress and encrypt their backups better that Qubes OS does. It can be done in some offline VM or even dom0, according to issues users want it for so many years.
And for usual user, who is not aware of technical details the behavior will stay the same.

[DemiMarie]

@jamke I believe (@marmarek correct me if I am wrong) that the Qubes team wants to eventually include @tasket’s Wyng Backup. That provides proper incremental backups without losing security.

[andrewdavidwong]

Duplicate of #4308

[andrewdavidwong]

This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If anyone believes this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

[jamke]

@jamke I believe (@marmarek correct me if I am wrong) that the Qubes team wants to eventually include @tasket’s Wyng Backup. That provides proper incremental backups without losing security.

@DemiMarie that would be great, the project of @tasket looks quite nice and interesting.

Nonetheless, I was hoping for some discussion, at least small, if it is a good idea to reconsider this decision from 2018, because a lot of time passed and I am not sure that it was right. I do not see problems in giving back the ability to create unencrypted backups that will be processed (compressed, encrypted and etc) by the users themselves in a better way than Qubes OS currently can.

It is unfortunate that the issue was closed without discussion the points I spend time providing in the first post.

[andrewdavidwong]

Nonetheless, I was hoping for some discussion

Please note that the issue tracker (qubes-issues) is not intended to serve as a discussion venue. Instead, we've created a designated forum for discussion and support. (By contrast, the issue tracker is more of a technical tool intended to support our developers in their work.) Thank you for your understanding!

It is unfortunate that the issue was closed without discussion the points I spend time providing in the first post.

That's because you posted it in the wrong place. As I wrote above:

This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If anyone believes this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.

Closing an issue as a duplicate isn't a statement about the content of the issue. It's a statement about whether the issue seems to be a duplicate.

If you want a closed issue to be reconsidered or reopened, then post your comment on that issue. But, in this case, since you want a discussion about a design decision, it would probably be even better to post on qubes-devel or the forum.

[jamke]

@andrewdavidwong OK, thank you.