> Thank you for the response, and please accept my apologies for the
> skimpy information. However I have inherited the systems and am trying
> to figure out what happens when one system is copied on top of another
> with the Linux rsync. FirebirdSS-1.5 is running on both systems when I
> do a "ps -A | grep fbserver", but only one server is online; the other
> is suppose to be a backup server in case the primary server fails.

If you are lucky, the source database is not in use at the time rsync
runs. By lucky, I mean that no connections or transactions are started
or ended and the garbage collection is not running (ie, the database
engine is doing nothing to the file for the entire time the file is
being copied). For a tiny database of a few MB (and a fast rsync
link), you may get away with it, but much larger and the database file
could be modified while the copy is taking place.

The more normal case would be that something happens during the copy.
For example, someone starts a new transaction. In this case, the TIP
in your destination database file won't be aware of this transaction,
however by the time rsync reads the data page, it copies some data
from that transaction. It doesn't take too much imagination to realise
that this is not a good thing at all.

Another example, you copy an index page before a data page of the
given table. Between reading the index page and reading the data page,
someone inserts a new record, but the index will not contain this
record. You may then find yourself violating unique constraints left
right and centre (because Firebird just looks into the index to
determine whether a value exists rather than the slow operation of
reading the entire table). Worse still, a backup will not restore
easily if it contains a table that contains duplicates in a unique
constrained field!

Worse still, and although I can not understand how it is possible,
there have been reports about the source database being corrupted by
copying it using a file system level copy utility.

In case you haven't guessed what I am hinting at yet, DO NOT RSYNC /
XCOPY / FTP / ZIP / or whatever a database file that is in use.

There are two things you may wish to consider to solve your problem.
If you are after a complete replication, then various replications
tools are available that work with Firebird. If you are simply after
are usable backup copy on a different server, then you can use the
gbak tool that ships with Firebird to safely generate a backup file.

One side note, if you are using Firebird 2, there is a new backup
utility (NBackup) which does give the option of doing file system
level things to the database while it is active. You need to first put
the database into a special mode where it maintains a sort of change
log but keeps the database file itself stable. After you have finished
with rsync, you need to use the utility to tell the firebird your
backup is finished and it will merge the changelog into the main
database file. Firebird 2 is not production stable, it is release
candidate level, so specific questions regarding it are off topic in
this list (until it becomes classified as stable), so you will need to
google for the appropriate documents for this feature if interested.

Adam