Automatic incremental encrypted offsite backups using btrfs

[li...@mullvad.net]

Hi.

I want my Qubes laptop to be fully backed up at all times in case of a system failure, theft, fire or any other unforeseen event that makes it impossible for me to reach my data on the laptop itself. I have been thinking about how to design such a system but wanted to make sure I'm not reinventing something that already exists, nor that I'm writing something that has security problems I have not identified.

There are tons of backup software out there but so far I have not been able to find one that fit's well into Qubes and also cover my needs. My system is running on btrfs and I'm planning on using the awesome 'btrfs send' functionality as the base of this backup software. Most existing btrfs backup software both require that the target backup server is running btrfs (btrfs receive) and that there is internet on the machine you are taking backup of (dom0 has no internet).

My plan is to place every VM in a separate subvolume (and root, /, is of course also a subvolume) and take daily snapshots of both root and every VM (in dom0). For every new snapshot I 'btrfs send' the difference between the new and the previous snapshot and send the output off to a dedicated backup AppVM. This backup VM compresses the incremental data (This data is usually VERY compressable I have noticed) and then encrypts it using gpg. Lastly it uploads the encrypted file to some server over ssh or similar protocol.

This was a very basic description. It should of course support saving X days back of daily snapshots, Y weeks back of weekly snapshots etc. The encryption needs to be done in a way so that only I can make use of the files I send to the internet. These details are not important at this stage, now I mostly want to know if there is any similar software available or if there is anything fundamentally wrong with my approach.

I also have plans to make this more Qubes specific by not snapshotting templates every night but rather every time they start up or shut down.

I have been happily using Btrfs as my root fs for some time and taking local snapshots for fast resets and cloning of VM works like a charm. Now I just need a way to securely store this outside my computer as well.

Regards,
Linus

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, May 19, 2016 at 12:08:47PM -0700, li...@mullvad.net wrote:
> Hi.
>
> I want my Qubes laptop to be fully backed up at all times in case of a
> system failure, theft, fire or any other unforeseen event that makes it
> impossible for me to reach my data on the laptop itself. I have been
> thinking about how to design such a system but wanted to make sure I'm not
> reinventing something that already exists, nor that I'm writing something
> that has security problems I have not identified.
>
> There are tons of backup software out there but so far I have not been able
> to find one that fit's well into Qubes and also cover my needs. My system
> is running on btrfs and I'm planning on using the awesome 'btrfs send'
> functionality as the base of this backup software. Most existing btrfs
> backup software both require that the target backup server is running btrfs
> (btrfs receive) and that there is internet on the machine you are taking
> backup of (dom0 has no internet).
>
> My plan is to place every VM in a separate subvolume (and root, /, is of
> course also a subvolume) and take daily snapshots of both root and every VM
> (in dom0). For every new snapshot I 'btrfs send' the difference between the
> new and the previous snapshot and send the output off to a dedicated backup
> AppVM. This backup VM compresses the incremental data (This data is usually
> VERY compressable I have noticed) and then encrypts it using gpg. Lastly it
> uploads the encrypted file to some server over ssh or similar protocol.

Better encrypt the data (so, compress too) in dom0, before exposing it
to any VM. AFAIR gpg have an option to compress before encryption.

But, we have chosen to not use gpg in Qubes backups for a reason. It
does a lot of processing the data during decryption, before
authenticating that data. So there is noticeable attack surface on
restore process. But if you authenticate the data some other way before
decryption (for example HMAC), it should be fine.

> This was a very basic description. It should of course support saving X
> days back of daily snapshots, Y weeks back of weekly snapshots etc. The
> encryption needs to be done in a way so that only I can make use of the
> files I send to the internet. These details are not important at this
> stage, now I mostly want to know if there is any similar software available
> or if there is anything fundamentally wrong with my approach.

This is already tracked here:
https://github.com/QubesOS/qubes-issues/issues/858
And was discussed here:
https://groups.google.com/d/msg/qubes-devel/Gcrb7KQVcMk/CK-saQU_1HYJ

