Qubes + Dropbox for file backups

User Support
1

Hi, this isn’t a specific qubes question (I think).

I have a qube that I use for my PhD work. There is nothing terribly exciting in it, my PhD is in law and cybersecurity.

I have just over a gig of files, of which most are PDFs of other articles (my zotero library) and files and presentations that I have written, along with some other random bits and pieces.

Right now, I have a script which rsyncs this PhD directory in the plain to another debian box which I own and which sits at my house. This script only does syncs when I am working on my home network, and the box then mirrors the files to another drive, so I’m covered in case of drive failure on both my qubes machine and on the debian box.

I then installed dropbox on the qube, and I have my PhD folder set as a dropbox folder, so as soon as I make a change there, it syncs with dropbox. I want cloud backup as well in case of theft of both debian box and qubes box, or a fire or something equally as catastrophic.

I would ideally like to not have the files in the clear on either my own server or on dropbox. However, the most important thing is that the backup works!

I have been messing about with doing something like:
bash script a command which tars my PhD folder into an archive.tar.gz, gpg it using the public key of a pair which I created for this process, then remove the tar.gz. then move the .gpg file into dropbox.

This would run every 30 minutes.

However, this seems rather computationally heavy and inefficient, as I’m using up 2x the space of the original folder (it doesn’t seem to compress worth a damn) during the process. I’m also not taking advantage of the fact that my folder don’t change the much so a lot of work is repeated.

My qubes machine is an x230 so not exactly endowed with an abundance of RAM or CPU.

Finally, I have to wait while dropbox then syncs the new file from scratch.

Am I missing a trick by not using some native qubes mechanism? Is there someway to just work on the diffs rather than starting from zero?

Should I just keep with what I’m doing?

2

Why you need to tarball your phd folder? why not sign each file, so you don’t repeat the process.

3

I’m afraid I don’t understand your question.

Are you saying that each individual file should be encrypted separately?

4

Ah so you did encrypt the file, i thought it was only signing file.
Aren’t private folder are enough ? since no one can see it.

5

For differential, client-side encrypted backup, there is borgbackup and restic. They are also versioned.

(For borgbackup, you may want to have only one system write to the backup repo (see the security section on their website for the problem with multiple writers). Not sure if a similar caveat holds with restic.)

1 Like
6

@JustAnotherQubesUser
Have you considered Mega?
Y̶o̶u̶ ̶g̶e̶t̶ ̶5̶0̶g̶b̶ ̶f̶r̶e̶e̶
edit: (heh they’ve lowered new account to 20GB)
It uses Zero knowledge encryption so even they cant access your data.
Should automatically backup whatever folders you specify so long as that VM has sys-net access.

7

i personally think they encrypt your data, but they have your key

8

@ppc
Since Mega was seized from Kim dotcom by NZ government I wouldn’t trust them with secrets your life depends upon. but in theory its good.

Also now lastpass can now reset your passwork with a phone number.
not hard to spoof a sim (especially for feds) = compromised.

A long time ago i used SpiderOak which was free & encrypted data locally before sending to the cloud provider of your choice. You just put your files in a folder and it encrypted them before going to the cloud. But it seems they have changed their business model and now you have to pay and use their cloud.

looks like https://cryptomator.org/ have stepped up to offer what spideroak did. Open source too. Windows, Mac, Linux, iOS, Android. This actually looks like a nice option.
Nice simple write up here by the Nation University of Singapore.
https://nusit.nus.edu.sg/technus/securing-data-in-the-cloud-with-open-source-software/

9

Ok i just set this up for fun in my Debian VM

  1. Installed Mega
  2. Installed Cryptomator
  3. Add Cryotomator vault to list of folders for Mega to sync (Drill down into the actual vault not the root vault folder that stores your keys or you will be giving those to Mega)
  4. Files are now auto encrypted before uploading to Mega (which should mean they are double encrypted).

