Adam,

Adam wrote:

>
>
> Chris,
>
> Let me simplify the answer.
>
> A firebird database is usually a single fdb file (but can be multiple
> files or have other extensions, for simplicity I will talk about the
> database as being a single fdb file, but the same applies even if it
> is not).
>
> When you ask whether the database is portable, pretty much everyone is
> going to assume you want to know if you can copy that fdb file from
> one computer to another computer. As I answered in my original
> response, if you are copying it to a machine with the same endianness
> (eg Intel -> AMD) and both machines are 32 bit or both machines are 64
> bit, then yes. Otherwise, no - you will need to make a transportable
> backup which will restore natively on the target machine.

I have already got this. No problem.

>
> I know Ann has on the architect list proposed a method "to allow two
> systems that share alignment rules and datatypes to access the same
> database, even if the systems have different endian rules".
>
> > I was aware of Firebird's ability to have the database copied from a
> > local machine, where it was being used solely by one person, to another
> > location to be 'shared' by a server. I just wondered how far it went.
>
> Let me clear this up.
>
> You should *never* take a file system copy of a database while the
> 'server' is running. Running means different things to different
> models. In some models, even if there are no users connected, the
> engine could be finishing up some garbage collection.
>
> Copying a database while it is 'in use' can cause:

You appear to have missed the part where I said that I would not copy
mysql databases while the server is running. You really think I would
have happily made corrupt copies of tables holding hundreds of thousands
of rows of user account and mailbox information and put them into
production huh?

>
> * Inconsistent data in target.
> (just look at careful writes, there is no way your FS is doing that -
> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert3
> <http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert3> )
> * Server crash
> * Reportedly can corrupt source
>
> The GBAK tool and services API both provide methods of backing up a
> database while the server is running. There are also third party
> options like DBAK (not sure about whether there is a Linux port though).
>
> There is a new NBACKUP tool that makes the appropriate changes to
> allow a file system copy.
>
> There are massive performance benefits to a freshly restored database
> over one simply file copied. Nice balanced indices and no garbage.

Hello, we are talking about the Linux side of things. I suppose you want
to contradict Nando's point about the security2.fdb user database
presence before a backup or restore is possible. Anyway, I have what I
need. On Linux, security2.fdb has to be copied since I have been
informed of no other option on this list and it is the same method Milan
used anyway. I just make use to bundle a security2.fdb file created on a
32-bit system with 32-bit binaries and the likewise for 64-bit binaries.

regards,

Christopher