Slashdot Mirror
Network-based Encrypted Backup in 15 Minutes
Amanda writes "Many of us plan for mundane (but important) tasks like setting up backup during long weekends. Much of it is because of complexity and cumbersome nature of the tasks involved. This article shows how to quickly and securely set up a network-based backup, all using freely downloadable software tools like Amanda, Samba and Tar."
The 15-Minute Backup Solution
... Round here it's more like 1 hour
Secure Network Backups in a Heterogeneous Environment in the Time it Takes to Have Pizza Delivered
That's some crazy Sh!t
You're goddamn right we do, Senator Stevens, and services like this are why you're wrong on Network Neutrality. It's got nothing to do with video on demand, and everything to do with your campaign sponsors trying to legislate innovation out of existence.
if you already know your backup needs, know the applications your are using for backup, know how to configure the applications and don't do any testing that your backup actually works.
The article is nothing but a stunt.
The catch is, it's supposed to take 15 minutes to SET UP the backup system, not to actually PERFORM the backup.
I suspect it will be a long time before I have a fast enough network connection to back up my (90% full) 950Gb RAID over a network in 15 minutes. And then there's the issue of the CPU horsepower required to encrypt all those hundreds of gigs of data. And come to think of it, this system doesn't really have any way to test if the backup actually WORKS, other than by restoring it to the primary system and wiping out the original data. And you know what will happen if you restore a hosed backup over your live production system.
Far too long. I just use rdiff-backup for easy incremental remote backups (Including ACL and extended attributes).
I still don't know why it is so unknown...
Move Sig. For great justice.
It seems to me that the 15 minuten setup guide does neither do nor stress the importance of comparing the backup to the original after it has been written. Comparison serves two purposes:
a) Make sure your backup is readable
b) Make sure your backup decrypts and is equal to the original data
Especially b) is often not the case due to RAM errors and other problems. With encryption a single bit-error after encryption can make your whole file permanently unreadable. a) can be violated by a number of things, but when you need that backup, it is too late to find out.
Never, ever do backup without full compare afterwards! From time to time do a full restoration to other hardware to be sure you know how to do it and that it works!
Seems to me this is really worth only the 15 minutes you need to put into it. But it can give you a dangerou, false sense of having understood how to do good backups.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
My favorite secure backup solution is rdiff-backup. It compiles and runs under window, linux or osx...
All traffic is sent over ssh...
It took 2 days to do first backup of my music collection...but subsequent runs only take 3-4 mins now (we are talking over 100 gigs)
Another nice feature of rdiff-backup is that it uses diff's to store changes to files...so you have a current 'mirrored' copy of data...and then you can pull up old versions using its diff features....
Of course it's a single command line tool...perfect for cron scripting, ect...
Another testitment to its speed - I use it to backup some linux virtual servers home directories...it can complete about 300+ servers in 15-25 mins....joy!
Enjoy! I know I have! =)
Backups-to-disk are becoming much more popular, I suppose because disks are now so much cheaper than tapes, last longer (IMHO) and are much more reliable. I had a lot of trouble at a previous employer with backups to tape - mostly in the fact that I could *never* do a restore, because tapes would just lose stuff.
So I wrote dbackup (shameless plug for an open-source system here) to be an extremely simple way to backup multiple filesystems on multiple servers to a central archive (in my case on a NetApp filer), which then did it's own tape archive thing which never worked.
It's a couple of perl scripts, it's really really simple, and it takes minutes to set up.
http://dparrish.com/dbackup/
Anything is possible, except skiing through revolving doors.
Let's just get something out of the way here.
Incremental backups are not full backups.
There, that wasn't so difficult, was it?
Saying that you can finish your backups in 15 minutes because you're doing incrementals is almost entirely false. You can finish your incremental backups in 15 minutes. You can backup the delta of your data in 15 minutes, but not the data itself.
Where's the difference? Trying to restore to yesterday with a two year old full and a series of differentials will take ages and increase your risk of failure enormously. Trying to restore with a two year old full and a cumulative incremental is basically using two complete data sets instead of one.
Incrementals are a tool to be used alongside fulls. Synthetic fulls may be a way of avoiding actually backing up your entire data set, but it still takes time to spin tape (or disk), and is new technology.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
I used to work at a place that as part of the backup, the compare function was run. After 12 months of pestering I pursuaded the IT manager to actually try restoring the tape and guess what?... the tape wouldn't restore.
In fact non of the tapes from the last 12 months would restore!
After the drive was repaired things were checked a couple of times, then the compare function was relied upon again.
I left a while later and AFAIK a restore has still not been tried.
No sharp objects, I'm a programmer!
It has a number of benefits, in particular the windows client can also store permission information and open files:
http://www.bacula.org/
It can also do bare metal restores for some platforms.
Deleted
I used to work at a place that as part of the backup, the compare function was run. After 12 months of pestering I pursuaded the IT manager to actually try restoring the tape and guess what?... the tape wouldn't restore.
That points to broken software. The ''compare'' might not even be a compare! It might be a checksum testing or the like. That is basically worthless.
Personally I use GNU tar for backups and the compare has allways been reliable. However I do test restores every few months, just to be sure. It never ceases to amaze me how many people just use some sort of backup, but never make sure it really works. Seems that data is still not percieved as mission critical, although it usually is....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.