On 12/10/2018 08:27 PM, Andrew David Wong wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 12/10/18 11:57 AM, Chris Laprise wrote:
On 12/10/2018 05:23 AM, Ivan Mitev wrote:
That's really great work.
On 12/9/18 5:38 PM, Chris Laprise wrote:
Status - Alpha version
------
Can do full or incremental backups of Linux thin-provisioned LVM to
local dom0 or VM filesystems or via ssh, as well as simple volume
retrieval for restore and verify.
I'm not familiar with the way OS X Time Machine works - apologies if
that's a dumb question: would the tool be able to backup to a LUKS
volume mounted in a VM, with the underlying volume being a file on an
NFS share on a NAS ? (that's a bit convoluted but that's the way I
backup my stuff now).
It sounds like your setup would work readily with the current alpha
version: A remote disk image file accessed via NFS by a Qubes VM, and
the VM does a 'losetup' on the disk image file and then 'cryptsetup
luksOpen' on the loop device... If so, that's very similar to my own
setup where I use sshfs instead of NFS. For this kind of setup, specify
'qubes://vmname' as the destvm in sparsebak.ini.
Any VM-mounted disk filesystem thats reasonably modern (like Ext4 or
even NTFS) should work regardless of whether the back end is remote or
local.
OTOH, someone wishing to directly use NFS, sshfs or samba sharing
(without an intermediate disk image file) would have some experimenting
to do at this stage as I haven't yet explored it. But it might work
without any special steps. The main thing is that currently sparsebak
will expect to see a mountpoint.
Finally, there is an option to store each backup session as a single
.tar file which doesn't require hard links but this naturally limits the
user's maintenance options and makes restoring a volume much slower.
> [...]
>
> One more item under 'Todo' I should also mention is the name: I don't
> really like the current working title and would appreciate your
> suggestions and PRs on this and many other issues!
Given how backups take forever to complete and how they trash my
laptop's CPU I do hope that the tool will get included "upstream" if
no major issues are found. The name could be qubes-incremental-backup
; or the project, "Qubes incremental backups". Anyway, I'm not good at
find good names :)
You should find sparsebak to be extremely CPU & IO efficient for
incremental backups. For full/initial backups the advantage isn't as
dramatic, but should still be noticeable.
I've already pointed Marek to the underlying fast delta-harvesting tech
that sparsebak uses in LVM and he seemed interested in that aspect.
Qubes is certainly also welcome to borrow or adopt code from my project
or have qvm-backup act as a wrapper for sparsebak.
For now, I'd like to make it convenient for Qubes users to configure
volumes in sparsebak and run backup sessions. The next step is including
VM settings along with the volumes in the backups, and integrating
encryption so the user doesn't feel compelled to setup a destination
LUKS volume.
Looks great, Chris! Would you be willing to submit this as a package
contribution?
https://www.qubes-os.org/doc/package-contributions/
Yes, although I'll probably wait until it gets to beta stage before
submitting it.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
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 post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/74347b4e-bbc6-3ed2-7128-a37da2160f13%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
