Hi

I had run into similar problems, once my production database was lost.
Inconsitencies in the data prevented gbak from restoring it. I could however
restore it with IB7s gbak with some command line switches, I don't remember
right now.
As a temporary solution, I expanded my backup script to do a gbak-backup AND
an file-copy kind of backup.

I now want to clearify these things.
What is the suppost way to do it?

gbak -b ....
gbak -r ...(sth with date in name)...

After both calls, I would like to check ERRORLEVEL result values.
Usually 0 means "everything fine". And values != 0 mean "some errors".
Is this the case for gbak? Can I RELY on that behavior?
I mean, am I totally save to only have the fbk, if my fdb is lost, but gbak
returned 0 both times?

Regards,
Steffen



-----Ursprüngliche Nachricht-----
Von: Helen Borrie [mailto:helebor@...]
Gesendet: Samstag, 17. Juli 2004 02:10
An: firebird-support@yahoogroups.com
Betreff: Re: [firebird-support] gbak Huge problem

Comments inline:

At 02:39 PM 16/07/2004 +0000, you wrote:

>Hi.
>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

This isn't correct syntax for a backup. It should be:

./gbak -b /opt/firebird/data/mydatabase.gdb /opt/whatever/mydatabase.bak

>gbak -R mydatabase.bak /opt/firebird/data/mydatabase.gdb

NEVER try to use the -R[EPLACE_DATABASE] option. Use

./gbak -C /opt/whatever/mydatabase.bak /opt/whatever/tempdatabase.fdb

>
>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.

Could be caused by any one of a number of problems and 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.

>
>it looks like a joke, but it isn't. This caused me a lot of problems.

Strong advice: never-never-never use a daemon to do a replace_database
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 of > problems.

> Please somebody can explain it?

gbak isn't a file-copying program. The -backup switch creates a complete
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



------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/67folB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links