There was some vague ideas, not nothing ready to use.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXPhmmAAoJENuP0xzK19csEpsH/0eubIZ6grBa/UhZlm+Pr7Ht
8faFmWVcvvt4HkFgo7w58zfB23DYsyXbgnyJMDIKoq3lIgUL75jl+UFM5x/JsWz+
HmKUD81tOce4q8r2A0Py7j8Ww5yqkinQBCTGdJcmVuma/XlRSKdey/IpuKbeyoqY
FdqLppffstnXQO2vrgY1gtm3JkEPk/s44omHZv/FRiPADrgnValtY45+Wwz6ue1b
y7hMy/1CKwSAGxiblw1BKj9cy19DdkwxnHJ5K5+A43/EzyYV7fytN6amCBS250fR
BxzgX7kbul4xUB7CFRFBe4VBqxxOWXksaycAHpOutxnNfc5O6+peOpDQvIUO5ys=
=JFdK
-----END PGP SIGNATURE-----

[Chris Laprise]

I know of no current way to encrypt backup data on Qubes and then fully
integrate it into a backup set without bestowing a totally trusted
status to the backup destination machine. By 'integrate' I mean
something like btrfs receive, which makes the backup increments readable
for operations like pruning old data (a feature that linus wants).

Fully trusting the destination machine means storing your decryption key
on it (so you can do the btrfs receive). If you really trust it that
much - not something a typical Qubes user would do - you could focus on
link-based encryption instead (ex: send plaintext data over ssh). It
would save you some steps and have roughly the same security profile.

And notice I said "no current way"... Maybe if Qubes individually
encrypted each vm disk image separately, so that btrfs is managing
pre-encrypted containers to begin with, then you could have your cake
and eat it too: You could presumably 'btrfs send' and 'btrfs receive'
and also be able to manage/prune the increments while keeping your data
private.

OTOH, if you give up the ability to prune then you can encrypt the
'btrfs send' data in dom0 before it is sent to a backup vm for
transmission. You can just keep piling up the increment files (without
using 'btrfs receive') until some point in time when you need to start
over by sending a new initial/full copy and erasing the old backup
files. If you alternate or rotate between different backup volumes -
erasing the oldest one when the newest one fills up - then this isn't so
bad!

One last thing about the nature of incremental backups based on
filesystem snapshots: The snapshots require more space on the
originating systems because they're storing old data. That might not be
suitable for everyone.

Chris

[li...@mullvad.net]

Yes I know it will not be possible to recreate the datasets as subvolumes on the destination since they are encrypted. I just planned to store them as compressed encrypted files. The system should be designed so I don't have to trust the storage location at all.
I know this makes it harder to remove old backups. I have been looking at a solution where I draw all full backups and diffs in a tree structure and can figure out which backup files I need to keep in order to be able to restore the backup points I want to be able to restore. This will require me to store some more data than a real subvolume on the destination would require and it will require me to upload new full backups at some interval, but the encryption part is really important so that doesn't matter to me.

Fully trusting the destination machine means storing your decryption key
on it (so you can do the btrfs receive). If you really trust it that
much - not something a typical Qubes user would do - you could focus on
link-based encryption instead (ex: send plaintext data over ssh). It
would save you some steps and have roughly the same security profile.

I will not trust the destination at all. The backed up files will be encrypted and signed. No btrfs receive anywhere except when I restore the data to my laptop.

And notice I said "no current way"... Maybe if Qubes individually
encrypted each vm disk image separately, so that btrfs is managing
pre-encrypted containers to begin with, then you could have your cake
and eat it too: You could presumably 'btrfs send' and 'btrfs receive'
and also be able to manage/prune the increments while keeping your data
private.

OTOH, if you give up the ability to prune then you can encrypt the
'btrfs send' data in dom0 before it is sent to a backup vm for
transmission. You can just keep piling up the increment files (without
using 'btrfs receive') until some point in time when you need to start
over by sending a new initial/full copy and erasing the old backup
files. If you alternate or rotate between different backup volumes -
erasing the oldest one when the newest one fills up - then this isn't so
bad!

Exactly what I'm planning on doing!

One last thing about the nature of incremental backups based on
filesystem snapshots: The snapshots require more space on the
originating systems because they're storing old data. That might not be
suitable for everyone.

Chris

Good clarification on the abilities one get and lose by trusting and not trusting the destination.

Linus

[li...@mullvad.net]

Good point to have in mind. I will have to look at these details if I get to the point where I implement this myself.

> This was a very basic description. It should of course support saving X
> days back of daily snapshots, Y weeks back of weekly snapshots etc. The
> encryption needs to be done in a way so that only I can make use of the
> files I send to the internet. These details are not important at this
> stage, now I mostly want to know if there is any similar software available
> or if there is anything fundamentally wrong with my approach.

