[SATLUG] backup recommendations

[tom weeks]

On Sunday 04 March 2007 10:46, Daniel J. Givens wrote:
> I didn't get tweek's reply yesterday for some reason, so I'll reply here
> along with my reply to Luis.
>
> I never said backups can be replaced with RAID. I'm saying that many people
> don't need long term archival of data.

True.. But my reply was to your comment of:
"As a whole though, I do not trust tapes as much as I trust redundant disks."

But given your comment below, I now understand the context of your statement 
more.

> I was simply stating that with a 
> disk based backup solution, you can utilize RAID to make it more robust in
> the cases of disk failure, which was in response to someone saying I had
> too much trust in disks.

Ahh.. okay.. now I see what you were trying to communicate.
You're talking about the inherent unreliability of backing up one data set to 
streaming backups to tape pools/sets... where you need all the tapes to do a 
restore (or the same problem if single tapes are used with incremental 
backups that require all tapes since the last "full" backup).  Yeah.. that IS 
a well known problem.  Classically it was addressed through good tape/drive 
cleaning procedures.. using occasional differential backups, etc.. but 
there's much cooler ways of getting around this now.

> To the best of my knowledge, you can't get RAID tapes. 

Actually.. you can.  Funny enough. It's actually called "RAIT". heh:
http://wiki.zmanda.com/index.php/Rait

Not sure about if/how older enterprise backup suites like Legato, ARCserv (or 
basic systems like dump) support that or not.. But some newer and some open 
source suites like Amanda do! :)
http://www.amanda.org/docs/rait.html

> You can make copies 
> of tapes, but if the tape goes bad, which always seems to happen when you
> really need the data, you're screwed.

In the classic idea of streaming tapes (writing a single or multiple data sets 
or backup stream(s) to multiple tape drives simultaneously for backup 
speed).. that was more like "RAID-0", if you'll excuse the comparison.

Int he old days it sometimes had to be done to increase backup speed at the 
cost of backup reliability.  But things are different now with things like 
disk based CRC (parity) and RAIT.

> That is why I like disk to disk 
> backups. In every place that I've worked that used tapes, we had one set of
> tapes that sat in the jukebox all year long. The tapes were rotated
> automatically, but the restores we did never went past a week and the tapes
> were overwritten within 30 days or so and we had no requirements for
> maintaining long term backups.

Ahh.. yeah.. If you're not even physically rotating the tapes to some off site 
storage location.. then no, tape doesn't give you any huge advantages except 
maybe archival shelf life, etc.  But some newer holographic technologies will 
be beating tape out soon (for enterprise backups anyway).

Drive are just to heavy, bulky and fragile to be rotating, moving and 
shuffling around in a true enterprise backup system.

That being said.. if you can afford enough of them.. some people use SAN with 
snapshots for near term backups/access & recovery, and then archive SAN 
snapshots to tape and rotate that off for long term.

But if you want near the same functionality at a couple of orders of magnitude 
cheaper.. then look into local disk snapshots/backups combined with tape.

> So that is why I advocate disk to disk and disk to remote disk solutions in
> instances where you don't have to maintain LONG TERM archives.

Off site disk  != Long Term.  "Long term" storage or what's called "retention 
& archiving" usually has more to do with your storage medium, tape pool 
sizes, and rotation policies.  

BTW.. One big reason for people not doing large backup/network implementations 
is because it's usually just not feasible to be backing up 100GB or more over 
the traditional network due to time for moving that amount of data (unless 
you're using something like iSCSI, Gb ENet, or Fibrechannel etc).

Tweeks