Recover Database

[Rich Ford]

Is it possible to save a checkpoint file in a backup directory then destroy
the database, create the database and then use this checkpoint file to recover the database the state prior to the destroy?

Rich

[Martin Bowes]

Hi Rich,

Short answer: Don't.

This is not the right way to do it as there are huge problems in getting the database to believe the checkpoint file is cool. You could end up with a very scrambled database configuration file

This is not what a checkpoint file is for. A checkpoint file is created so that you can do time based recoveries using th edatabsse journals.

What you want is a static backup created with either unloaddb or copydb. Those are designed for exactly this sort of task.

Marty

_______________________________________________
Info-ingres mailing list
Info-...@lists.planetingres.org
https://lists.planetingres.org/mailman/listinfo/info-ingres

[Rich Ford]

Thanks for the quick reply.

Rich

[Karl Schendel]

> On Jan 25, 2022, at 9:01 AM, Rich Ford <richf...@gmail.com> wrote:
>
> Is it possible to save a checkpoint file in a backup directory then destroy
> the database, create the database and then use this checkpoint file to recover the database the state prior to the destroy?
>

Possible, yes. It's not the simplest thing in the world to get right,
and you can't just rollforwarddb the checkpoint. I don't advise it
unless there is no other way to recover, and then I'd want to get
Tech Support involved.

Karl

[Adrian Williamson]

Ah yes, the dreaded database identifier and binary editing of database
(CNF?) files....keep you all night long that will.

-----Original Message-----
From: info-ingr...@lists.planetingres.org
<info-ingr...@lists.planetingres.org> On Behalf Of Karl Schendel
Sent: 25 January 2022 14:50
To: Ingres and related product discussion forum
<info-...@lists.planetingres.org>
Subject: Re: [Info-ingres] Recover Database


> On Jan 25, 2022, at 9:01 AM, Rich Ford <richf...@gmail.com> wrote:
>

Possible, yes. It's not the simplest thing in the world to get right, and
you can't just rollforwarddb the checkpoint. I don't advise it unless there
is no other way to recover, and then I'd want to get Tech Support involved.

Karl

[Roy Hann]

Like everyone else has said, I would discourage that approach.
The preferred tool for that situation is unloaddb.

That said, your disaster recovery plan should include all the steps
required to do just what you suggest. In the event of a total loss of
the facility (fire, flood, carpet moths) you need to be able to
reinstate your database on a new machine using the checkpoint.

I get the impression you are new to the site. You should ask if
anyone else there knows where the disaster plan is.

If they don't, your next step is to become a hero by writing it.

Roy

[Allan Biggs]

Rich,

If you're on virtual machines backed up on an NFS and assuming the nfs hasn't suffered as Roy postulates. There are possible ways of rolling back the virtual machine itself and recovering from there.

Allan

--
Sent from my Android phone with mail.com Mail. Please excuse my brevity.

[Paul White]

This work ok for replication.

I drop a production database, which removes ckp jnl dmp tmp data. (Non x100 db).

Then:

Createdb

Ckpdb +j

Rsync from DR server:ckp dmp jnl

Copy aaaaaaaa.* from dmp to data

Infodb to make sure

Rollforwarddb to point in time

Ckpdb +j

No editing configs or iidbdb required.

Am i missing something?

[Roy Hann]

Wednesday, January 26, 2022, 2:00:06 AM, you wrote:

> This work ok for replication.

> I drop a production database, which removes ckp jnl dmp tmp data. (Non x100 db).

> Then:
> Createdb
> Ckpdb +j
> Rsync from DR server:ckp dmp jnl
> Copy aaaaaaaa.* from dmp to data
> Infodb to make sure
> Rollforwarddb to point in time
> Ckpdb +j

> No editing configs or iidbdb required.

> Am i missing something?

I would update iidatatabase.db_id in iidbdb to make it the database ID
of the old database. It's not a big deal but it means IPM will show
the correct database name.

And for DR purposes I'd make sure I was keeping all my Ingres user IDs
from iidbdb, and also my area and location definitions so they could
be recreated after the smoke clears.

Roy

> On Wed, 26 Jan 2022, 2:25 am Roy Hann,
> <spec...@processed.almost.meat> wrote: