[ale] backup suggestions

[Jeff Hubbs]

Another thing about trying to use additional diskage for backups is that
when most people try it - and this goes for the rsync solution that Jim
Kinney mentioned as well - is that they don't implement a kind of media
rotation that enables you to roll back the machine to a known good  state
from a time preceding the most recent backup operation.  Say you discover on
Thursday that your database files came unhinged on Tuesday, before
Wednesday's backup.  If all you did was to copy Wednesday's state on
Wednesday, then congratulations, you have backed-up a screw-up.  On the
other hand, if you can restore from the most recent good state, say, Monday,
then you've managed to cross the river.  I'm not a DBA, but depending on the
DBMS and how you're running it, you may even be able to roll your DB forward
up to the problem point.

There are lots of managers who just don't "get" backups.  They think you can
use a Jaz drive, a (God forbid) Zip drive, CD-Rs, or another server's drives
to make backups.  It seems that if you come from "PC space," or the "do
things with no money space," or the "run uninterrupted indefinitely" school,
there's a tendency to not think or intuit in terms of recoverability.  

And then there's the issue of what it takes to restore from media when you
need to.  You've got to get a machine up enough to be able to operate its
tape drive and its disk controller.  You've got to be able to handle a bad
spot on a tape.  One of the most intriguing schemes I've read about to date
was one where the machines were not only backed up every night, but they
were RESTORED every night as well.  Yeah, that shop, whatever it was, wasn't
24/7 but darned if they hadn't rendered restoration trivial!!  They had an
extremely high level of confidence in their backups.

What worries me is that while disk drives have exploded in capacity, tape
drives have not, and the issue of multi-volume backup sets run in series or
in parallel arises.  It seems as though tape capacities grew quite nicely
for a number of years, only to have disk drives blast right past them.
Right now, I think ~80GB is the biggest drive I can easily buy (100GB on the
immediate horizon), whereas I think I'm limited to ~75GB on tape - and the
tape drive and media at that level are a heck of a lot more expensive than
the disk drive.  The calculus of all this, I think, are leading people to
blow off recoverability in pursuit of capacity.

- Jeff

> -----Original Message-----
> From: KeithH [mailto:hne at inetnow.net]
> Sent: Wednesday, August 01, 2001 8:14 AM
> To: rob hoppe
> Cc: michael d. ivey; atlanta linux enthusiasts
> Subject: Re: [ale] backup suggestions
> 
> 
> rob hoppe wrote:
> 
> > "michael d. ivey" wrote:
> > 
> > 
> >>On Tue, Jul 31, 2001 at 04:44:13PM -0400, Jeff Hubbs wrote:
> >>
> >>>I'm presuming that by "back up" you mean copy server disk 
> drive data such
> >>>that it can be taken far from the server.  Looks like 
> you're left with IDE
> >>>tape, possibly Travan, and SCSI emulation.  Within-server 
> disk-to-disk
> >>>transfers only protect you from a failed drive or RAID set 
> and nothing more
> >>>serious.
> >>>
> >>Any pointers on parallel tape drives?  Also, anyone done SCSI over
> >>parport?
> >>
> >>--
> >>
> > 
> > Any backup demands a good fast media.  True SCSI is the 
> only sure way to be sure.
> > One person suggested a hard drive backup, this is a good 
> option and should be
> > considered.  Slow drives can be used here and checked 
> easily.  A DLT through SCSI
> > is the preferred method for me.
> > 
> > Rob
> > 
> 
>    I agree with Rob on this one.  If you want speed, reliability, 
> portability, multiple backups, and more of a backup than just 
> a mirror, 
> then tape still rules.
> 
>    And if you hunt around, you can find good deals.  I saw a 
> refurb Dell 
> P120 (DLT 7000 Library {8 tapes I think, about 400+GB}) at a 
> local shop 
> for about $700.  The only downside is that is was HVD SCSI, and that 
> means also buying a $200+ controller, since you can't use it 
> with SE or LVD.
> 
> Keith
> 
> --
> To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" 
> in message body.
> 


___________________NOTICE____________________________ 

This electronic mail transmission contains confidential information intended
only for the person(s) named.  Any use, distribution, copying or disclosure
by any other person is strictly prohibited. If you received this
transmission in error, please notify the sender by reply e-mail and then
destroy the message.  Opinions, conclusions, and other information in this
message that do not relate to the official business of NIIT shall be
understood to be neither given nor endorsed by NIIT. When addressed to NIIT
clients, any information contained in this e-mail is subject to the terms
and conditions in the governing client contract.
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.