On Fri, 7 May 2004 21:34:55 +0000 (UTC), Leyne, Sean <sleyne@...>
wrote:

>
>> There certainly are larger ones. A few years back one poster had a 200GB
>> IB database, and an almost-1GB database (IB) has been mentioned.
>
> That should read almost *1TB* database -- the size quoted was 980GB.

Thanks - I goofed, close to _1TB_ is correct!

> Further, Nickolay Samofatov (here in my office) has experience with
> numerous database of 9-20GB and has seen test cases of databases as
> large as 100GB.
>
>
>> It should be quite easy now (that Fb is faster, gbak is faster and
>> hardware is faster) to have pretty large databases running.
>
> Unfortunately, GBAK is not practical for large databases (the actual
> size will vary according to mileage). The backup is not so much the
> problem, although that can be a problem, it is the speed/approach of the
> restore. A restore which takes 24+ hours to perform has limited value
> for most businesses when they experience problems.
> These speed issues were the reason why I/BroadView Software commissioned
> the new NBackup function. It performs backups at database page level,
> not data level. Thus, you can perform backups/restores at near hardware
> speeds as well as perform incremental backups.
> This new function is available today in the HEAD branch (i.e. non
> v1.5.x) of the Firebird code

For Very Large Databases a restore should only be a 'last resort' maneuver.
UPS, RAID and replication should keep the 'fetch the backup tape' at some
distance.


--
Aage J.