We're seeing huge backup files in the field, .FBK files larger than the source database by a considerable amount (21gig DB, 32gig backup).

I tested on 2.1.3.18185, 32-bit classic server, Windows Vista (64-bit). The customer is running XP Pro SP3 so I doubt the OS version is relevant.

The source database is 21,219,568KB

backup the FDB file:

params: -se service_mgr -v -nt - results in 13,257,345KB file, took approximately 31 minutes. Likely what one would expect.
params: -v -nt - Results in 32,220,963KB file, approximately 39 minutes

When I compare the log files from the backups, the only reported difference is the number of bytes written (and the file-name for the .FBK, of course expected):
***** backup.log
gbak:writing SQL roles
gbak:closing file, committing, and finishing. 13575521280 bytes written
***** BACKUP_NO_SVC_MGR.LOG
gbak:writing SQL roles
gbak:closing file, committing, and finishing. 32994266112 bytes written
*****

Doing the same two tests in transportable format result in an even smaller FBK file (11,205,556KB) taking roughly the same amount of time. The resulting FBK files are the same (except for timestamps and the like), so whether using "-se service_mgr" or not doesn't appear to matter when in transportable format.

This appears to be some sort of obscure bug. I tried the exact same backups on a 6gig database with the same structure as the 21gig db and the results of that were normal (FBK's all being smaller than the FDB).

I attempted to search for this problem in the issue tracker, with no luck.

Anyone ever heard of this? Should I repost to the Devel list or perhaps just enter a new issue in the tracker?



**********************************
**** more detailed/extra information ****
**********************************
DB stats:
Database "D:\temp\i21426\SW.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 326
Page size 16384
ODS version 11.1
Oldest transaction 310
Oldest active 311
Oldest snapshot 311
Next transaction 312
Bumped transaction 1
Sequence number 0
Next attachment ID 7
Implementation ID 16
Shadow count 0
Page buffers 250
Next header page 0
Database dialect 1
Creation date Sep 24, 2010 10:23:14
Attributes force write

Variable header data:
Sweep interval: 0
*END*



When I restore the test .FBK's, the 13gig fbk takes 1.5 hours. The 33gig fbk takes 3 hours, and the 11gig fbk takes about 1.25. Likely expected due to the file size. I did a complete table data comparison of the restored databases and there are no differences.

I also tried the tests (all variations of -nt and -se service_mgr) on a smaller database (5gig) and had more expected result, with the non-transportable .FBK files being somewhat smaller in size. The opposite of what I'm seeing with the large database.

If I restore a transportable fbk file (being the smallest, figure it might be cleaner) and then backup the resulting database with -v -nt the fbk file is 32gig, which is roughly 10GB larger than the source database.

-----
Brenden Walker
DRB Systems, Inc.




[Non-text portions of this message have been removed]