Backup Script with Transparent Encryption
knnniggett
datastorageunit is the freedom to choose your own backup strategy.
The script I've uploaded in the Files section of this discussion group
represents the method I chose to perform my own backups. The intent
is that the script may benefit someone else. Note that I'm not touting
this as the "best" way to backup one's data. I'm simply showing one
particular way to go about it.
http://groups.google.com/group/datastorageunit/web/dsu_backup.sh
If you download the script, don't forget to "chmod +x dsu_backup.sh"
to make it executable. Once you edit the variables to match your
system, it should run w/o issue on any Linux platform.
The script was inspired by this guide:
http://wiki.rdiff-backup.org/wiki/index.php/BackupToEncfsAcrossSshfs
The only difference is that I chose to use rsync instead of rdiff-
backup as I do not need the ability to keep multiple snapshots/
revisions. Feel free to use rdiff-backup as the backup tool if your
needs differ from mine.
DISCLAIMER
Understand that I am not an expert on encryption. I don't know for
certain how secure this method really is, and since I have just
started using this method I cannot make the "tried and true" statement
that other forms of backup may be able to make. I'm just a guy that
wants to backup his data onto a remote server and make it moderately
difficult for anyone else to view said data. So far it is working
quite well.
ADVANTAGES & FEATURES
- The data files stored on the server are encrypted
- All programs used in this script are based off of known and accepted
standards (e.g. ssh, rsync, encfs)
- Because the encryption method is transparent to the backup program,
you can essentially use any backup program you want.
- If you use rsync as your backup tool, all backup jobs after the
initial backup will be partial/incremental. This is important if you
have a lot of data.
- Cron safe. Once you are confident the script runs unattended,
simply schedule it as a cron job and forget about it.
- The script has lots of error handling to help gracefully exit upon
error and even allow a defined number of retry attempts
DISADVANTAGES
- This method creates a mount point on top of a mount point which one
could argue is not exactly efficient
- While I trust my own data with it, this method is not a "tried and
true" way of backing up your data.
TODO:
- The main loop works great, but I have not yet tested all the error
handling built into in script
- I've noticed that there are multiple timeout, keepalive, etc. type
variables that affect the reliability of the data transfer. If I
receive feedback regarding failed transfers to the remote server, I
may have to take a more detailed look into these.
As always, your feedback is welcomed.
knnniggett
I have uploaded a new version of the backup script found in the files
section of this discussion group.
Changes include:
- Added support for Truecrypt file encryption!
- some minor bug fixes
- added the ability to output a disk usage summary after the transfer
completes
- Increased error handling when things go wrong or just timeout during
a transfer
The user can now choose between using encfs or truecrypt file
encryption.
Adding support for additional kinds of file encryption should be
possible if anyone is interested.
NOTES:
For reasons I am not certain of, on my system Truecrypt seems to run
painfully slow during mount or unmount operations from the command
line. What this means is that the backup script may appear to be hung
while it is attempting to mount or unmount your Truecrypt volume. If
you notice this, please wait another minute or two. In the few cases
I have tested this, Truecrypt seems to eventually figure itself out
and move on.
This script should run on any system that supports bash shell
scripting (i.e. Linux, possibly OS X).
I'm always interested in feedback so please feel free to respond with
questions or comments.
john
Also, in case anyone wasn't aware...you can now create your encfs directories on the server itself...and mount them there. Instead of having to mount them from your computer across the internet. This is an advantage of using encfs over truecrypt...However, TrueCrypt may still be preferred by some.
jmayoralas
mounted... you, as root, could access the un-encrypted volume. Am i
wrong ?
John - DataStorageUnit - Owner
accessed by the systems root account while the EncFS directory is
mounted. Once you unmount the volume...only you can remount it, not
even root can remount...(just to clarify).
Also, just so everyone knows. Only one person has root capability on
this server...and that's me.
If you stick to mounting the directory across the Internet from your
home computer...only admins on your home system can gain access to the
directory.
The main reason I mention this new capability is that it gives you the
ability to move and copy files much more quickly while mounted
locally. If you want to rearrange things a bit, for whatever reason.
FYI...thanks for pointing this out, everyone should definitely be
aware of this.
Martin Larsen
The main reason I mention this new capability is that it gives you the
ability to move and copy files much more quickly while mounted
locally. If you want to rearrange things a bit, for whatever reason
On the other hand, if I, while I am away from home, need to access my data, I can login with Putty on my mobile phone and mount the encrypted folder and do whatever stuff I need to do, then unmount again. It will probably be mounted for just a few minutes.
Without the ability to mount the folder locally, I would have no way to access my data under such circumstances.
Martin