Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Network-based Encrypted Backup in 15 Minutes 25

Posted by timothy from the avoid-the-noid dept.
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."
This discussion has been archived. No new comments can be posted.

Network-based Encrypted Backup in 15 Minutes More

Network-based Encrypted Backup in 15 Minutes

Comments Filter:

  • 15 Minutes for a Pizza? (Score:5, Funny)

    by neonprimetime ( 528653 ) on Monday July 03, 2006 @02:15PM (#15651358)
    The 15-Minute Backup Solution
    Secure Network Backups in a Heterogeneous Environment in the Time it Takes to Have Pizza Delivered

    That's some crazy Sh!t ... Round here it's more like 1 hour

  • Hi, Senator Stevens! (Score:2, Interesting)

    by Tackhead ( 54550 )
    > 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."

    So you want to talk about the consumer? Let's talk about you and me. We use this internet to communicate and we aren't using it for commercial purposes.

    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

    • Stevens is a scumbag. During hearings on price gouging, Sen. Cantwell wanted to put them under oath Stevens shut her down. Then they lied. Stevens made it possible. They pissed all over Congress, and the U.S. public, and Stevens held their dicks.

  • It only takes 15 minutes... (Score:3)

    by Homology ( 639438 ) on Monday July 03, 2006 @02:30PM (#15651451)
    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.

  • 15 minutes?!? There's a catch. (Score:4, Insightful)

    by sakusha ( 441986 ) on Monday July 03, 2006 @02:58PM (#15651618)
    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.
    • Where do you get that you don't have any way of testing that the backup works? That's flat out wrong. Amanda provides tools for browsing backups, performing partial restores and more.

      http://www.amanda.org/docs/amrecover.8.html [amanda.org]
      • I checked the man page, there's a command "amverify" but it merely tests the backup dataset for internal consistency, it doesn't verify it against the original. This is a recipe for disaster. I can think of multiple scenarios where I could perform a backup that is internally consistent but will not work upon restoration. In fact, MOST of the backup systems I've ever seen have no method to truly test integrity other than a full restoration on a duplicate hardware system and then running a bitwise comparison

    • Re:15 minutes?!? There's a catch. (Score:4, Interesting)

      by gbjbaanb ( 229885 ) on Monday July 03, 2006 @03:53PM (#15652025)
      That depends - if you perform incremental backups then 15 minutes of more than feasible. Try BackupPc [sourceforge.net] for a easy-to-use rsync solution with a web front end for restores. I'm not sure about the encrypted bit though, but it can copy over a SSH tunnel.

      Alternatively, try Mozy [mozy.com] for 2 gig of free online encrypted backups with individual file restores. (yes, someone hosts it and they expect you to pay for more storage space, but its useful for your important stuff at least)
    • Well you could have an encryption offload engine that goes at full tilt, and assuming you have something that will sink 10GbE at full speed for extended periods of time you could do it in a shade under 16 minutes. Thing is you will real *BIG* iron for it to take that amount of data in that short period of time. It will nicely fit on one DLT-S4 tape, but that only goes at 60MB/s, and even RAID0 hard disk system is not going to be that fast.
    • I think your right about testing the backups. It would be nice if it could run when I'm no using my systems, and make a working backup. I have had failed restores from all kinds of products and individual applications not working with future versions.. a nice dependable, encrypted, automatic backup would be nice to have though, although for many of us it may tak days to unencrpt and get a working verison going. If it were possible and set up with your os and main programs / docs on one drive with huge media

  • 15 minutes ? (Score:5, Interesting)

    by B2382F29 ( 742174 ) on Monday July 03, 2006 @03:09PM (#15651674)

    Far too long. I just use rdiff-backup [nongnu.org] for easy incremental remote backups (Including ACL and extended attributes).

    I still don't know why it is so unknown...

    • same here - rdiff-backup is a complete no brainer for small scripted backups. Try Boxbackup [fluffy.co.uk] as well - a little more work to set up, but it's got a native windows client that works well and is easy to manage for a larger install.

  • I think this is dangerous advice.... (Score:5, Insightful)

    by gweihir ( 88907 ) on Monday July 03, 2006 @03:33PM (#15651862)
    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.
    • 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.
      • 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. I

  • rdiff-backup for the win! (Score:2, Informative)

    by Anonymous Coward
    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...p

  • DIsk-based backups (Score:2, Informative)

    by Fred Nerk ( 128328 ) *
    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
    • Couldn't agree more about backup to disk, having worked for one of the largest backup software provider for a number of years I use backup to disk as well. But as most people fail to realize, and has been mentioned here as well backup is less than half the story, if you do not test / ensure you can restore your data then time and effort spent on the backup process is wasted. I use a offsite backup product from Rune Solutions, i.e. I wrote and use my own sofware.
  • 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 yo

    • cryptsetup -c <algo> -b <size> create sdXN /dev/sdXN
      mount /dev/mapper/sdXN /backups
      rsync -aR [-c] [-z] --delete -e ssh somehost:/dir /backups/somehost/current/
      cp -al /backups/somehost/current /backups/somehost/`date +%Y-%m-%d`

      There. Every backup is a full one, only changed data take space on the disk, and it's encrypted to boot. A simple croned script can do the job for you and also purge old backups after a set time and/or pattern and notify you if your disk is filling up.

  • It has a number of benefits, in particular the windows client can also store permission information and open files:

    http://www.bacula.org/ [bacula.org]

    It can also do bare metal restores for some platforms.
     

Slashdot Top Deals

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn

Close