This is already tracked here:
https://github.com/QubesOS/qubes-issues/issues/858
And was discussed here:
https://groups.google.com/d/msg/qubes-devel/Gcrb7KQVcMk/CK-saQU_1HYJ

Thanks for the links. I already saw the thread, but the issue was new for me. I'll post something there if/when I get to a point where I have something to show.
 

[Chris Laprise]

Then you could copy the encryption method used in the python scripts for
qvm-backup, using openssl. For transmission, use an appvm assigned to
the task of connecting to the destination: issue qvm-run commands in the
vm to take care of the particulars, such as running 'scp'. Using
'--pass-io' with qvm-run will allow you to pipe backup data from dom0 to
your vm commands.

Chris

[li...@mullvad.net]

Yes, exactly my plan, the part about using a dedicated VM and talking to it with 'qvm-run --pass-io'.

Regarding the encryption I have some questions left that I didn't take a decision about and could use some input around. qvm-backup is all about using a symmetric cipher with a passphrase. This works fine since I guess most people invoke that script manually. I want a fully automatic backup solution and I would then need access to the passphrase in dom0. Would you regard simply storing that passphrase in a file in dom0 to be an acceptable solution? Another solution would be having to start the backup process manually upon each boot and entering the passphrase in the console so it can keep the passphrase in ram for the lifetime of the process.

The fact that qvm-backup takes a --passphrase-file might already confirm that at least someone accepts having the passphrase in plaintext on disk. I'm concerned about this since that solution could reveal the entire secret on screen with just a few keypresses. This can be compared with LUKS or a passphrase protected asymmetric private key where one can't extract the secret even if they get a hold of the unlocked computer for a while.

Would you regard any/both of the above symmetric solutions better/safer than having a public key in dom0 that you do asymmetric encryption of the backups with? Given I solve the gpg attack surface issue Marek pointed out of course.

If I'm not mistaken, symmetric encryption is regarded safer against quantum computers and other future attacks and that might be a reason to stay all in symmetric for the backups, since we don't want to trust the place we store it in.

Linus

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

li...@mullvad.net:

>
>
> On Friday, May 20, 2016 at 3:19:07 PM UTC+2, Chris Laprise wrote:
>>
>> Then you could copy the encryption method used in the python scripts for
>> qvm-backup, using openssl. For transmission, use an appvm assigned to
>> the task of connecting to the destination: issue qvm-run commands in the
>> vm to take care of the particulars, such as running 'scp'. Using
>> '--pass-io' with qvm-run will allow you to pipe backup data from dom0 to
>> your vm commands.
>>
>> Chris
>>
>
> Yes, exactly my plan, the part about using a dedicated VM and talking to it
> with 'qvm-run --pass-io'.
>
> Regarding the encryption I have some questions left that I didn't take a
> decision about and could use some input around. qvm-backup is all about
> using a symmetric cipher with a passphrase. This works fine since I guess
> most people invoke that script manually. I want a fully automatic backup
> solution and I would then need access to the passphrase in dom0. Would you
> regard simply storing that passphrase in a file in dom0 to be an acceptable
> solution? Another solution would be having to start the backup process
> manually upon each boot and entering the passphrase in the console so it
> can keep the passphrase in ram for the lifetime of the process.

Assuming you have enabled LUKS encryption in your Qubes setup then
stroing the passphrase in dom0 should not really increase the risk (see
also below). dom0 has anyway full control over the backuped data and has
access to the password during encryption when using symetric encryption.

> The fact that qvm-backup takes a --passphrase-file might already confirm
> that at least someone accepts having the passphrase in plaintext on disk.
> I'm concerned about this since that solution could reveal the entire secret
> on screen with just a few keypresses. This can be compared with LUKS or a
> passphrase protected asymmetric private key where one can't extract the
> secret even if they get a hold of the unlocked computer for a while.

