On 12/10/18 7:57 PM, 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.
That was the bit I was missing, thanks for the explanation.
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.
FWIW I had quite a few problems with sparse files and initial file
allocation on NFS mounts some time ago - which is actually the reason I
asked you about the NFS "backend".
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.
Thanks for taking the time to reply, and for your work !
--
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/702b5058-19d0-8bc7-0f74-bc6d49e7f0a9%40maa.bz.
For more options, visit https://groups.google.com/d/optout.
