--- In ib-support@y..., "Theo Bebekis" <teo@e...> wrote:

> Alexander
> > BTW, usage -r option on restore is the direct way to have at

hands

> > only broken database and unrestorable backup one fine day. Some

types

> > of logical corruptions are detected only on restore phase and

restore

> > process terminates.
>
> Do you mean by that that the -r option is
> dangerous?

Theo, yes, it is dangerous. Let's say gbk is unrestorable and you
don't know about it. Simply example - null in _not null_ column, we
can make this mistake ourselves changing metadata, sometimes such a
records appears when server crashed with unfinished garbage collection
process. Such a corruption is not checked on backup, it's too
expensive. You start restore overwriting original database, restore
fails uncompleted - you haven't database where you can to fix problem
and make restorable backup. So I intentionally recommend
1. Always restore with -c option and if successful - stop server
and replace database by file copy of fresh instance
2. To all who make sheduled automatic backups and have feeling they
are safe - include control restore of new gbk into another file into
sheduled maintenance process.

Best regards, Alexander V.Nevsky.