I am going to change my ibx with codegear's one.

So it seems, about fitting CD-size backup; without estimating backup
size, the best I can do is to wait till db backup size reachs to 650
mb. Then I can specify first chunk's name and size.

Thanks

Ömür

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 01:40 AM 1/08/2008, you wrote:
> >Hello everybody,
> >
> >I use Delphi 6 and IBX components.
>
> The IBX components that shipped with Delphi 6 are too buggy to use

reliably. I think you can still get improved binaries for Delphi 6
from the Codegear website though...

>
> >I am trying to backup a database as several 650 MB chunk files.
> >
> >What I want to see is, enough number 650 MB chunk file plus one
> >chunk file smaller than 650 MB if necessary.
> >
> >* First, I supply 99 unique name and theirs sizes are 650 MB. On

4

> >MB test db, what I see were one 4 MB chunk and ninetyeight 1 KB
> >chunk.
>
> The last chunk must have no file size specified. If your service

component is implementing gbak -b multi-file properly, then it
should remove the file size for the last chunk.

>
> But this looks OK. All of the backup data from a 4 MB database

would fit into the first (primary) backup file with about 649 MB of
spare capacity. Each of the 1 KB files will contain only the path
to the next file in the sequence and the limit specified as maximum
file size, but no user data.

>
>
> >* Second, I supply 1 unique name and its size is 1 MB. On 4 MB

test

> >db, what I see were one 1 MB chunk and one 3 MB chunk.
>
> Numerically, this is consistent with the first test. The backup

data is slightly larger than 1 MB so a secondary file was created.
However, using gbak "raw", this situation would cause an exception.
It is not valid to supply a file size for the "last" file (the
primary file, in the single-file case). So what this seems to tell
us is that the service component is probably wrapping a handler for
that exception and is automatically requesting a secondary file.
How was the secondary file named?

>
> >So, is it another method to do what I want.
>
> You need to do more testing with *actual* databases of typical

size.

>
> >If it is not, is it a method to calculate expected backup size ?
>
> Other than testing typical databases that have been working under

conditions that are typical for your user applications, no. The
file size of a database is almost always larger than the total size
of the active data, because there will be pages that contain
garbage. Sometimes a database could be two or three times larger
than the active data, when housekeeping is neglected for long
periods.

>
> Backups don't back up garbage, so a freshly restored database is

the best indicator of the actual size of the database. You could do
some statistics comparing the backup file size with the size of the
database restored from it, to get a rough ratio.

>
> >Or can I delete small chunks safely in my first method (I mean

this and future versions) ?

>
> You must not delete ANY chunks in the sequence. A restore from a

multi-file backup must be able to find all of the files that were
specified in the backup call: each of those "empty" files contains
the link to the next file.

>
> For your testing, I recommend you use gbak and file-copies of real

databases taken from production conditions. But for your IBX
testing, get hold of the most recent version of the service
components and test the theory that the TIBBackupService component
is wrapping a "fallback" for situations where the primary file was
specified alone with a file size.

>
> ./heLen
>