At 11:21 PM 7/11/2007, you wrote:

>If it's not a very bright idea to restore over a database that isn't
>running, why is it then a possibility? Is there some "hidden" clever
>reason for this?

No, it's that it is a wise precaution, on databases you care about, to test a restored database before you blow away the existing one. As Stefan mentioned, it's "probably OK' on a development database (though it wouldn't be, for me, since I have all sorts of things set up in those dbs that I DO care about!)

>What is considered good practice when backing up a database?

See Set's notes.

>All I need is to move the data offsite each night using rsync, and optionally
>having the database "vacuumed" once a week to keep the size under control.

You can do that just fine without having to restore the database AT ALL. Don't use rsync to move a database; run gbak -b, which will both create your backup AND do what you call "vacuuming" in the live database; then you can rsync the backup file and restore it elsewhere to check its integrity if you want to. gbak is a "hot" backup, i.e. you can run it while users are working. If there is a lot of garbage, some users might observe a slight slowdown, that's all.

>It's pretty difficult for me to shut down the database as it is being
>used 24/7, so I guess the whole "vacuum" thing is going to be pretty
>hard to accomplish?

Not in Firebird. Forget about "vacuum". If the applications are well-behaved, your weekly backup will be enough to keep everything ship-shape. Some systems *are* written badly and there is actually a thing a bit like "vacuum" that you can do, called "sweep". You can do it manually, when needed, or you can set it up to run automatically under a certain set of conditions. But if you're running gbak regularly, it's unlikely you'll need to think about sweeping much.

>I'm running Firebird Classic 2.0.3 on Linux.

On Classic, where you have only one style of garbage collection (cooperative) there *will* be times when one user will notice a "hit" from cleaning up another's garbage, e.g. when s/he is the unlucky one who is next to access a table after the other user has done a mass delete on it. (SS has to get rid of garbage too, but it has more ways to do it and, with the background option, will do it in idle time if it can.)

./hb

>Sincerely,
>Thomas
>
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Visit http://www.firebirdsql.org and click the Resources item
>on the main (top) menu. Try Knowledgebase and FAQ links !
>
>Also search the knowledgebases at http://www.ibphoenix.com
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Yahoo! Groups Links
>
>
>