frecover database checkpoints

[Michael Osterhouse]

We are deveoping a remote disaster recovery site. When required, we would will make tape copies of critical files and move to the remote location, load them on a computer and be back online. We have tested our system and it works fine except that the Ingres database returns a checksum error when we try to load the checkpoints. Everything else off the tape loads fine, and there is no errors returned by fbackup/frecover. I suspect I am dealing with "sparce files" and have read many of the posts about them. I use DDS3 tapes using BEST compression. I have tried to reload the database with and without the -s option; doesn't seem to make a difference. Does the compression level affect how sparse files are loaded/unloaded from tape (other then time and space)? Although we don't have the bandwidth at this time, is ignite able to copy sparse files? This might be an option in the future.
Thanks.

[Massimo Bianchi]

Hi,
sparse file or not it not the issue. sparse is only a os way to reduce disk usage, but the application thinks that all space is allocated.

Is ingres backed-up online of offline ? this is the real question.

I think that you backup the ingres online.

This error is common to oracle, when backed up online without the proper care.

Massimo

[Steven E. Protter]

I think your backup needs to be cold. Then an OS based fbackup will work. fbackup can't back up any rdbms when its hot, it gets a fuzzy, nearly useless copy of everything.

SEP

[Chris Wilshaw]

Are you using the same kind of tape drives on both machines, and are they at the same patch level? Both of these could potentially produce problems.

As far as the checkpoint itself is concerned, as long as the checkpoint it definitely complete before the backup starts, the files will be OK, as from that point on, they are not directly accessed by the system.

Another possibility is that your Ingres system is not configured to restore the checkpoint properly.

On our systems, when we checkpoint the databases, we also compress the files (but do not give them a .Z or .gz suffix). It could be that you restore is getting the files back OK, but the database is unable to reload them due to them being an unrecognised format.