Subject | Re: [firebird-support] gbak Huge problem |
---|---|
Author | Helen Borrie |
Post date | 2004-07-17T00:09:53Z |
Comments inline:
At 02:39 PM 16/07/2004 +0000, you wrote:
./gbak -b /opt/firebird/data/mydatabase.gdb /opt/whatever/mydatabase.bak
./gbak -C /opt/whatever/mydatabase.bak /opt/whatever/tempdatabase.fdb
misunderstanding. For example, is the daemon logged in as SYSDBA or the
database owner?
-- sysdba, the owner or root can do backups
-- only one of these users can restore with the -replace_database option
and then that user becomes the owner of the database. The user that is
looking at the recreated database won't be able to see anything that it has
no privileges for.
restore. Fine (recommended, in fact!!) to have the daemon restore the
backup for a human being to check over tomorrow, but use -create_database
to restore into a temporary file.
Don't plan to use restores as a way to do daily housekeeping - have your
daemon perform a daily sweep if your objective is daily cleanup.
script of the database definition and stores the data separately in a
compressed format (not in tables!!). It doesn't validate the data it stores.
Restore rebuilds the entire database from scratch. The replace_database
option overwrites the existing database with a completely new database and
then attempts to write the data into their right places. If there were any
inconsistencies in the data, the operation will abort and you will end up
with no database; or just the metadata; or any of the varieties you
described above.
/heLen
At 02:39 PM 16/07/2004 +0000, you wrote:
>Hi.This isn't correct syntax for a backup. It should be:
>i have three diferent firebird 1.5 servers. I have a nightly bash
>script in every server that performs a database backup and restore.
>Cron execute the script the first time and all was fine, but the
>second time, i was unable to restore the resultant backup files
>generated by gbak.
>My script looks like:
>
>gbak /opt/firebird/data/mydatabase.gdb mydatabase.bak
./gbak -b /opt/firebird/data/mydatabase.gdb /opt/whatever/mydatabase.bak
>gbak -R mydatabase.bak /opt/firebird/data/mydatabase.gdbNEVER try to use the -R[EPLACE_DATABASE] option. Use
./gbak -C /opt/whatever/mydatabase.bak /opt/whatever/tempdatabase.fdb
>Could be caused by any one of a number of problems and
>For the first database, i can restore only metadata, not data.
>For the second database, the previous day data is missing.
>For the thirth database, stored procedures and triggers are missing.
misunderstanding. For example, is the daemon logged in as SYSDBA or the
database owner?
-- sysdba, the owner or root can do backups
-- only one of these users can restore with the -replace_database option
and then that user becomes the owner of the database. The user that is
looking at the recreated database won't be able to see anything that it has
no privileges for.
>Strong advice: never-never-never use a daemon to do a replace_database
>it looks like a joke, but it isn't. This caused me a lot of
>problems.
restore. Fine (recommended, in fact!!) to have the daemon restore the
backup for a human being to check over tomorrow, but use -create_database
to restore into a temporary file.
Don't plan to use restores as a way to do daily housekeeping - have your
daemon perform a daily sweep if your objective is daily cleanup.
> it looks like a joke, but it isn't. This caused me a lot ofgbak isn't a file-copying program. The -backup switch creates a complete
> problems.
> Please somebody can explain it?
script of the database definition and stores the data separately in a
compressed format (not in tables!!). It doesn't validate the data it stores.
Restore rebuilds the entire database from scratch. The replace_database
option overwrites the existing database with a completely new database and
then attempts to write the data into their right places. If there were any
inconsistencies in the data, the operation will abort and you will end up
with no database; or just the metadata; or any of the varieties you
described above.
/heLen