encrypted tape backups

noodlefling

noodlefling

What's the easiest way to create encrypted backup tapes?

Right now, I'm using dump to create the tapes. It's not the most feature-rich system, but when it comes to backups, stability is more important than anything else.

Passing a parameter to dump like "-p <password>" would be ideal, but I'm not going to get that lucky, am I?
 
One way could be after dumping filesystems to use gnupg to encrypt dumps (slow).

You could write sh script to automate this
 
How would that interact with the process of writing to tape? Would you need to create and encode tar files in some way or could it all be done in a direct write to tape?
 
The LTO 4 standard for tape drives from the LTO Consortium now includes native AES encryption capabilities, so that the device itself handles backup. However, keep in mind the purpose of backup is to increase the availability of data. The purpose of encryption is decrease the availability of data. A single bit error and kiss goodbuy to your encrypted data. I will use only vendor supported encryption device.

HTH
 
No love for LTO3, then?

I completely agree with your assessment of the nature of backups, by the way, but we have pointy-haired individuals who have just learned the word "encryption" and they're swinging it around with extreme prejudice these days.

I know tapes would allow for a fairly easy exploit of this of kind of thing, but is there any sort of "passworded dump" possible? This might satisfy the Document Patrol while not being completely unusable and/or stupid.
 
Looks like I might be able to pipe the data through bdes. I haven't had time to experiment myself, and I can't find any useful information about bdes (other than the man page).

I'm not too concerned about the nuts and bolts, but is there anything out there with some examples of how others are using it? I want to get an idea of what's reasonable.

Any idea how much time this would add to a large file dump?
 
This issue got put on hold, but we're getting back to it, and a Google search for more info yielded this thread as the closest to the original topic.

In terms of the LTO4 encryption, how would you actually do it in FreeBSD? It looks like there's a one-time communication with the tape drive itself, after which it just sort of works invisibly. Is there some FreeBSD version of this tool, or would we hook it up to a Windows box once just to set it up or something?

It doesn't look like there's a simple software solution.

dump is such a ridiculously useful and easy-to-use backup method that I hesitate to give it up. And I don't really want to get experimental with something as important as backups.

Have there been any advances in the past year? Any other suggestions?
 
Another couple of years and I'm still responding to myself...

We're considering going to large USB drives instead of tapes. This gives us more options, although it's still not clear what the best method is. Backups need to take place automatically at least once a day, so entering a password at the time of the backup is not an option.

The drive could be left online full time, but it makes more sense to umount the filesystem as soon as the backup is complete. This also would allow us to mimic the current tape swap system (ie, any time during a given day, as long as it's done before the backup starts).

Some testing has shown that dump works perfectly well with a drive instead of a tape, and is faster. There are methods to encrypt each individual file and also the possibility of encrypting the entire drive.

Either is fine as long as the result is officially encrypted drives that do not require entering a password at the time of the backup.

Any suggestions?
 
I encrypt my backups to USB and remote drives (off site backup). I back up unencrypted locally and then send an encrypted version offsite. So this would be the same as the USB drive going off site, you want encrypted backup on that drive.

I use openssl to encrypt the data: openssl enc -e -aes128 -salt -pass file:key.txt

I place the password in a file called key.txt.

So if using tar, here is an example:

Backup:

tar cvzf - /data | openssl enc -e -aes128 -salt -pass file:key.txt -out databackup.tar.gz.aes128

Restore:

cd /data
openssl enc -d -aes128 -pass file:key.txt -in databackup.tar.gz.aes128 | tar xvzf -

You can customize this to meet your needs.
 
I would advise against using -aes128 encryption as the example above suggests. Please consider -aes-128-ctr instead. I am not sure which block cipher mode default -aes128 uses, it very well might be CBC mode.

The difference between CBC and CTR modes, when we talk about backups is very simple: If you have one small block of data corrupt in the middle of the backup, the rest of backup becomes unreadable with CBC mode, while still readable with CTR.


I, myself, also struggle with implementing multi-volume encrypted backups which would work for tapes. I have bumped into the wall: when cassette needs to be changed, the archiver has to close current cassette file, wait for user change the cassette and open new file on new cassette. This is what gnu tar does perfectly, but it can't encrypt. And, if I redirect archiver (tar) output to encrypted stream, the archiver(tar) cannot close-and-reopen the output, thus multivolumes are impossible.

I've tried dar_split which supposed to solve precisely this problem, but... it simply does not work, because it does not close the file while waiting for me to change the cassette. Same problem with old team utility (but, at least, author admits it in the BUGS section...).

At this point I can do unencrypted multivolumes OR encrypted single-volumes... I am thinking, should I write proper dar_split utility myself ???
 
You must log in or register to reply here.
Back
Top