On Wed, 20 Feb 2019 10:38:15 +0000
lik...@gmx.de wrote:
>On 2/19/19 6:22 PM, Chris Laprise wrote:
>> On 2/19/19 10:41 AM, liked2-mmb7mzph...@public.gmane.org wrote:
>>> Hi,
>>>
>>> assume there are files stored in a qube without networking. Furthermore
>>> assume there's a secured backup server located in the internet. This server
>>> is only a storage of client-side (before data is sent over the wire)
>>> encrypted files. What options do you imagine to backup those files (skip
>>> the client-side encryption) to the server?
>>>
>>> I can imagine the following options:
>>> 1. enable temporary the network with firewall restricted to the server for
>>> the (previously offline) qube
>>> Advantage: no inter-vm copying of files.
>>> Disadvantage: firewall rules must be setup correctly to avoid to
>>> bypass any other traffic like icmp/dns etc. I can imaging a potential
>>> information leakage due to enabling network access.
>>> 2. copy files temporary to another qube (dvm?) with a firewalled internet
>>> connection
>>> Advantage: files not being backed up can stay secured in the
>>> non-network cube. Leakage of data is reduced in comparison to 1.
>>> Disadvantage: can take time and needs additional disk ressources
>>>
>>> I've learned that you should always find at least 3 options, otherwise you
>>> haven't thought hard enough. Which options am I missing?
>>>
>>> Which option would you prefer and why?
>>
>> Another disadvantage of #1 is that connecting the net to the source qube
>> exposes it to attack.
>>
>> Had you thought about using qvm-backup? Also, I'm working on a fast
>> incremental backup tool that's suitable for Qubes:
>>
>> https://github.com/tasket/sparsebak
>>
>
>I've checked qvm-backup. It's an appropriate solution if you don't care about
>disk space and bandwitdth of the network connection. Saving of a subset of
>files due to remote space and bandwidth resouces will not work well with
>qvm-backup.
>
>Also incremental backup is not really possible with qvm-backup.
>
>Regarding the solution you're working on: If I get it right, it's meant to be
>a disk->disk backup? What I'm looking for is an incremental client-side
>encrypted backup, similar to the tool duplicati. Also a poor man solution with
>git+rsync+veracrypt would be possible.
>Can you imagine how sparsebak could be combined with truecrypt? Is there
>compression support?
>
My backup routine is this.
Important files are kept in a LUKS encrypted container on specific appVM's,
mounted when needed.
A similar LUKS encrypted container is maintained on my home network server. I
mount the container on my home server over an ssh connection then use rsync.
Different appVM's use different paths within the container, so they all backup
to the same home network based container...which is unmounted when not actively
being used.
If I completely lost my current machine setup, it would only take a couple of
hours to setup a new one...and quite some time to rsync all of the important
files, but solid and repeatable.
My encrypted backup contains 30 years of e-mails as well as financial and
client information. I also keep another backup of the same information on a
completely different physical machine, which while not Qubes can actually run
enough software against the encrypted container to continue with my necessary
day-to-day tasks.
I clone my templates before major upgrades or just if there are questionable
upgrades happening so if there is an issue I can set all of the machines which
use the template to use the backup while I sort it out. I may not make a fresh
backup of a template if the only upgrades are chrome or vivaldi or something
else non-critical.
It is hard to beat rsync...just work a method which is appropriate for the
different appVMs as if they were discrete machines...which they are from a
logical standpoint.
Stuart
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/20190220134645.601128dc%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
