I have a problem with pseudofloppys

I have a customer that has a big database, more than 2 GB in a
pseudofloopy. They have create a multireel backup system , compressed,
on pseudo floopys. The problem is that , even when they have define
correctly the multireel, they try to define 2Gb per reel (the systems
does not admit more). It works well but each pseudofloopy has only 500
Mb. it seems that D3 counts the MB of the pseudofloppy BEFORE the
compress.

This is the which of the D3

:which (cda
System Release Information
==========================
D3 Release Version 7.4.2.RS
Most recent mload into boot abs performed at 20:21:28 on 29 May
2005.
Implementation. . . . . . RS6000
Software Serial Number. . 11031154
System ID Number . . . . 60129545
Release . . . . . . . . . D3/UNIX: RS6000
Unix Information. . . . . AIX;pick0:AIX;3;5;0158194A
Boot Monitor. . . . . . . 7.4.2.M7; 21 Apr 2005
Boot ABS. . . . . . . . . 7.4.2.A11; 07 Jun 2004
Boot ABS Data File. . . . 7.4.2.A11; 07 Jun 2004
System Data Files . . . . 7.4.2.D11; 07 Jun 2004
FlashBASIC Revision . . . 7.4.2.F13; 13 Apr 2005
SQL Revision. . . . . . . 7.3.0.S3; 02 Feb 2004
ABS Patch Level . . . . . 7.4.2.A181; 06 May 2005
:


thanks in advanced

joseba

That is fine - D3 writes out 2Gb of RAW datya, which is then
compressed. The upside is that you can now burn 2Gb of data onto a CD
:-)

We generally set pseudo to 1Gb size - number of pseudo tapes = Gigs of
data

Joseba, this is the way pseudo-floppies have always worked. D3 has no
idea what the size of a pseudo will be after it's compressed. It
generates 2GB of uncompressed data and then breaks to a new data
volume. The fact that you're getting compression down to 25% of the
original size is actually quite good. If you want bigger compressed
volumes then set the size in pick0 to something like 3GB. Even at 50%
compression that will create volumes of 1.5GB. I wouldn't push it and
try to get 4GB in there because then you take a chance of creating a
final compressed volume of >2GB and ... BOOM.

Also note that you can't rely on compressed volumes of 25% of the
original size. Compression is affected by the frequency of repeating
data, which might be site-specific. For this particular client it
seems they have a lot of repeating data. Maybe that's a clue that
there's a lot of redundant data in the database itself. I'll take a
wild guess that this client makes extensive use of indexes on their
primary data files. If these are D3 indexes then you need to ask
yourself if you really want to backup the indexes. Ahh, so many
things to think about...

Regards.
T

"jra" <frelance (AT) sarenet (DOT) es> wrote:

Tony Gravagno wrote:
Personally I would ALWAYS take the indexes on a backup. Anyone who has
REALLY had to use a backup in a disaster recovery situation where
indexes weren't saved will know what I'm talking about (Luke, did you
say that big file had 16 or 26 million records?)

Restored from tape vs build from scratch is painful to endure. If
backups are done out of hours, no-one will notice - and the media cost
(disk or tape) is trivial. Backups are there to save your bacon, and if
you are wallowing in **it, you want to get out as quick as you can

"jra" <frelance (AT) sarenet (DOT) es> wrote
TAPE /u/bupdir1/pickbu 500 P LX # autogen

mkdir /u/bupdir1 ; touch /u/bupdir1/pickbu ; chmod 666 /u/bupdir1/pickbu

In use, the system will fill up pickbu with what was 500kbytes before compression,
then create file pickbu-1 with more, then pickbu-2 with more, etc...

This way you do not need human intervention to complete large backups.

Larger figures, like 100000 instead of 500, give the traditional one file backups.

This feature works on d3/sco and d3/linux, but I have not tried it on d3/linux.
I'm guessing that there's no such feature for d3/nt.

Frank Winans wrote:
Lager numbers actually just mean that more information is written out
before compression, so that you don't end up with tens of thousands of
files !

If you get a single file, then it simply means that your raw data was
smaller than the volume sze set

Thanks to all. I know now how it works. It count the bytes BEFORE, as
Tony says. And you cannot put a size bigger than 2000000 (at least in
the chg-device sentence)

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote
small tape size. If you have 100000 listed and exceed that during a save, the system
prompts for another volume, and awaits your response. Again, I'm not sure they
ported this feature to the D3/Aix product.

Quite a humorous typo -- when I saw "Lager numbers" I thought of Bistro Math!
{a reference to 'Hitchhikers Guide' series}

"Frank Winans" wrote:

Sorry Frank, that's a bit backwards. 500 is the default and ensures a
single backup file with _no_ cascading. In fact, if that parameter is
anything less than 1000 there is only one file. If it's 1000 or over
then the files will cascade as you mention to files of size*1000
bytes, tagged with -1, -2, etc. (1000=1MB, etc)

In case anyone is curious, the value doesn't mean anything anymore for
any device other than pseudo floppies. (Pseudo-stiffies?)

You're correct that D3NT doesn't have that feature yet, and I haven't
heard anything about it being in D3 7.5 (replaces 8.0). There are
utilities available to break up binary files into smaller blocks.
Personally I'd prefer to do this after the save and get a number of
consistently sized compressed files rather than the variably sized
files we get when size is considered before compression.

HTH
T

"Tony Gravagno" wrote
500 gives cascading, big figures don't give cascading.
I guess that's bad news for the original poster in this thread -- he was
using 2000000 and didn't seem to be getting cascading on his d3/aix
release.