Working flawlessly.
Guaranteed Zero knowledge cloud encryption :sunglasses:

3 Likes
10

I guess it is the age old problem; how to encrypt securely, robustly and efficiently but with minimum user requirements.

I would like a service that provides the ease of use of Dropbox but where the files are encrypted locally before they make the journey to the cloud. Added to this is the requirement that the software / service will probably be around in a decade or so.

It would be great if Qubes could just spit out a file automatically which was the encrypted, compressed contents of whatever you wanted backed up.

11

I don’t know if this might suit you but I have often used the following application and it works very well:

1 Like
12

@JustAnotherQubesUser
the setup i described with Cryptomator is what you’re asking for. you just have to install it, once setup you just mount your vault and save your files in there, they will all sync automatically. 20gb on mega. PhD stuff secure.

13

@spergynerd
this is interesting. just took it for a spin.
not bad, native mega support, so no need to have maga client also installed. more of a scheduled backup than instant, but does what @JustAnotherQubesUser wants where he can just dump files in a regular folder and let them go up to the cloud of his choice.

14

It looks like you’re looking for a Qubes-native solution. Here’s a general rule of thumb.

When thinking about the kinds of problems Qubes itself can help you solve, think of each qube as a blob. In this case it means, what you’ll be able to do is to backup the whole qube with the backup util. You can then of store that encrypted backup in another Qube that syncs that file to dropbox. But this is not ideal as it’s not versioned so it would 1gb every time you run it. Also you’d have to run it manually or set some automation.

So in this case it’s probably best a solution beyond Qubes and within one particular qube. So then the question becomes: how do I do encrypted cloud syncs in Fedora/Debian/etc.? And these are not qubes-specific questions. (some others here have already pointed to a few tools).

I hope this helps.

15

At least for syncing with your own Debian box you could consider the following setup:

  • On your QubesOS machine encrypt the files using file-based encryption, e.g. fscrypt (assuming Linux).
  • To synchronize use Syncthing on both machines and sync only the directory that contains the encrypted files. Only changed files get transferred.

This obviously does not work for Dropbox, because you cannot install Syncthing there, but for that there is Cryptomator. :wink:

16

Thanks for the responses.

Looking at Cryptomator, would it not make more sense to have a Veracrypt file which is opened (manually / bash) when the PhD Qube is started, and have a rsync set up every few mins so that the contents are kept up to date.

The veracrypt file would live in a synced dropbox file.

VC has been around for a while, while the options mentioned don’t seem to have much in terms of reviews / community?

I know that this is something which can be really over-complicated, and for me the most important thing is robustness, followed by simplicity. It just seems wrong to keep so much data in the clear.

17

IIRC, may be mistaken though:
Veracrypt creates a single container for all your files (like LUKS).
Now, when you connect to that container in your Dropbox, open it locally and change a file, the sync needs to transfer the complete changed container back to the box instead of only the single changed file.
That’s why I suggested file-based encryption.
While I do not know of any external fscrypt-audits, it is at a Linux standard included in modern kernels.

18

You are correct, in that a single container is created.

However, my understanding of the Dropbox program is that is doesn’t have to resync the entire file. It works on the diff (I’m not sufficiently technical to go into detail beyond this).

@deeplow yes, I had looked to see if the native backup tool would work.

I’m just a bit surprised that a privacy focused OS, when offering tools such as a secure password manager, doesn’t include a means to selectively archive arbitrary files/folders remotely. Although I guess it isn’t your (Qubes) wheelhouse, I’d be surprised if most users haven’t cobbled something together to allow arbitrary encrypted cloud backup.

19

Actually, Qubes is more a security-based OS than a privacy-based one. Although it tries to be helpful for privacy, too.

This looks like a problem of the underlying operating systems you are running in the VMs, not the problem of Qubes itself.

1 Like
20

Yes, I’m probably just grumbling that my problem isn’t being solved!

Yes, but Qubes ships with two main templates.