Backups are an important element of system maintenance on any system, and should be, at least in my opinion, mandatory for all users to perform regularly.  Without doing backups, you could find yourself in a world of hurt.should something bad happen.  But there are some things that even the best backup system in the world can't protect you against.  One of those is nature.   Given that this year has seen major earthquakes, a record tornado season, a planned record hurricane season, and other natural disasters of types we can't even begin to imagine, keeping copies of your backups in a remote location, or away from your home or business (aka offsite backups) is an idea that will save you should the worst ever happen.   So let's look at a few possibilities that will provide you with simple piece of mind and security for your data.

Automated Remote Site Backups

The first assumption in this tutorial is that you have a high speed internet connection.  The second is that you're performing some kind of manual or automated backup on your system.   Without these two, most of this tutorial will be of little use to you.  Now that's not to say it will be completely useless, as I plan to show you other ways of doing things that don't require an internet connection.  However, it does simplify things quite considerably in some areas.

Now as for what you'll do for off site backups, that depends a lot on how big your organization is.  If you're a big, multi-million dollar company with a lot of valuable data to protect, organizations like Global Data Vault or Iron Mountain might be right up your alley.  But for the average individual, or the small business, a remote file server of your own design may be the better option.  If you already have a file server setup at home, I would recommend building a second one and putting it in a remote location no less than 5 miles from your home or business.

The idea with that strike your home or business do so within a limited 2-3 mile range.   This can include flooding, severe weather, and more.  There are however times when things happen over a much wider area, such as with hurricanes, earthquakes and more.   Now these might seem like extreme examples, but if you don't prepare for the absolute worst, how are you truly prepared for anything?  As one famous writer once said, "Prepare for the worst, and pray for the best."  That philosophy is true even in data backups and storage.

If you've setup your own personal file server as listed in this tutorial, then you're one step closer to having a working remote backup solution.  There are a few modifications though to that file server setup that I will recommend if you're going to use it as just a dedicated remote backup server.  You should do everything in the first three pages as prescribed down to the letter.  The only change I can recommend will depend on how you plan to perform your remote backups.  If you plan to automate them, you'll want to skip specifying passwords for the ssh keys.  Since you can't enter the ssh key access password from a command prompt via cron, having one without a password is important.

Now that might seem to lessen the security of the ssh session a bit, but if you're automating things, some minor sacrifices are necessary.  If you will be doing these by hand, then you can leave everything as is.  The next 3 pages in the tutorial you can comfortably ignore, since you won't be doing any file serving, or mail serving on this server if it's being used just for dedicated remote backup storage.  Of course if you're repurposing another server to fulfill both of these tasks, then that's fine as well.

Once you have your server built, you'll need to take it down the road, or over to the next city, or wherever you can find someone who is willing to keep it for you, and then drop it off.  Make sure everything works on their end before leaving, including configuring firewalls and port forwarding to allow you to access the server from the internet.  Also note, whoever is keeping it for you should also have a high speed internet connection and should be no less than 5 miles away.  Once that's done, the next step is very easy to setup and test.

When you get home, first ssh into the box using your secure key.  You should have verified this at the remote location, but even so it's still a good idea to double check.   Next, you'll want to create the following perl script for your backups.

=============================

&rbackup;

sub rbackup {

   # Define arrays for the day of the week and month of the year.            #
   @days   = ('Sunday','Monday','Tuesday','Wednesday',
              'Thursday','Friday','Saturday');
   @months = ('January','February','March','April','May','June','July',
              'August','September','October','November','December');

   # Get the current time and format the hour, minutes and seconds.  Add     #
   # 1900 to the year to get the full 4 digit year.                          #
   ($sec,$min,$hour,$mday,$mon,$year,$wday) = (localtime(time))[0,1,2,3,4,5,6];
   $year += 1900;

   # Format the date.                                                        #
   $date = "$months[$mon] $mday, $year";

   $rbackup = "/usr/bin/scp -r -P ### -i /home/user/id_dsa /drive2/backup_folder/$date/backup.rar user@192.168.0.1:/drive2/backups/$date";

   system($rbackup);
}

================================

Now save the file as rbackup.cgi.  Be sure though before you do that you change everything in red to match your system.  IE, the path to scp, the port number ssh is listening on at your remote backup server, the location of your secure key file, the path to your backup folder and file, and your user, ip, and remote storage path for your backup files.  Next, you'll want to add a crontab entry so that the system automatically performs the remote backup the same day you do your regular backups.  If you want, you can modify your existing backup.cgi file to automatically complete the remote backup as soon as the regular backup is complete.  Just add the line "&rbackup;" below the line that reads "&backup;", and then put the rest of the text above at the end of the file.

Now if you're backup data in quantities greater than 500mb, you may want to reconsider doing remote backups, unless of course you've got an uber fast upload on your end, and your friend at the other end has an equal download speed.  If one of you either doesn't have enough internet connection speed, or one of you doesn't have an internet connection, you will need to consider using the next method for remote site backups.  

Manual Remote Site Backups

"SneakerNet" is a tongue in cheek term coined in the early PC days that refers to doing data transfer from one machine to another using some form of removable data storage and your own two feet.  Hence the term "SneakerNet".  If you are unable to do automated remote data backups as mentioned above, you'll be forced to take a different approach to ensuring your data is safe.

The best way I know to do this comes in several forms.  The most practical and least likely to suffer failure is a simple hard drive in a portable drive enclosure.   With this you simply plug it into your computer, copy over the backups, and then drive it (or if the location is far enough away, you can send it by postal mail) to the remote location where it will be stored.  Sometimes, even if you're doing automated remote backups, this kind of data storage isn't all that bad an idea.  Even I do it to some degree. 

Just find someone you can trust and then stash the portable drive with them until you need it again.  I recommend having several of these drives.  That way you can keep one at your location for future backups, and keep two offsite at one or more secure or trustworthy locations for safe keeping.  Don't forget to label the drives so you know which has the backups you need on it.  Sticky notes and a little masking tape work well for this.  Since you don't need a detailed audit of what's on the drive, simply putting "backups for 05/20/2008" on it should surfice.

Conclusion

Well, that's pretty much it.  There's nothing really fancy to it and most of what you'll do will seem tedious for now.  But when that critical disaster comes at some point in the future, you'll be glad you did this.  Because once data is lost, you'll never get it back.