IDS Forum

Re: External Restoration

Posted By: Martin Fuerderer
Date: Friday, 6 February 2009, at 4:38 a.m.

In Response To: Re: External Restoration (VIKAS HIVARKAR)

Hi,

it only checks the value of the ROOTPATH parameter,
i.e. the chunk path name.
After all, this is a restore, and you can do it with the files
still having a size of 0 (zero) bytes. The file (or raw device)
has to exist, but it doesn't matter really, what is there.

Especially, the restore on one (target) host (UNIX machine) of a backup
taken from a different (source) host would never attempt to access
any chunk on the source host, not even for any checking.

[ There is a check of disk content for the purpose of log salvage.
This gives the admin the chance to salvage any logical log files
(not yet backed up) that may still be lingering on the disk ... before
starting the actual restore (which overwrites such lingering log files).
And it also does not depend solely on the ROOTPATH
parameter (to search for and find lingering logical logs).
Also the "oncfg..." file in $INFORMIXDIR/etc/... is used for this
purpose.

But this is never done on a different machine/instance. It is
done only locally. Because the impending overwrite (by the
restore) is only locally, so a possible log salvage is needed
only locally.
]

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

IBM Deutschland Research & Development GmbH
Chairman of the Supervisory Board: Martin Jetter
Board of Management: Erich Baier
Corporate Seat: Boeblingen, Germany
Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294

ids-bounces@iiug.org wrote on 06.02.2009 10:03:13:

> Hello,
>
> Thanks to all as Restoration with rename went smoothly when I pointed
the
> ROOTPATH to root chunk of original instance, in my case
/dbs/lt1/rootdbs.
>
> But there is some doubt and please some one could clear it?
>
> I used a level 0 backup from UAT instance (on different HOST) which have
all
> the chunk paths exactly same as the chunk paths of LT1 instance on
> TEST server
> (I created the new instance on TEST server).
>
> ROOTPATH /dbs/lt1/rootdbs for LT1 instance on TEST server.
>
> ROOTPATH /dbs/lt1/rootdbs for UAT instance, whose level 0 backup I used
for
> restoration.
>
> ROOTPATH /dbs/lt1/rootdbs set on NEW instance (before starting its
> restoration) was same as ROOTHPATH in onconfig on UAT instance and
> also on the
> LT1 instance.
>
> But my entry in onconfig for NEW instance was:
> ROOTPATH /dbs/lt1/rootdbs
> AND NOT
> ROOTPATH HOST:/dbs/lt1/rootdbs
>
> AT the time of Restoration the ROOTPATH actually pointed to the
rootchunk of
> LT1 instance on same server.
>
> So what does IDS check? Only the ROOTPATH ?entry?, which should be same
as
> onconfig from where the level 0 backup was taken OR does it check
> the contents
> of rootdbs.
> In my restoration it could never read the original rootdbs chunk on UAT
> instance (as it was on another HOST machine and I did NOT mention HOST:
$PATH
> in onconfig on NEW instance).
>
> Thanks,
> Vikas.
>
>
------------------------------------------------------------------------------
> Hi,
>
> no.
>
> There is a general requirement that the ONCONFIG file configuration
> for the restore be the same as it was at backup time. (Some
> onconfig parameters are not checked strictly, but others are.)
> For that reason (among other parameters) the ROOTPATH
> has to be the same as during the backup. In your case that means
> it has to point to the chunk of the source IDS instance.
>
> [ For your "cloning" scenario, some other parameters in the
>
> ONCONFIG for the restore need to be explicitly different,
>
> e.g. SERVERNAME. ]
>
> TO AVOID OVERWRITING the source IDS instance, you have to
> use the RENAME functionality during the restore. And here you
> have to specify a RENAMING FOR ALL CHUNKS, including the
> chunks of the root dbspace. The restore itself will then change
> the ONCONFIG file (of the restored instance) to reflect the new
> ROOTPATH correctly as specified in the renaming.
> And of course the restore will use these new locations for
> the restoring of data to the disks, thus not overwriting anything
> from the source instance.
>
> Regards,
> Martin
> --
> Martin Fuerderer
> IBM Informix Development Munich, Germany
> Information Management
>
> IBM Deutschland Research & Development GmbH
> Chairman of the Supervisory Board: Martin Jetter
> Board of Management: Erich Baier
> Corporate Seat: Boeblingen, Germany
> Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294
>
> ids-bounces@iiug.org wrote on 04.02.2009 09:50:00:
>
> > Kenneth, Art. Thanks for the help !
> >
> > one query:
> >
> > --- In the ONCONFIG of the target ensure that the rootdbs is pointing
to
> the
> > root chunk of the source (otherwise restore fails)----
> >
> > Does it mean, we would be restoring the level 0 backup of one instance

> to
> > itself but at new place?
> >
> > Regards,
> > Vikas.
> >
> >
>
------------------------------------------------------------------------------
> >
> > You can indeed use a backup and restore. IDS 11.10 and later allow you

