SLUG Mailing List Archives
Re: [SLUG] Tape drives
- To: Stephen Robert Norris <srn@xxxxxxxxx>
- Subject: Re: [SLUG] Tape drives
- From: Tony Green <tgreen@xxxxxxxxxxxxxx>
- Date: Thu Aug 16 09:13:01 2001
- Cc: Peter Rundle <peter.rundle@xxxxxxxxxxxxxxxx>, Slug <slug@xxxxxxxxxxx>
* This one time, at band camp, Stephen Robert Norris said:
> On Thu, Aug 16, 2001 at 08:55:06AM +1000, Peter Rundle wrote:
> > > Anyway, its generally bad, and the whole thing with Companies citing
> > > 2:1 compression ratios when listing device capacity is bulltwang and
> > > is quite dishonest IMO
> > Ahmem to that. When I buy a 9Gb disk I get a 9gb disk I don't get some
> > bulltwang about it being 18Gb if I put a compressed file system on it.
> > But tapes, lying hounds!
> The only plus sides to it are:
> a) You might get the data on the tape rather than not have a copy at all.
> It's probably better to fit data on the tape (once the tape is too
> small for the uncompressed image - about 2 weeks in my experience :)) and
> have a dodgy backup, than not have a backup at all!
> b) It's faster.
> And HDD drive manufacturers lie too - they just lie by about 2.5% instead.
> Only RAM sizes seem to be correct, and that's probably because there are
> good harware reasons why you can't fiddle with them :)
in a corporate environment (and research as XFire pointed out on #slug)
you will be lucky to get the tapes you really want. You'll fight tooth
and nail to convince the PHB's of the advantages of uncompressed backups
- but when it comes down to it - it will lower costs significantly (so
long as you don't end up loosing data).
Go for compression on a file level (eg make sure you are archiving a lot
of compressed files rather than creating a single compressed tar file
containing a lot of other files) - this should reduce the chance of
loosing a lot of data if a tape fails.
Mind you - I'm still stuck on the DVD-RAM jukebox (80 DISK!!!) that
XFire found! Oh for more deep pocketed VC's!
GnuPG Key : 1024D/B5657C8B
Key fingerprint = 9ED8 59CC C161 B857 462E 51E6 7DFB 465B B565 7C8B
Imagine working in a secure environment and finding the string
_NSAKEY in the OS binaries without a good explanation
-Alan Cox 04/05/2001