Subject | Re: URGEND - Cannot restore with GBAK |
---|---|
Author | Alexander V.Nevsky |
Post date | 2004-03-24T09:48:28Z |
--- In firebird-support@yahoogroups.com, "Steffen Heil" <lists@s...>
wrote:
disadvantage. AFAIK -n gbak option in FB affects only CHECK
constraints defined on explicitly created domains, as it was in IB6. I
several times attempted to attract attention of developers to this
problem but was unsuccessfull. Seems this is routine, not interesting
work. If so, IMO Firebird Foundation, using our (not large) fund,
should establish special grant on this task. Unfortunately just now
Foundation is paralysed by technical problems with mail server and
voting machine, but I'll insist on it as soon as situation will be
normalized. We MUST have certainty that using special options we can
retrieve data from gbk if it was created in case of any damage of the
source database.
metadata only on FB and pump data from IB7 database to get FB1.5 one.
BTW, during this process you most probably will got exceptions on
problem records and localize and repair them.
this is acceptable, you are right.
control restore into another file just after you made backup. This is
good diagnostic procedure not for gbk only but for source database
too, some kind of corruptions can be detected on restore only, as you
certain of now. My personal practice is - nightly cron make backup,
transfer it onto another computer and restore. If all is successful,
I'm have copy and know that source database have no problems. If
restore fails, I localize problem in source database while it is minor
problem, not a catastrophe. BTW, IB7 gbak by devault uses -no_validity
and IMO this is trap for newbies, default mode should be most paranoic.
Best regards,
Alexander.
wrote:
> What I have done now is I have downloaded Interbase 7.1 trial andused its
> gbak with my firebird server. -n works in that release, it restoresthe full
> database.conditions or
> [As far as I can tell, every row is restored and only violated
> "not null"s are removed. Can someone comment on this?]skip
> The "man page" (-help) of my firebirds gbak tells me that "-n" would
> validation. Is -n somehow buggy on firebird?Steffen, IMO lack of such a flexibility of gbak is largest FB's
>
disadvantage. AFAIK -n gbak option in FB affects only CHECK
constraints defined on explicitly created domains, as it was in IB6. I
several times attempted to attract attention of developers to this
problem but was unsuccessfull. Seems this is routine, not interesting
work. If so, IMO Firebird Foundation, using our (not large) fund,
should establish special grant on this task. Unfortunately just now
Foundation is paralysed by technical problems with mail server and
voting machine, but I'll insist on it as soon as situation will be
normalized. We MUST have certainty that using special options we can
retrieve data from gbk if it was created in case of any damage of the
source database.
> The tip to use IB7.1 gbak was from google, and I was lucky, that thegbk was
> in 1.0.3 format. From what i know from this list, gbak 1.5 gbk-files areAFAIK they are really incompatible. I think you should restore
> incompatible to IB7.x. Can someone comment on this?
metadata only on FB and pump data from IB7 database to get FB1.5 one.
BTW, during this process you most probably will got exceptions on
problem records and localize and repair them.
> I seem to have gotten away this time having only a bloody nose. But I ambackups
> afraid such problems could occur again. Till now I thought recent
> were some kind of safety, but beginning today I start [additionally]copying
> fdb files.You can safely copy fdb files only when FB server is stoped. If
this is acceptable, you are right.
> What is the safe way to backup firebird databases ?Common practice of persons who had one time bloody nose is - make
control restore into another file just after you made backup. This is
good diagnostic procedure not for gbk only but for source database
too, some kind of corruptions can be detected on restore only, as you
certain of now. My personal practice is - nightly cron make backup,
transfer it onto another computer and restore. If all is successful,
I'm have copy and know that source database have no problems. If
restore fails, I localize problem in source database while it is minor
problem, not a catastrophe. BTW, IB7 gbak by devault uses -no_validity
and IMO this is trap for newbies, default mode should be most paranoic.
Best regards,
Alexander.