Execution of Long Restores Remotely

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. #Informix

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

Hi Paul, Could you please, elaborate what is meant by running the command in a screen?

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 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

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 gunzipUse 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 < filenameWhen running commands remotely, put in background with "nohup" or "at now" so that it continues if you lose connection. ------------------------------ Doug Lawry Oninit Consulting ------------------------------

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

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.

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 ------------------------------

Hi Doug, Thank you for the valuable advice. Yes, there is no need to apply logical logs.

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

Thank you, Art.

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

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 ------------------------------

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 0Current 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.

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 ------------------------------

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?

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 ------------------------------

Hi Doug, That's great insight. Thank you so much for the clarifications.

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

Ah yes - thanks, Paul :-) ------------------------------ Doug Lawry Oninit Consulting ------------------------------

Or even onstat -Dr

Hi Paul and Eric, Thank you. Yes, guessed the typo in Doug message. :)

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