Access all vm data from a backup-vm?
102 views
Skip to first unread message
Stickstoff
Nov 20, 2016, 5:21:38 AM11/20/16
to qubes...@googlegroups.com
Hello dear new qubes family,
I am having trouble designing a backup concept for my qubes workstation.
My goal is to have a (daily) copy of the entire workstation on a trusted
remote backup target (versioning, encryption, rotation is done
remotely). Only a small part of the local data ("vault") would need to
be encrypted before sending it on its way.
My plan was to use a dedicated backup-vm, locked down to only connect to
the remote target.
- My first idea was to "mount --bind" the data to the backup-vm in
read-only mode. It would then do a simple rsync to the remote backup
target. This seems not to be possible, as I can't mount a directory from
outside, dom0, into the filesystem of the backup-vm. Mounting a
btrfs-snapshot would be a nice alternative, which doesn't seem to be
possible neither.
- I could use a dedicated drive, partition, or .img file to hold a copy
of all data locally and connect this back and forth between dom0 and the
backup-vm. This seems wasteful and opens security risks.
- I could serve all data via nfs to the backup-vm. This would, of
course, open security risks in enabling some kind of networking in dom0.
- I could send the backup-stream ("btrfs send", for example) to the
backup-vm and it forwards it to the remote backup target. This would
need all backup logic, programs and scripts to run in dom0. Also, I
suppose this would be an unstable solution, where (network) problems
immediately lead to a failed and broken backup (where rsync fails more
gracefully).
How do other people backup their qubes machine to a remote target?
Thank you,
N2
I am having trouble designing a backup concept for my qubes workstation.
My goal is to have a (daily) copy of the entire workstation on a trusted
remote backup target (versioning, encryption, rotation is done
remotely). Only a small part of the local data ("vault") would need to
be encrypted before sending it on its way.
My plan was to use a dedicated backup-vm, locked down to only connect to
the remote target.
- My first idea was to "mount --bind" the data to the backup-vm in
read-only mode. It would then do a simple rsync to the remote backup
target. This seems not to be possible, as I can't mount a directory from
outside, dom0, into the filesystem of the backup-vm. Mounting a
btrfs-snapshot would be a nice alternative, which doesn't seem to be
possible neither.
- I could use a dedicated drive, partition, or .img file to hold a copy
of all data locally and connect this back and forth between dom0 and the
backup-vm. This seems wasteful and opens security risks.
- I could serve all data via nfs to the backup-vm. This would, of
course, open security risks in enabling some kind of networking in dom0.
- I could send the backup-stream ("btrfs send", for example) to the
backup-vm and it forwards it to the remote backup target. This would
need all backup logic, programs and scripts to run in dom0. Also, I
suppose this would be an unstable solution, where (network) problems
immediately lead to a failed and broken backup (where rsync fails more
gracefully).
How do other people backup their qubes machine to a remote target?
Thank you,
N2
Franz
Nov 20, 2016, 6:35:44 AM11/20/16
to Stickstoff, qubes...@googlegroups.com
I have a simple script in dom0 that mounts a NAS via nfs on a backupVM and launches the default encrypted backup system.
best
Fran
Thank you,
N2
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5831792C.3060308%40posteo.de.
For more options, visit https://groups.google.com/d/optout.
David Hobach
Nov 20, 2016, 7:04:06 AM11/20/16
to Franz, Stickstoff, qubes...@googlegroups.com
On 11/20/2016 12:35 PM, Franz wrote:
> On Sun, Nov 20, 2016 at 7:21 AM, Stickstoff <stick...@posteo.de> wrote:
>
>> Hello dear new qubes family,
>>
>> I am having trouble designing a backup concept for my qubes workstation.
>> My goal is to have a (daily) copy of the entire workstation on a trusted
>> remote backup target (versioning, encryption, rotation is done
>> remotely). Only a small part of the local data ("vault") would need to
>> be encrypted before sending it on its way.
>> My plan was to use a dedicated backup-vm, locked down to only connect to
>> the remote target.
>>
>> - My first idea was to "mount --bind" the data to the backup-vm in
>> read-only mode. It would then do a simple rsync to the remote backup
>> target. This seems not to be possible, as I can't mount a directory from
>> outside, dom0, into the filesystem of the backup-vm. Mounting a
>> btrfs-snapshot would be a nice alternative, which doesn't seem to be
>> possible neither.
That works. Just use qvm-block from dom0 to attach your other VMs to
> On Sun, Nov 20, 2016 at 7:21 AM, Stickstoff <stick...@posteo.de> wrote:
>
>> Hello dear new qubes family,
>>
>> I am having trouble designing a backup concept for my qubes workstation.
>> My goal is to have a (daily) copy of the entire workstation on a trusted
>> remote backup target (versioning, encryption, rotation is done
>> remotely). Only a small part of the local data ("vault") would need to
>> be encrypted before sending it on its way.
>> My plan was to use a dedicated backup-vm, locked down to only connect to
>> the remote target.
>>
>> - My first idea was to "mount --bind" the data to the backup-vm in
>> read-only mode. It would then do a simple rsync to the remote backup
>> target. This seems not to be possible, as I can't mount a directory from
>> outside, dom0, into the filesystem of the backup-vm. Mounting a
>> btrfs-snapshot would be a nice alternative, which doesn't seem to be
>> possible neither.
your backup VM. Then you can e.g. start rsync in your backup VM from
dom0 using qvm-run.
The concrete dom0 command should be
qvm-block -A [BACKUP_VM] dom0:/var/lib/qubes/appvms/[CLIENT_VM]/private.img
and then mount etc. in your backup VM using e.g. qvm-run.
read-only didn't work though the last time I tested it (you can write
anyway - probably some bug).
Marek Marczykowski-Górecki
Nov 20, 2016, 8:07:58 AM11/20/16
to David Hobach, Franz, Stickstoff, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This is risky. If one of your VMs is compromised, it may try to exploit
some bug in filesystem handling code, or rsync, to steal data from other
VMs.
Handling this at block device level (so do not mount, but use /dev/xvdi
as is) should be much safer. But then, you have qvm-backup tool which
handle all this for you. The disadvantage (at least for now) is copy
all the data each time - no support for incremental backups or such.
> read-only didn't work though the last time I tested it (you can write anyway
> - probably some bug).
Yes, this one:
https://github.com/QubesOS/qubes-issues/issues/2255
- --
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
iQEcBAEBCAAGBQJYMaApAAoJENuP0xzK19csIzIIAIUsmVoT3OkLxXMPdJcya1hp
LRPG+YxM09Zo8eVrMZwqGmnyew+YMb8p66yi0RMSUF2bPIoNmb0cNrfUCHzuSlXc
Hd0eQ2cBFwCvVyzepxdUobkZebNiG+zylV6hEj3T9vpVXs0QYR6vbdHe90YO8yRe
IpzzyG2/lPowNQOzbm3GN8EIISSymfuVqfFT4wXzZk2zdZAsJ63xsgO9PfAFghts
k2f0zq763WtpbDcpNjAoBSsB5OjtKbCG4tBEO8AXSEfepzMssB99QAInfcEOiq1m
L6AAcqPGUwPSj8Xa3iQ6VvnNowGjjOA2KxStmgN+XqzU5FCa/93ettIa/iukHIk=
=gj/a
-----END PGP SIGNATURE-----
Hash: SHA256
some bug in filesystem handling code, or rsync, to steal data from other
VMs.
Handling this at block device level (so do not mount, but use /dev/xvdi
as is) should be much safer. But then, you have qvm-backup tool which
handle all this for you. The disadvantage (at least for now) is copy
all the data each time - no support for incremental backups or such.
> read-only didn't work though the last time I tested it (you can write anyway
> - probably some bug).
https://github.com/QubesOS/qubes-issues/issues/2255
- --
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
iQEcBAEBCAAGBQJYMaApAAoJENuP0xzK19csIzIIAIUsmVoT3OkLxXMPdJcya1hp
LRPG+YxM09Zo8eVrMZwqGmnyew+YMb8p66yi0RMSUF2bPIoNmb0cNrfUCHzuSlXc
Hd0eQ2cBFwCvVyzepxdUobkZebNiG+zylV6hEj3T9vpVXs0QYR6vbdHe90YO8yRe
IpzzyG2/lPowNQOzbm3GN8EIISSymfuVqfFT4wXzZk2zdZAsJ63xsgO9PfAFghts
k2f0zq763WtpbDcpNjAoBSsB5OjtKbCG4tBEO8AXSEfepzMssB99QAInfcEOiq1m
L6AAcqPGUwPSj8Xa3iQ6VvnNowGjjOA2KxStmgN+XqzU5FCa/93ettIa/iukHIk=
=gj/a
-----END PGP SIGNATURE-----
pixel fairy
Nov 20, 2016, 10:02:28 AM11/20/16
to qubes-users, tri...@hackingthe.net, 169...@gmail.com, stick...@posteo.de
On Sunday, November 20, 2016 at 8:07:58 AM UTC-5, Marek Marczykowski-Górecki wrote:
> This is risky. If one of your VMs is compromised, it may try to exploit
> some bug in filesystem handling code, or rsync, to steal data from other
> VMs.
> Handling this at block device level (so do not mount, but use /dev/xvdi
> as is) should be much safer. But then, you have qvm-backup tool which
> handle all this for you. The disadvantage (at least for now) is copy
> all the data each time - no support for incremental backups or such.
what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
> This is risky. If one of your VMs is compromised, it may try to exploit
> some bug in filesystem handling code, or rsync, to steal data from other
> VMs.
> Handling this at block device level (so do not mount, but use /dev/xvdi
> as is) should be much safer. But then, you have qvm-backup tool which
> handle all this for you. The disadvantage (at least for now) is copy
> all the data each time - no support for incremental backups or such.
if you were using qubes-backup, how would you restore a single file or folder?
Marek Marczykowski-Górecki
Nov 20, 2016, 10:15:44 AM11/20/16
to pixel fairy, qubes-users, tri...@hackingthe.net, 169...@gmail.com, stick...@posteo.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Sun, Nov 20, 2016 at 07:02:28AM -0800, pixel fairy wrote:
> On Sunday, November 20, 2016 at 8:07:58 AM UTC-5, Marek Marczykowski-Górecki wrote:
>
> > This is risky. If one of your VMs is compromised, it may try to exploit
> > some bug in filesystem handling code, or rsync, to steal data from other
> > VMs.
> > Handling this at block device level (so do not mount, but use /dev/xvdi
> > as is) should be much safer. But then, you have qvm-backup tool which
> > handle all this for you. The disadvantage (at least for now) is copy
> > all the data each time - no support for incremental backups or such.
>
> what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
It's better, but personally I wouldn't do that either.
> On Sunday, November 20, 2016 at 8:07:58 AM UTC-5, Marek Marczykowski-Górecki wrote:
>
> > This is risky. If one of your VMs is compromised, it may try to exploit
> > some bug in filesystem handling code, or rsync, to steal data from other
> > VMs.
> > Handling this at block device level (so do not mount, but use /dev/xvdi
> > as is) should be much safer. But then, you have qvm-backup tool which
> > handle all this for you. The disadvantage (at least for now) is copy
> > all the data each time - no support for incremental backups or such.
>
> what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
> if you were using qubes-backup, how would you restore a single file or folder?
copy that single file to original VM, then remove restored VM.
- --
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
CYSSMFZ7CkfJCnuMO3VfYJk4iACLbgBwfej5MWqnimgW5oihQdmXZ6q/qhuYmZjY
MkLCvfKLcOtLMZaCjkFkPjrs8plYmmtovo8wRA89ji3L0JilnAgClQ0cc5wL7Cjb
d5YFMAHemMiomWJx5pHAUJHS4hgbgXvH57Hx7OgObA8f4DTfQBXI18bVqGdgMnUK
cdqze1lagALso+poNJG7p1IhJABb+FN30cTwTCwy9NudwnmQfRjShMaWKG7rXIXF
H1wk9IQc5/PSo4eKlEj3h/ML/aHGlff6RQtBdO8bF4QdTVduLJfKI71CfBf6Lrw=
=3S2/
-----END PGP SIGNATURE-----
pixel fairy
Nov 21, 2016, 12:13:36 AM11/21/16
to qubes-users, pixel...@gmail.com, tri...@hackingthe.net, 169...@gmail.com, stick...@posteo.de
On Sunday, November 20, 2016 at 10:15:44 AM UTC-5, Marek Marczykowski-Górecki wrote:
> > what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
>
> It's better, but personally I wouldn't do that either.
how would you do incremental backups? would lvm/btrfs/zfs snapshots on the backup volume work?
> > what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
>
> It's better, but personally I wouldn't do that either.
> > if you were using qubes-backup, how would you restore a single file or folder?
>
> Restore selected VM (under another name - it's done automatically),
> copy that single file to original VM, then remove restored VM.
it would be nice to have it offer to restore foo to foo_backup-NNNN with out networking and maybe even start the file browser or shell
Stickstoff
Nov 21, 2016, 2:58:43 PM11/21/16
to qubes...@googlegroups.com
>> what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
>
> It's better, but personally I wouldn't do that either.
>
>> if you were using qubes-backup, how would you restore a single file or folder?
>
> Restore selected VM (under another name - it's done automatically),
> copy that single file to original VM, then remove restored VM.
How large would the attack surface be if I create a huge .img container
>
> It's better, but personally I wouldn't do that either.
>
>> if you were using qubes-backup, how would you restore a single file or folder?
>
> Restore selected VM (under another name - it's done automatically),
> copy that single file to original VM, then remove restored VM.
(50% of diskspace), mount it in dom0, do an rsync of all app-vm data
onto it, then mount it in my backup-vm for the actual remote backup?
Even if the backup-vm was compromised, all malicious changes _in_ the
.img container would be overwritten by the next rsync.
I am unsure if "sharing" the blockdevice-metadata (partitiontable etc)
is such a high risk?
Also, as dom0 and the backup-vm don't see any userdata, but only the
other vms .img files, this should be pretty safe?
For me, it would be nice as the backup-vm handles all backup-logic, can
do incremental backups, and there is almost no backchannel from
backup-vm to dom0.
Of course, as soon as my backup-vm or remote backup target is
compromised, I have a huge problem anyway. At least some (vault) data
would always be encrypted (by the regular qubes procedure), and would
necessarily be full-backupped every time.
In general, availability of my data is more important to me than
privacy. I'm still trying to achieve both, though :-)
N2
p.s.:
Please let me know if generally I should leave single emailadresses in
CC, I removed all but the list itself.
Marek Marczykowski-Górecki
Nov 21, 2016, 3:16:03 PM11/21/16
to pixel fairy, qubes-users, tri...@hackingthe.net, 169...@gmail.com, stick...@posteo.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Sun, Nov 20, 2016 at 09:13:36PM -0800, pixel fairy wrote:
> On Sunday, November 20, 2016 at 10:15:44 AM UTC-5, Marek Marczykowski-Górecki wrote:
>
> > > what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
> >
> > It's better, but personally I wouldn't do that either.
>
> how would you do incremental backups? would lvm/btrfs/zfs snapshots on the backup volume work?
Impossible right now. Some ideas:
> On Sunday, November 20, 2016 at 10:15:44 AM UTC-5, Marek Marczykowski-Górecki wrote:
>
> > > what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks?
> >
> > It's better, but personally I wouldn't do that either.
>
> how would you do incremental backups? would lvm/btrfs/zfs snapshots on the backup volume work?
https://github.com/QubesOS/qubes-issues/issues/858
> > > if you were using qubes-backup, how would you restore a single file or folder?
> >
> > Restore selected VM (under another name - it's done automatically),
> > copy that single file to original VM, then remove restored VM.
>
> just tried that, it complained that there was already a vm of the same name. did you mean to rename the original and then restore the old name?
available in GUI unfortunately...
> it would be nice to have it offer to restore foo to foo_backup-NNNN with out networking and maybe even start the file browser or shell
- --
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
wxsrgR9lM3tt6lj8sRPOz6SlxBASewcBsmIcXNFUAqnZu11Fg/lb8NujngI1oxcf
POYYTDLFcZkHK2mhkrRxXiTfrwm9/cfFMye2mQSzA9KxfuoPltKJqCQmgSqVMb+n
T96l/9vA7p0m4OCjzs4/Ra9zXqctctLYbxCI8DcCxnpEW5yDptFtAIdnp454lGPF
eIZPrloznEutN0OXZ58yHOP8DMx0QfnzAh7qCixUf0ZL3Gecp+wrpBcMG8q/of7P
GU/MSN/RYnaOFDULeAocowCgvfRLYyL6iU73FGVrQtYsHjfsJnwgNccVSwD8m4U=
=DHGj
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages