--- In ib-support@yahoogroups.com, Paul Schmidt <pschmidt@i...> wrote:

> Mathematical limits, are limits like how many rows can a table have,

how many

> pages, etc. These are largely theoretical in nature, but are

unlikely to be

> tested because the other limits are much lower.

Agreed. But the other limits change much faster.
Have you ever experienced one of those famous BIOS-limits for
... 512 MB-Disks, 2GB-Disks, 32 GB-Disks, 128 GB-Disk ?

> 32TB seems to be reasonable
> these days.

These days indeed only few organizations are able to afford such
amounts of disk space. But considering how fast disk space grow and
how cheap it got over the last few years, i am curious how long "these
days" will last.
In another post I already mentioned that my first harddisk has had
only 1/1000th, no correction: 1/10000th of the capacity of a nowadays
cheap&dirty harddisk. And it was _much_ more expensive !

> Then there are practical limits, like how long does it take for Gbak to
> backup a certain sized database, for example if it takes 8 hours per

TB, then

> a 32TB backup would be almost 11 days (ouch), if it's a really

important

> database then 11 days to backup would not be reasonable, and the

down-time

> for a restore would not be reasonable either. In this case 1-3 TB

would be a

> more reasonable limit.

Restricting yourself on gbak, you are perfectly right.
But I would like to stress the fact that gbak really isn't the final
wisdom !
Indeed, with really existing firebird-databases having a size of 980
GB around, probably "someone" (who is someone?) should simply start to
think about more clever methods to backup huge databases:
1.) Obvious solution: Incremental backups come to my mind.
Why should I have to backup every time a 980 GB database if only about
for example 10 % of it (or even less) has changed ?
2.) The backup-process could probably record the changes done to the
database whilst it was backed-up as well. This would for example mean
that after completion of an 8 hours backup-run, you have a backup of
the actual state of the database, not an already 8-hours old one.

> Now the real issue, technical and practical limits apply for all of the
> engines, not just Firebird.

Well, obviously SAP DB already provides some kind of backup-able
changelog which makes at least backups of huge databases considerable
more practical.
Indeed, because of this, it got an especially honorable mention in the
comparision of open-source databases which I mentioned in my first
post. May I quote ?
"Beim Thema Datensicherheit glänzt die SAP DB, die als einziger
Kandidat in diesem Testfeld Möglichkeiten zum Online-Backup mitbringt."
Freely translated as:
"Concerning data security, SAP DB shines because it is the only
candidate in this test which provides possibilities for Online-Backup."
I am especially unhappy about this very misleading term
"Online-Backup". It sounds like other databases (postgresql, firebird)
may not be backed-up whilst they are online.
You and me know that this isn't true ... but some uninformed reader
might get a completely wrong impression.

Anyway, the SAP DB changelog shows successfully that you should not
easily take for given these practical limitations which are arising
from the use of gbak.

Kind regards
Frank Emser