System Bible -- Near-Line Backups of Critical Files ...

[A. Daniel King_1]

Hi, folks ...

Two-items:

(1) What critical HP-UX files should I have on-hand for a near-line (i.e., on-disk/from-disk) restore? Some of the items on my list include:

/stand/system
/stand/ioconfig
/stand/rootconf
/stand/bootconf
/etc
/usr/sbin/sendmail*
/usr/local/etc
/var/adm/cron/*.allow
/var/spool/lp/pstatus
/var/spool/cron/crontabs
/quotas
/tcb
/sbin/rc*
/sbin/init.d
/dev

And output from many commands:

kmtune # Output
lvlnboot –v # Output
vgdisplay –v # Output
others ...

... in addition to many site- and application- specific files and output. Sybase, EMC, etc.

We generate a ~5MB tarball and ship it to diverse geographic locations, and we keep daily iterations for several weeks. This is in addition to Ignite and Data Protector, which can be relatively cumbersome for simple, one-file restores. Its worth the cost of a couple-of-hundred MB to have such items very close-at-hand.

However, it is time to review the list of things we currently back up. I seem to recall that HP had a specific document for such things, and I'd like to go back and recheck for anything new or changed.

Which document was this, or is there a current document I should be looking into?

I'd love to use the forums to augment the official documentation, so advice and experience is also appreciated.

(2) Ditto for Linux, specifically for current Red Hat versions (v3-4).

[Geoff Wild]

What you really need to keep is a system configuration - ie how is the system laid out, software installed, etc.

I use 2 main tools - cfg2html and sysinfo403 (attached).

I run sysinfo and cfg2html from cron like so:

# Run the sysinfo script
0 6 1 * * /usr/local/sysinfo/sysinfo -a -b -o /usr/tmp/`hostname`.sysinfo >/tmp/sysinfo.cron 2>&1

# Run the cfg2html scripts
35 6 1 * * cd /opt/cfg2html; /opt/cfg2html/cfg2html_sun.sh >/dev/null 2>&1

BTW - to get rid of the annoying popup that the author inserted, modify head02.html in /opt/cfg2html/plugins and delete the following lines:







I collect the data on a central server and that data is replicated to a DR site.



Rgds...Geoff

[A. Clay Stephenson]

Since you already have Data Protector --- and because the critical files for YOUR sites are extremely hard to predict (and may change from day to day as to what's really important), let me suggest that you rethink your plan. Restoring from Data Protector is trivially easy, iff your have the media on hand in a library. It's then simply point-and-click. The problems is that you are shipping the media off site. While that is very good for data pretection, it's counter-productive for quick restores. The solution is to automatically copy your media using omnimcopy so that you have both an on-site and off-site copy of the media. This does one other thing for you. Since omnimcopy is a logical, rather than a physical, copy operation if the copy succeeds, you know you actually have a good backup.

I would never trust myself to be smart enough to include every critical file so my method has the advantage of leaving nothing out.

[A. Daniel King_1]

Clay, do you ever have a day off?

You are correct. We have an aggressive tape rotation policy, and the tapes go offsite farily quickly.

I don't really care about having all the files, just the most important ones ... Knowing that the most important file will be the one I did *not* include!

I'll have to consider doing a media copy for a small subset of our tapes.

Thanks!

[A. Daniel King_1]

Hmmm ... for Linux, is there anything better than lspci, perhaps all from /proc outside of actual PIDs? lvmdiskscan?