Informix

nested-group-icon.png

DB2

Expand all | Collapse all

Execution of Long Restores Remotely

  • 1.  Execution of Long Restores Remotely

    Posted Wed May 27, 2020 11:56 PM
    Hi,
    As part of a Disaster Recovery Exercise, need to restore large instances (about 80GBs) remotely.

    Now there are multiple issues here:
    1. The remote connection may time-out due to terminal session time limit,
    2. VPN time limit; or
    3. Some Internet issue.

    What are the best ways to run 'ontape -r' remotely?

    Environment: HP-UX 11.31 and Informix 11.5.


  • 2.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 12:16 AM
    Run the command in a screen ? 

    Paul Watson
    Oninit LLC
    +1-913-387-7529
    www.oninit.com
    Oninit®️ is a registered trademark of Oninit LLC





  • 3.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 02:20 AM
    Hi Paul,
    Could you please, elaborate what is meant by running the command in a screen?





  • 4.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 09:23 AM
    Screen is command line utilty 

    screen -S ontape  

    This is will give you a session that will not die if comms are lost, think of it as a nohup you can reconnect to 

    If you are worried about losing comms between two servers when copying the files then use rsync as it is resumable as are some ftp setups

    Just a FYI if you are using encrypt as a restore option then -d won't work with STDIO - a bug in some versions - 12.10.FC12 in my world 

    Cheers
    Paul



    Paul Watson
    Oninit LLC
    +1-913-387-7529
    www.oninit.com
    Oninit®️ is a registered trademark of Oninit LLC





  • 5.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 02:20 AM

    Hi

     

    Maybe split and compress the backup filec and scp it to the remote machine to limit the risk of losing everything if the network breaks.

     

    Then run ontape -in backgroup mode (nohup ontape -r <<!

    enter

    enter

    enter

    !

    & )

     

    from the remote machine. ( you may need to fine tune he command, I didn't test it

    At least the restore session won't have any timeout because it runs in background mode.

     

    The best way in your case would be to use RSS established permanently. It handles network faults and you will not be in an emergency

    To copy the file far away.

     

    And your have very old versions: you are out of support: not a good idea at all fr production system. You live very dangerously

     

    Regards

    Eric

     

     

    Eric Vercelletto
    Data Management Architect and Owner / Begooden IT Consulting
    Board of Directors, International Informix Users group
    IBM Champion 2013,2014,2015,2016,2017,2018,2019,2020
    ibm-champion-rgb-130px

    Tel:     +33(0) 298 51 3210
    Mob : +33(0)626 52 50 68
    skype: begooden-it
    Google Hangout: eric.vercelletto@begooden-it.com
    Email:
    eric.vercelletto@begooden-it.com
    www :
    http://www.vercelletto.com
    www  https://kandooerp.org

    image001.jpg@01CDC3E9.1425CBB0

    image002.jpg@01CDC3E9.1425CBB0

    image003.jpg@01CDC3E9.1425CBB0

     

     






  • 6.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 03:25 AM
    Hi Saradhi.

    Use "rsync --append" to transfer a level 0 "ontape" archive. If the connection fails, it will continue the transfer where it failed if restarted.

    Preferably set this in source and target $ONCONFIG files:

    BACKUP_FILTER gzip
    RESTORE_FILTER gunzip

    Use multi-threaded pigz if gzip us too slow.

    Alternatively, add "--compress" to the rsync command, or gzip the file before transfer.

    Once the file has been copied across, restore with:

    ontape -p -t STDIO < filename

    When running commands remotely, put in background with "nohup" or "at now" so that it continues if you lose connection.

    ------------------------------
    Doug Lawry
    Oninit Consulting
    ------------------------------



  • 7.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 04:18 AM
    Hello.
    If you don't have access to the source host console, I would suggest running via rsync with -z option (compress), and also using nohup in background. 

    I have made several large copies using this, on a 30M network link.
    Everything went fine here.

    HTH

    Alexandre Marini





  • 8.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 07:40 AM
    Hi Doug and Alexandre,
    Thank you.

    Level-0 backup, say databackup (about 80GB), is restored on to a file system on the DR server.

    Are you saying,

    $nohup ontape -p -t STDIO < databackup

    is the command to use, than

    $ontape -r [assuming TADEDEV=databackup]?


    When we run ontape -r commoand, it prompts some queries, how will be they be supplied?

    [I want to reclarify my question:

    Imagine, from my Windows Laptop I do a PUTTY session to my Unix Server.

    On that PUTTY terminal session, I run the restore command.

    Now the challenge is if the PUTTY sessions get a time-out, then the restore gets aborted.

    So, what is the best approach than $ontape -r via a PUTTY terminal session.]

    Thank you all.





  • 9.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 07:51 AM
    Either of:

    # Output saved in file "nohup.out"
    nohup ontape -p -t STDIO < databackup &

    # Output emailed:
    echo 'ontape -p -t STDIO < databackup' | at now

    On completion, just run "onmode -m" to bring on-line.

    It's simpler to use "ontape -p" (physical restore only) whereas "ontape -r" needs to know which logical logs to be applied afterwards which I assume you don't need.

    ------------------------------
    Doug Lawry
    Oninit Consulting
    ------------------------------



  • 10.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 08:01 AM
    Hi Doug,
    Thank you for the valuable advice.

    Yes, there is no need to apply logical logs.





  • 11.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 08:29 AM
    Set the Keepalive in you PuTTY session to 60 seconds that will prevent the inactivity timeout from killing the session!

    Also you can use the -d option to perform a non-interactive restore which will not prompt.

    Art 





  • 12.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 09:06 AM
    Thank you, Art.





  • 13.  RE: Execution of Long Restores Remotely

    Posted Thu May 28, 2020 09:38 AM
    Hi Saradhi,

    as someone stated above, either the "screen" or the "tmux" command (if available on your Unix system) could be your friend. Both programs will open a new shell from which u can detach (CTRL-A then D for screen, CTRL-B then D for tmux). You can run your ontape within the screen or tmux session. Then your putty ssh session can break: the command will keep on running.

    man screen of man tmux (or query some search engine) on how to do that.

    Best,
    Arjen.

    ------------------------------
    Arjen Van Drie
    ------------------------------



  • 14.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 03:25 AM
    Hi All,
    I was doing a trial restore.
    Using:
    nohup ontape -p -t STDIO < backupfile &

    File size is about 79,883 MB

    What I noticed in the message log is that 
    07:32:22  Physical Restore of rootdbs started.
    ----
    ---
    08:13:15  Physical Restore of rootdbs Completed.
    --
    --
    08:13:15  Maximum server connections 0

    Current time is 17:08:02

    onstat -d: shows Fast Reovery and chunks are in PI-B- 

    CPU load is 0.03 or so.

    After 08:13 I do not any messages in the log file.

    ps -ef shows oninit -r (9 processes) are running.

    1. How to know what the Informix Engine is doing?

    2. Are there any performance issues using ontape -p -t over ontape -r?

    3. No idea when this comes over to Quiescent Mode!

    Thank you in advance for your inputs.





  • 15.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 03:42 AM
    Hi Saradhi.

    "Physical Restore Completed" means it has finished. You can now use "onmode -m" to bring the instance fully on-line (or "onmode -d ..." if starting HDR or RSS).

    Next time, use "onstat -D" (capital letter) to view page writes during the restore, which shows which chunk it is currently restoring.

    Performance of "onstat -r" and "onstat -p" is identical, but the latter finishes without further restore/recovery phases.

    ------------------------------
    Doug Lawry
    Oninit Consulting
    ------------------------------



  • 16.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 03:58 AM
    Hi Doug,
    Thank you so much for your response.

    Yes, $onmode -m brought the instance to On-Line, and chunks in PO-B- Mode.
    Looks all good.

    I have a doubt here:

    a. ontape -p -t, should have come to Quiescent mode?
    b. onmode -m, looks like actually brought the instance from Fast Recover to On-Line.
    c. So, what exactly is happening in the Fast Recovery?

    d. Can I issue $onmode -m, soon after I notice  "Physical Restore of rootdbs Completed" in message log?





  • 17.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 04:08 AM
    a. ontape -p -t, should have come to Quiescent mode?
    No - it leaves the instance in Fast Recovery in case you want to apply logical logs separately with "ontape -l" or start replication.

    b. onmode -m, looks like actually brought the instance from Fast Recover to On-Line.
    Correct.

    c. So, what exactly is happening in the Fast Recovery?
    See a.

    d. Can I issue $onmode -m, soon after I notice  "Physical Restore of rootdbs Completed" in message log?
    Yes.


    ------------------------------
    Doug Lawry
    Oninit Consulting
    ------------------------------



  • 18.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 05:30 AM
    Hi Doug,
    That's great insight.

    Thank you so much for the clarifications.





  • 19.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 05:56 AM

    Probably means ontape –r and ontape –p instead of onstat –p and onstat -r

     






  • 20.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 06:01 AM
    Ah yes - thanks, Paul :-)

    ------------------------------
    Doug Lawry
    Oninit Consulting
    ------------------------------



  • 21.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 06:05 AM

    Or even onstat -Dr

    ��

     






  • 22.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 06:11 AM
    Hi Paul and Eric,
    Thank you.

    Yes, guessed the typo in Doug message. :)






  • 23.  RE: Execution of Long Restores Remotely

    Posted Sat May 30, 2020 06:13 AM

    No problem

     

    Onstat -Dr is the most accurate way actually to follow up your restore operation