ez_archive
by Ed Zychowski <zychoe@champint.com>

PROCESS CONTROL - CONTROL SYSTEMS - QUINNESEC
Ed Zychowski 9/10/98

Download: ez_archive.zip (7 KB), ez_archive.tar.Z (8 KB)


IMPORTANT: This application has only been tested on 51-series stations at V4.2.3


The I/A system has two basic methods of backup. The first method, called a 
saveall, backs up the database of the control processsors, spectrum interface 
processors, AB stations etc. This back-up is made to diskette from a copy 
stored on the hosting application processor or application workstation. This 
type of backup can be performed during normal operation of the stations. The 
second form of backup is an image dump of workstations or application 
workstations. This backup is performed to a streaming tape and is made while 
the workstation is offline in "single user mode" and takes about an hour to 
perform. In the event that there is a failure of the hard drive on an 
application workstation, and control database changes have been made, this 
backup system is potentially inadequate even though a saveall of the control 
processor has been made. This is due primarily to how the compound summary 
access software and checkpoint software works. 

Without getting into a lot of detail about how the software works, here are a 
few examples of some of the problems.

If a block had been added since the last tape backup, the block won't be 
accessible from ICC. The block will still be running in the control processor 
and can be visible from select. The block cannot be "re-entered" from ICC 
because CSA sees it as existing. In the event that the control processor 
would need to reload, the block will not be there. You cannot up load the 
block from the control processor because an upload only uploads a subset of 
block parameters. The "save all" is useless because the only way to get 
saveall data back into the control processor is to initialize the control 
processor (completely deleting the control processors control database) and 
then doing a "load all" which will re-sync the CSA database. If the process 
is running, this is not usually acceptable.

I have spoken with a number of people from Foxboro and they acknowledge the 
problem exists. During the start-up of a recent I/A conversion, the hard drive 
on the application workstation was corrupted and we learned that this is a 
real problem.

To minimize the problem, I have written a program called ez_archive, which 
will automatically copy these important files to a remote station each day. 
In the event of a loss of the hard drive on an application workstation, the 
drive would be repaired, the most recent tape would be loaded and the backup 
files would be restored back to the application workstation from the remote 
station. 

On the application workstation, the files ez_archive and ez_mask should be 
copied to an appropriate directory. In our I/A system, that directory is 
/usr/ci/archive. The same directory should be created on the remote station 
that will be used as a repository for the back up files. The back up station 
for our I/A node is 02WP02. 

IMPORTANT !!!!!
The locale variables ArchPath and ArchSta must assigned appropriately in the 
script file ez_archive. This is done by editing the file. For example, given 
that my directory structure is /usr/ci/archive and my remote node letterbug 
is 02WP02, the first two lines of the script should be:

ArchPath='/usr/ci/archive'
ArchSta='02WP02'

Remember to use correct unix syntax for variable assignments. (ie. no spaces, 
correct quote symbol (` is different than '). Next make sure the file 
ez_archive and ez_archive.restore are executable if they aren't by entering 
the command:

chmod +x ez_archive ez_archive.restore

The script ez_archive can then be added as a cron process via crontab. In our 
system, it will run every day at 3am.

The program uses the directories in the file ez_archive.mask to filter 
directories in /opt/fox/ciocfg so that unnecessary files are not saved. This 
has the additional benefit that if a new station or compound is added, the 
archive software will not have to be modified. The new files will be backed up 
automatically. Additionally, if a compound or station is removed, the backup 
files will also be removed. The file ez_archive.log will be created on the 
application workstation in the same directory as the script. This file will list 
the last 20 times the archive ran. The code will also automatically rmount the 
remote station in the event that it becomes unmounted. Any errors generated by 
the script will be reported via e-mail to the user as all cron processes without 
a defined output destination do. The openwindows application mailtool works well 
to monitor this.

On the remote station, using the ArchPath as the starting point, the directory 
structure of the original files will be reconstructed. For example, on the 
application workstation, the source code of block BPCHEM:BPPROD is in 
/opt/fox/ciocfg/BPCHEM/BPPROD.s. On the remote station (using the our setup), 
the file will be on 02WP02 at /usr/ci/archive/opt/fox/ciocfg/BPCHEM/BPPROD.s.

To restore the files back to the correct location from the remote station, run 
the ez_archive.restore script. This script will get the remote station letterbug 
and path from the ez_archive script. Before running the ez_archive.restore 
script, it is necessary to ensure that the remote system is mounted to the AW.