> to
> > rename the chunks at restore time. Just make sure that either the
> original
> > server is offline, or that the new server has a different SERVERNUM
and
> > SERVERNAME in its ONCONFIG file than the existing one.
> >
> > Art
> >
> >
>
------------------------------------------------------------------------------
> > Vikas,
> >
> > You need to perform an ontape backup with chunk rename. I am
> > assuming that you have correctly setup the onconfig of the
destination.
> > Here ensure that the servernum of the source and destination are
> > different. Create a text file with the following structure, called
> > dest_rename.
> > <chunk name in source> <chunk offset> <chunk name in destination>
<chunk
>
> > offset in destination>
> >
> > Ensure that you include all the chunks here as otherwise you might end

> > up overwriting the live db.
> >
> > On both the source database and destination set the tape dev to STDIO.

> > In the ONCONFIG of the target ensure that the rootdbs is pointing to
the
>
> > root chunk of the source (otherwise restore fails)
> > Assuming you have an env file for the source Informix instance called
> > src.env and one for the destination Informix instance called dest.env.

> > If the destination chunks are files, pre-create them by just touching
> > them and set the appropriate permissions, chmod 0660 informix:Informix

> > <files>
> >
> > Run
> > $ . src.env
> > $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to the

> > file created with the rename details as indicated above>)
> >
> > After it finishes the destination will be in quiescent mode.
> >
> > BTW, you can use ontape instead of STDIO, but STDIO is faster ;)
> > You can monitor the progress of the backup using onstat -g arc on the
> > source and the progress of the restore using onstat -D on the
> > destination.
> >
> > Regards,
> > Kenneth Penza
> > Systems Engineer| SMD
> > MALTA INFORMATION TECHNOLOGY AGENCY
> > * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 :
> > http://www.mita.gov.mt
> > * Please read our Legal Notice: http://emailpolicy.mita.gov.mt
> > P Please consider your environmental responsibility before printing
this
>
> > e-mail
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > VIKAS HIVARKAR
> > Sent: 03 February 2009 16:58
> > To: ids@iiug.org
> > Subject: External Restoration [14708]
> >
> > Hello,
> >
> > IDS 11.10 FC3 on solaris 10.
> >
> > Problem: I have instance lt1 on my test server having 25 medium size
> > databases
> > (level 0 backup size of about 400 GB using ontape), now I want all
these
>
> >
> > databases on the same server in another instance. Currenly the chunks
of
>
> > lt1
> > are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on
same
> > server.
> >
> > I simply cannot build another instance and restore the level 0 as the
> > chunk
> > paths won't be the same and restoration will abort giving me an error.

> >
> > What options do I have, OTHER than Export / Import OR HPL OR
Archecker?
> >
> > Would External Backup and Restore help me in this case? I see the
> > documents
> > say that Cold Restoration would allow me to change the chunk path.
> >
> > Old path of chunks /dbs/lt1/.....
> > New path of chunks /ids/lt2/.....
> >
> > Can this help me with my requirement? If yes then
> >
> > I need help with the restoration process as, what should be the path
of
> > root
> > dbspaces for the new instance when I want to initialize it for the
first
>
> > time
> > so that I have a instance which I can now take down and start the
> > External
> > Restoration with the copied chunks from old instance.
> > Or do i have so simple create a new instance with the chunks in new
path
>
> > ( in
> > this case do i have to build all the chunks as that of old instance or

> > only
> > rootdbs ).
> >
> > Else any suggestions of doing this in a better way will help me!
> >
> > Regards,
> > Vikas
> >
> >
> >
>
>
*******************************************************************************
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>

Messages In This Thread

• External Restoration
  VIKAS HIVARKAR -- Tuesday, 3 February 2009, at 10:58 a.m.
  • RE: External Restoration
    Penza Kenneth at MITA -- Tuesday, 3 February 2009, at 11:16 a.m.
  • Re: External Restoration
    Art Kagel -- Tuesday, 3 February 2009, at 11:31 a.m.
    • Re: External Restoration
      VIKAS HIVARKAR -- Wednesday, 4 February 2009, at 3:49 a.m.
      • RE: External Restoration
        Penza Kenneth at MITA -- Wednesday, 4 February 2009, at 5:31 a.m.
      • Re: External Restoration
        Art Kagel -- Wednesday, 4 February 2009, at 6:50 a.m.
        • Re: External Restoration
          Peter_Logan@spartanstores.com -- Wednesday, 4 February 2009, at 8:25 a.m.
          • RE: External Restoration
            Penza Kenneth at MITA -- Thursday, 5 February 2009, at 5:06 a.m.
      • Re: External Restoration
        Martin Fuerderer -- Wednesday, 4 February 2009, at 12:17 p.m.
        • Re: External Restoration
          VIKAS HIVARKAR -- Friday, 6 February 2009, at 4:03 a.m.
          • Re: External Restoration
            Martin Fuerderer -- Friday, 6 February 2009, at 4:38 a.m.
            • Re: External Restoration
              VIKAS HIVARKAR -- Friday, 6 February 2009, at 5:02 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.