Hi Michael,

mivi71dk wrote:

> So in short:
>
> 1.
> Schedule a GBak operation at let say 00.00 instead of the file
> system backup. This an be run while users are attached and working
> on the DB ?
> How does that ensure that the data is valid ?

gbak is a client to your database almost like any "normal" client.
when gbak starts, it opens a transaction, and from that point on the database is
"frozen" to the state the transaction started. even if your backup takes hours,
it will still be an exact snapshot of the db at the time it started (Firebird's
multi-generation architecture makes that possible). when people change data
while gbak runs, that's no problem - different transactions. it's just that the
data they changed while gbak runs won't be in the backup.

Someone already suggested GBAKSched - we also use this and it behaves very
nicely. it launches gbak, can zip your backup file, copy the zip to two
different locations and even email you a log file for each run.

runs as a service, set it up and forget it. ours is doing 3 backups a day,
sometimes while 20 or 30 users are hacking on the database (we live in 24x7
industry), and we never ever had a single problem with gbak for 2 1/2 years now.
i do think you can trust gbak!

to detect a broken backup, we always have two databases: the "real life" one and
what we call the "playground db". people who are not yet comfy with our app
can try things out in the "playground", and they know the next day all they
tried will have gone. a separate task runs a restore in the night after the
backup and restores to the "playground" db, so if something should go wrong, all
you have to deal with is a broken playground, but never the real system.

hth + regards,
fingerman
--
-------------------------------------------------------------------------
when parsers parse, and compilers compile, then why don't objects object?

fingerbirdy - fingerman's door to Firebird
http://www.fingerbird.de