MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

Re: Save/restore of '/tmp'



fixed

On 01-Aug-2014 06:26 -0500, rob@xxxxxxxxx wrote:
I've migrated several lpars from Power 6 to Power 8, with a few more
to go. One thing I've noticed is that even though BRMS says it was
saved it doesn't seem to get restored on the target system.
The creation date/time Creation date/time: 07/29/14 12:12:28 is way
before the restore of the stream files.

The logs would say what was restored.? In my experience the Restore (RST) of a directory or file does transpire according to what is logged by restore, even when the directory or file already exists; barring any errors, for example due to disallowed object differences. A directory, much like a file, is a container; the existence allows the /objects/ within to be restored, such that although the container was /restored/, only the contents that were restored are notable.

I am guessing it was created with the restore of the OS.

Some objects are created during an IPL irrespective the IPL being part of an install, many others only during an install; though often the run-time would be designed to reactively create those same objects if they are found to be missing when required. The Object Information Record (OIR) of the /QSYS.LIB objects is much nicer from which to determine origins; excepting of course, the anomaly with the "system created on" information discussed recently: <http://archive.midrange.com/midrange-l/201407/msg00338.html>

So when you restore the stream file system you will get the
subdirectories underneath it but not the attributes of '/tmp' itself.
Which is a big thing if you have to run CHGATR OBJ('/tmp')
ATR(*RSTDRNMUNL) VALUE(*NO) in order to get email attachments to work
from IBM i email utilities. Just run that again after a restore.

I have little idea of what BRMS does with regard to saving the /tmp, but I would expect the OS would by default [for DR B&R] treat the /tmp much the same as various system libraries having a function, if not analogous, at least somewhat similar; e.g. similar to how the *LIB objects QRPLOBJ and QRECOVERY would and should not be saved and\or restored as part of DR. And then, BRMS to do what the OS built-in backups do. I actually would have guessed that the directory /tmp would get created with [err... changed after creation to have] the Allow Save (*ALWSAV) attribute set to *NO.


This is not covered in the "Recovering your system" manual.<<SNIP>>


I would expect there is at least some allusions, if not specific mention of, implementing System Change Management; ensuring that customizations made to the prior system should be re-applied to the new system. That Change Attribute (CHGATR) request is really no different than any other customization in that regard. Introduced as a change to the default behavior spanning some release, however, possibly that Restricted Renames And Unlink (*RSTDRNMUNL) attribute change was eventually implemented by some sys admins, reactively rather than proactively; a customization by any origin is best implemented as part of proper System Change Management, and is not unique to a recovered system.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact