> Well yes, but I wouldn't call the case of databases, especially if
> they're backed up by modules specific to the database, a case of
> compression in the sense that people usually mean it.   Databases have
> much in common with spare matrices where they can be largely empty
> space.   And we see that freqently a database dump is way, way smaller
> than the database.   So the real issue was, I thought,  what people
> could expect under normal circumstances, which would certainly not be
> anything like 260 gb on a 100 gb tape.

It can still happen, I would just be suspicious of it happening
constantly.  Most of my experience is with 35/70 DLT7000s.  My Exchange
databases were rarely outside the 53-57GB range.  Day in, day out, very
consistent.  Portions of the database itself must have been compressed.

Most of our full backups were pretty close to standard, from 60 to 80
GB, with somewhere around 66-68GB being about normal.

The incrementals were all over the board, but tended to compress more
than the fulls.  I had several 100GB+ tapes.  That's more than 2.8:1.
The average was much closer to 2:1, but I never calculated a real
average.

Any tape that reported more than 120GB was suspicious and I checked it
out.  I did have some problems a few years ago with some tapes getting
portions overwritten, so the reported figure was greater than the actual
figure.



--
Darren Dunham                                           ddunham AT taos DOT com
Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=