Reconsider obligatory encryption for qvm-backup to make backups much smaller and more flexible
20 views
Skip to first unread message
jma...@tutanota.com
Jul 3, 2023, 2:25:56 AM7/3/23
to Qubes Devel
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
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
Metatron
Jul 13, 2023, 10:51:54 AM7/13/23
to jma...@tutanota.com, Qubes Devel
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/NZPQRld--3-9%40tutanota.com.
Completely agree with this. I too have missed the option to encrypt
backups.
I store all my backups on luks encrypted drives, the addtional
encryption is an annoyance.
An additonal use case is that I occationaly build a qube for friends and
then send to them, again the mandatory encryption is an annoyance. I
could also imagine that at some point qubes users may even want to
"publish" a qube publicly.
One further feature that would be very useful would be the option to
have each qube backed up to a single file rather than a single
monolithic blob of all qubes selected for backup. This would enable:
- Trimming of backups; when I go over old backups I find that I may have
many qubes that I no longer need. However as all the qubes are stored
in a single file if there are any qubes within the backup I wish to
retain I am suick with a 40-60GB file for example that I have to keep
until I no longer need ANY of the qubes contained within the backup.
Andrew David Wong
Jul 13, 2023, 11:15:05 AM7/13/23
to Metatron, Qubes Devel
On 7/12/23 8:47 AM, Metatron wrote:
> [...]
>
It's worth noting that every Qubes backup includes a qubes.xml file that lists all the qubes in the system at the time the backup was created regardless of whether those qubes were selected for inclusion in the backup. This is an intentional aspect of the design of qvm-backup[-restore], the goal of which is to preserve the system's data and configuration as well as possible, which requires the inclusion of data about the dependencies of each qube in the backup on other qubes. [1] There's an open issue for the development of a separate export tool intended for the specific use case you describe. [2]
[1] https://github.com/QubesOS/qubes-issues/issues/2645#issuecomment-281720735
[2] https://github.com/QubesOS/qubes-issues/issues/1747
> [...]
>
> An additonal use case is that I occationaly build a qube for friends and
> then send to them, again the mandatory encryption is an annoyance. I
> could also imagine that at some point qubes users may even want to
> "publish" a qube publicly.
>
> [...]
> An additonal use case is that I occationaly build a qube for friends and
> then send to them, again the mandatory encryption is an annoyance. I
> could also imagine that at some point qubes users may even want to
> "publish" a qube publicly.
>
>
It's worth noting that every Qubes backup includes a qubes.xml file that lists all the qubes in the system at the time the backup was created regardless of whether those qubes were selected for inclusion in the backup. This is an intentional aspect of the design of qvm-backup[-restore], the goal of which is to preserve the system's data and configuration as well as possible, which requires the inclusion of data about the dependencies of each qube in the backup on other qubes. [1] There's an open issue for the development of a separate export tool intended for the specific use case you describe. [2]
[1] https://github.com/QubesOS/qubes-issues/issues/2645#issuecomment-281720735
[2] https://github.com/QubesOS/qubes-issues/issues/1747
Reply all
Reply to author
Forward
0 new messages