In case of LUKS you can get the master encrpytion key (when you have it
you don't care about the passphrase) from the kernel memory.

What you can do is encrypt to an asymetric encrpytion key. For this dom0
only need access to the public key. Those backups can then only be
decrypted by someone who has access to the corresponding private key.

> Would you regard any/both of the above symmetric solutions better/safer
> than having a public key in dom0 that you do asymmetric encryption of the
> backups with? Given I solve the gpg attack surface issue Marek pointed out
> of course.

I think you need to explain your threat model to be able to answer this
question. When someone get access to dom0 they have anyway full access
to the current version of the backuped data. So against what scenario
you are trying to defend?

> If I'm not mistaken, symmetric encryption is regarded safer against quantum

> computers and other future attacks ...

AFAIK this is correct.

> ... and that might be a reason to stay all

> in symmetric for the backups, since we don't want to trust the place we
> store it in.

HW42
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXRJlOAAoJEOSsySeKZGgWZLQQAIRwCAPUNjf8x6UkcSfC+w1H
SYwJyGeHw7ZckxvIhbhJQEWq6aeHGRkLJFuNCsf9eZS20iFEaVG26WK/aMKclLg2
T2q+uCDDBtBU6HxW7+dr3OgGHyyHS+01JwXPEiW2Lp4ehgN/EXT3GlTPw/xBn287
64l4Dr7b9WRRMyLTVrZhJ7R5dYZvfKld8P5zaHewRHzkcQgZEBu2+baBW4/+NHSu
dpY9krR7qCXGPmHXNb5J8yLxfIEopB2k5AE9gecXWmKQMk3Zp1dfFxzcGjOiQOFV
CacqTwvGkY53HJEG6R7H+oZU2vXv/+TeYUE//LLpNAHzh84PuFQAK9IUEmp4oi3G
UtuS7A4hkVTAblVeP7Ua7LOmyvvn/GK5e7d+Nus3Iwoyv9yli0i6N3v5kcy5t1tz
5CfvQ3Gh/yt5ieS/pbV3wTKXzxsLoe+vTwt+HS9KusmD7VJLTGI8diNZtzYlz8hd
i6WAsRn9S3keZl3GygFdhS75ifQU5U+twkBZnuvxBZscAQKSq0QHy7nUJHm8MrtO
mtbNlhkLKsVGuQLcK+XPvAqqfO9XpT/Pa/9SbmkNBLwLB0+BME17esvm8rP5j9G/
RIfwrOsJd7HihOA/SxMh0yM1v1pHsk27tzGsfJUim2E6OYeh092/ywHVWB5pTPCK
AqcmINwF+l+e7dx0VY49
=pNtT
-----END PGP SIGNATURE-----

[Chris Laprise]

On 05/24/2016 11:26 AM, li...@mullvad.net wrote:
>
>
> On Friday, May 20, 2016 at 3:19:07 PM UTC+2, Chris Laprise wrote:
>
> Then you could copy the encryption method used in the python
> scripts for
> qvm-backup, using openssl. For transmission, use an appvm assigned to
> the task of connecting to the destination: issue qvm-run commands
> in the
> vm to take care of the particulars, such as running 'scp'. Using
> '--pass-io' with qvm-run will allow you to pipe backup data from
> dom0 to
> your vm commands.
>
> Chris
>
>
> Yes, exactly my plan, the part about using a dedicated VM and talking
> to it with 'qvm-run --pass-io'.

Small correction: Instead of using scp you probably want to pipe into
the ssh command itself, since ideally there will be no backup file on
disk in the backup vm (i.e. you're streaming). So your qvm-run pipe
command may contain a command to pipe over ssh :) or execute a script in
the backup vm to do the job.

I don't know if the qvm-backup methods allow for compression, but you
might consider adding that as well before encryption (xz is a great choice).

By storing your passphrase on your active LUKS partition (on your source
system), you are making the security of the backups dependent on the
security of the source system. Lots of IT depts think this is fine, and
in the case of Qubes dom0 the security is even stronger. But its not as
good as manually entering the passphrase in every case: If your security
model values the integrity of the backups above all else, and possible
threats include having your backed-up data infected with malware, then
you may wish to remain with manual passphrase entry (combined with an
automatic backup process, it might not be so inconvenient if the
sessions aren't too frequent). It depends on how infect-able and
irreplaceable your data is.

There are use cases where manual entry seems to be a requirement -- such
as having your laptop stolen and then compromised with a physical
attack, where the attacker wants to attack you through your online
backups as well -- and others where it doesn't make sense.

Adding a second authentication factor may strike an excellent balance
between tight security and convenience, making the stored passphrase
dependent on the presence of a fob for instance.

You can also do full best-practices for backups and introduce offline
archives as well, to alleviate worries associated with automated
backups. Archives are manually curated periodic "backups" that are much
more insulated from attack by virtue of being offline, so you have
something (hopefully) pristine to resort to in case a disaster
compromises your online backups in addition to your source systems.

Re: symmetric encryption... yes I think it makes the most sense for
backups or really anything that doesn't rely on a whole group of people
interacting.

Chris

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, May 24, 2016 at 07:22:06PM -0400, Chris Laprise wrote:
>
>
> On 05/24/2016 11:26 AM, li...@mullvad.net wrote:
> >
> >
> >On Friday, May 20, 2016 at 3:19:07 PM UTC+2, Chris Laprise wrote:
> >
> > Then you could copy the encryption method used in the python
> > scripts for
> > qvm-backup, using openssl. For transmission, use an appvm assigned to
> > the task of connecting to the destination: issue qvm-run commands
> > in the
> > vm to take care of the particulars, such as running 'scp'. Using
> > '--pass-io' with qvm-run will allow you to pipe backup data from
> > dom0 to
> > your vm commands.
> >
> > Chris
> >
> >
> >Yes, exactly my plan, the part about using a dedicated VM and talking to
> >it with 'qvm-run --pass-io'.
>
> Small correction: Instead of using scp you probably want to pipe into the
> ssh command itself, since ideally there will be no backup file on disk in
> the backup vm (i.e. you're streaming). So your qvm-run pipe command may
> contain a command to pipe over ssh :) or execute a script in the backup vm
> to do the job.
>
> I don't know if the qvm-backup methods allow for compression, but you might
> consider adding that as well before encryption (xz is a great choice).

Compression is supported, but for now only from command line.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXROVRAAoJENuP0xzK19csljcH/0uDn4AaqBbHHNNBQA40FVQl
oL+4OFdGVQkJiFiTFmTuCQHk1YCNhuDu8+1yJSF5q9RRKiWAYzgnTCJutyZCBeJ9
0ZJH957MJwlTAg2ts8cNBnAuHqoINRUCOas8K1DHK0g3O/tbUswZe7fufNqAO+4l
WYZqxTwHes7ERiiqKrQc5fsoi4HBvbm1sO6oDNmhymwIRdkOTLw0yKM61RWMFoDB
x4sV7gB9eSBkLUr2aUE6YapiVwMqdFi0YiWuIXgzaHoMMnB0P4OUJ4HDJqH4FWRY
xYmdYE8+8bln3pmpRsu/Qu3ALZJVEh1qa7Caz4tsUOLduMxK85n+6fEF4UbXaLA=
=BHyy
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-05-24 08:26, li...@mullvad.net wrote:
>
>
> On Friday, May 20, 2016 at 3:19:07 PM UTC+2, Chris Laprise wrote:
>>
>> Then you could copy the encryption method used in the python
>> scripts for qvm-backup, using openssl. For transmission, use an
>> appvm assigned to the task of connecting to the destination:
>> issue qvm-run commands in the vm to take care of the
>> particulars, such as running 'scp'. Using '--pass-io' with
>> qvm-run will allow you to pipe backup data from dom0 to your vm
>> commands.
>>
>> Chris
>>
>
> Yes, exactly my plan, the part about using a dedicated VM and
> talking to it with 'qvm-run --pass-io'.
>
> Regarding the encryption I have some questions left that I didn't
> take a decision about and could use some input around. qvm-backup
> is all about using a symmetric cipher with a passphrase. This
> works fine since I guess most people invoke that script manually. I
> want a fully automatic backup solution and I would then need access
> to the passphrase in dom0. Would you regard simply storing that
> passphrase in a file in dom0 to be an acceptable solution?

Yes. See this message (and the surrounding discussion):

https://groups.google.com/d/msg/qubes-devel/EBc4to5IBdg/fzMGx7QcwrkJ

> Another solution would be having to start the backup process
> manually upon each boot and entering the passphrase in the console
> so it can keep the passphrase in ram for the lifetime of the
> process.
>

Yes. This means that the passphrase could be obtained from RAM, but
the same is true of the disk decryption passphrase (which protects the
backup passphrase) via a cold boot attack. Depends on the threat
model. In practice, probably not a significant security difference.

> The fact that qvm-backup takes a --passphrase-file might already
> confirm that at least someone accepts having the passphrase in
> plaintext on disk. I'm concerned about this since that solution
> could reveal the entire secret on screen with just a few
> keypresses. This can be compared with LUKS or a passphrase
> protected asymmetric private key where one can't extract the
> secret even if they get a hold of the unlocked computer for a
> while.
>

Again, I think this depends on the threat model. Arguably, not many
more keypresses would be required to permanently and undetectably
compromise dom0, so if an attacker gains access to the keyboard in
that disk-decrypted, screen-unlocked state, we should assume it's game
over.

> Would you regard any/both of the above symmetric solutions
> better/safer than having a public key in dom0 that you do
> asymmetric encryption of the backups with? Given I solve the gpg
> attack surface issue Marek pointed out of course.
>

Personally, I would never use asymmetric encryption for a long-term
backup for the reason cited immediately below. (And keep in mind that
any backup can be "long-term" against your will if any copies are
retained, e.g., by cloud storage services or forensically recoverable
storage media.)

> If I'm not mistaken, symmetric encryption is regarded safer
> against quantum computers and other future attacks and that might
> be a reason to stay all in symmetric for the backups, since we
> don't want to trust the place we store it in.
>

Correct.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXRP4vAAoJENtN07w5UDAwqUwQAMIQs35eaZ5xFAAu4K6zY6WI
8PL3tzb5j3dFLiLP7H9GIbjg0VWSVZMJaa2bENeBKC77R+71FH05v3ipdKllyBMJ
uoV7LyPnW3LeKrj+ajM9IALddpcwew6cSKQ0UCof8fxiUOI2Ylqpng2bro6/wysx
CQcZgl1F3yN5i1JnSMzDAZ7FtlZ2rXCH5/ARqtttIz6ChyiLefkzEgwp1TEhVZ3e
Ed/dTacN4bBvu3zbpnSmsgrVWyMwnErRZiKpNjKNJRSJC25tNOYnFdL3gGztfy/6
7Hmt0vcrpyy0KayK+LffswwYGrj/HVCsCE8H46eEBDalCDBl+X+jS1evgba2wV7h
79ZhmmZ4iumzGdDK3owFKSu9J+Pv9Ot/6qVYXOCnNUWgAoWcdoEWds84HscZGQeL
QN+d4r93sKu0bqkaFsXWPOb9KUpN6mg/8jMAD50kKgQN6kwXC37hP+buAtjbZ4nC
458EjxGgjLcEkgT2Sa28k2tGnhs+FOSaaaEqWYwx1EbxRDsNFBcY0BNnfFaMR1ar
HcZqvDOz4cXZ0S34X/17pA3fHb1RqK87inZ3NS4VgppIHYZmaOxwuidnjb/QBy9Y
/hmrdM2FzgNQGKvHJJOLolEqC8Go8e19bTINhccVHWqPLhOOmErAm4y/UWn3YxEy
o62sCRL4lqFoYZAFoEoo
=ZT5j
-----END PGP SIGNATURE-----

[Chris Laprise]

Can I supply an argument? Like:
qvm-backup -Z 'xz -3'

To set the compression level.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yes. Take a look at `qvm-backup --help`. You can specify a compression
filter program with `-Z COMPRESS_FILTER` or
`--compress-fitler=COMPRESS_FILTER`. The default is gzip.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXR804AAoJENtN07w5UDAwMo8QAJXwpKJxlOBMQG1rQ8Me+lqn
pPMzla/XsEsBfst/8KIrxf3zUwT0GrOt10TXgLBv1F8AzNeQgvyIIjvylKs5tBWv
XPsmc6NOg9+mlx5CIzPcozbcps0D6VhY3/MG5OqzdZRxF6UCL4/TiOhrAL7AAZ6N
yR1usWnvqk1YM5dQl/VQHaZbKdgRw9FJJV4Y055rZU4VViF4JmwYV/hwpwktjnRp
9iMyU4N2u3W0gBc5p4rL+W1tCqRJcOKa+tS/mDu+f57ZIn3PH9s6y5y30wQkH/lP
gxVGuj5yFhxeyCk07ulIWZI0V0LzToEpD9EtypOh2MkDQzzI5lz95P0wFRAgXVke
XNmnJyJnMIBBUNXzXl2yMONkas/ITi/KCiBr1ifMmnk33c8J4OFkXrhBolZ3w64i
bxPJYEOHa20Ka5KbkIgh2amjA7jIbumKV0w766YfllBLCCATJLi2yN4rKYtw87+P
ZkkZbKwYvhob6WgjiFAQ3kE5Xy9lhHSmqJARJ4ElQ0m19ge5W1/N9CNUFM8Wr8pd
H9b03pCBt+Diyk23ItZ0bgPC0uJIeMrm30iZ3ECkSWiluvAr/DhEFkA9Urv3Zf+q
kOjjOChhGLasuE0yHdYEBl/CFLb+AYzWe0HBMHRhgYZF+boPrY3OiS8sxLQwx5X8
sEmFBI8zKiOT0MfsKN+R
=HXjq
-----END PGP SIGNATURE-----