# Offsite backup - would encryption be a sane option?

## Bigun

I've never encrypted anything in linux (beyond using SSH tunnels), and I've got a possible scenario where some semi-personal data could potentially be exposed.

I have my home server where I keep all important documents, my kid's photos, home movies, etc.  These are offloaded via SSH tunnel to an offsite backup.  The offsite backup location is my my workplace, which is a secured location, but nothing is stopping another employee from disconnecting it and taking it with them.  

That said, this backup is being performed by a Raspberry Pi, therefore anything that decrypts the drive from the Pi itself could be attained just by pulling the SD-Card.  In my mind, it would be better if the remote machine had the ability to decrypt the drive remotely, if that is even possible.  And if it isn't, is this just an exercise in futility?

----------

## frostschutz

If it's an USB drive, kernel 3.17 has this USB-IP thing, maybe that way you could just ... use a USB disk as if it was local.

Alternatively there's NBD which would also let you a remote disk like a local block device, which you could then use for LUKS.

Or you just build encrypted archives locally and upload only the already encrypted files. That's what you'd usually do for cloud storage as well.

Edit:

Whoops, I misunderstood you completely. You want it the other way around, the remote should encrypt? If it's running Linux, that's just a matter of setting up LUKS (or whatever) remotely and then using regular file transfers. Security wise it's a bit weird though.

----------

## Hu

Entrusting the the remote peer with the cryptography is strange if you are worried that it could be stolen or modified.  The simple way to handle this is to locally create an archive, encrypt it with gnupg, and then send the encrypted archive.  Create a secure backup of your key material, since no one, not even you, can read it otherwise.  The key material could change infrequently enough that it could be put in a personal safe or a safety deposit box.

----------

## Bigun

 *Hu wrote:*   

> Entrusting the the remote peer with the cryptography is strange if you are worried that it could be stolen or modified.  The simple way to handle this is to locally create an archive, encrypt it with gnupg, and then send the encrypted archive.  Create a secure backup of your key material, since no one, not even you, can read it otherwise.  The key material could change infrequently enough that it could be put in a personal safe or a safety deposit box.

 

Never thought of it that way.  Keep in mind it is a 3 TB array and an external 3 TB drive, will I need to allocate extra space somewhere to create the encrypted bundle?

*edit*

Also, wouldn't this wind up being a full transfer every time?  I would assume the encrypted bundle would change everytime, initiating full need to transfer the whole load.

----------

## Hu

You did not specify that the volume was so large.  You could create a differential backup based on what has changed since the previous backup, then encrypt and upload that.

----------

## Bigun

 *Hu wrote:*   

> You did not specify that the volume was so large.  You could create a differential backup based on what has changed since the previous backup, then encrypt and upload that.

 

I'm not familiar on how to do that.  Currently I just rsync the volumes over an SSH tunnel.  From what I can tell this would be vastly different.

----------

## szatox

How does your backup process look like? If you have random access to files stored offsite, it might be as easy as creating a container file and mapping them as a volume for crypto device.

----------

## Bigun

 *szatox wrote:*   

> How does your backup process look like? If you have random access to files stored offsite, it might be as easy as creating a container file and mapping them as a volume for crypto device.

 

I have two major components in play:

1)  Home server with a 3 TB media array

2)  Remote Raspberry Pi with external 3 TB HD

Here is how my backup currently works:

1)  Home media center initiates a secure shell with the Pi

2)  Through the secure shell, the media center initiates an rsync session between the home media array to the external offsite drive

3)  If the rsync command was successful, the media center deposits the date/time into a file and initiates another sync for that one file to the Pi

4)  The Pi reads that file and displays that date/time on an external LCD so I can verify offsite backup was successful at a glance

The whole process takes about 8 minutes on average (depending on how much data needs to be updated).

----------

