Looking for some help-VMS Severs running Openvms V8.3-1H1

[The Gunners]

Hi There, Im looking for a bit of VMS help. I have two non clustered standalone VMS Severs running Openvms V8.3-1H1. I want to create a simple job that looks at the disks on one and backs up the differences mabey every hour (like an incremental) to a saveset - it then copies this saveset to the second VMS box and restores it. (Sounds easy and I know the basic commands to do all this except my DCL skills are non existent) Was wondering if anyone has a similar type script mabey or could advise ?

[abrsvc]

If you can "cluster" the systems using the current standalone system disks, you can "serve" the drives and use host based shadowing to keep the drives equivalent. The main problem with your sepcific request is that many files may be "in use" which can cause some synchronization problems or access problems. While the backup utility has the ability to "ignore interlocks" and copy the files anyway, there are potential issues that can arise using this method.

Perhaps if you could describe the reasoning behind the request, we can provide options to accomplish your goals.

Dan

[The Gunners]

Hi Dan,
Thanks indeed for the reply. Well basically these are test systems. The users are developers and just want to try sync any executeables , commands , basic user files but not huge amounts of data or databases. Its just a failsafe really in case the first system goes down

[Ian Miller.]

How much data are your users prepared to lose?

[The Gunners]

Hi Ian , as I said its a test area so they basically asked would it be possible to run some kind of job that checeks every hour or so for exe's and specific files that they update quiet regularily and just copy them over. Its a best endeavours approach is the way Im working with them on it , in my mind it doesnt sound like a major task - perhaps Im not appreciating the complexities

[RBrown_1 · Accepted solution]

More detail is required. Consider this example. Start with this on the local system:

$ BACKUP/SINCE=BACKUP/RECORD/VERIFY REMOTE::XFR.BCK/SAVE

On the other system:

$ BACKUP XFR.BCK/SAVE

But this may not do what you want if you already have a regular backup job that includes /RECORD. In that case you would probably want to save the backup time in a file or logical name, and use that saved time in your /SINCE.

Other considerations:

Files that are open at the time that the BACKUP/SINCE runs will *not* be backed up. We count on them being available to back up next cycle. Are there files that you will want to back up that will happen to be open *every time* you attempt to back up?

Will the backup always go in the same direction? If not, then there needs to be additional cleverness.

Doing it automatically? I would put these commands in a couple of self-resubmitting batch jobs.

As an alternative to BACKUP, consider the attached command file, which runs on the receiving system. It maintains a "last backup date" file in each directory, but it looks like you have to manually create version 1 for that file.

[RBrown_1]

"Consider that attached command file".

[John McL]

You say ...

"Thanks indeed for the reply. Well basically these are test systems. The users are developers and [we ?] just want to try sync any executeables, commands, basic user files but not huge amounts of data or databases. Its just a failsafe really in case the first system goes down."

Just a failsafe ?

Is there any special reason why this test system going down should present a major problem? Your .EXE's, .COM's etc should still be okay on the disk.

Is it that a reboot takes so long that you want to move the users to the other system while the first system is rebooting?

If that's then case then clustering the two systems might give you what you need without any requirement to run these Backups and restores, moreover there's no issue with disk and directory compatibility (e.g. size). Sure a crash and reboot will cause a minor disruption to the cluster, but it should be only a couple of minutes at most.

Controlling which node users can access should be child's play.

[Shriniketan Bhagwat]

Hi,

BACKUP can be used to create the saveset over network. It works over DECnet. Please refer section 11.5.3 from HP OpenVMS System Manager's Manual, Volume 1: Essentials. Below is the link.
ftp://ftp.hp.com/pub/openvms/doc/AA-PV5MJ-TK.PDF

You can use the below steps to create the files on other node as per your requirement.

1. Create the image backup of disk on node1 across network on to node2 with /RECORD qualifier.
2. Restore the image backup on node2.
3. On regular bases create incremental backup of disk on node1 across network on to node2 with /SINCE=BACKUP and /RECORD qualifier.
4. Restore the incremental backup on node2.

Use /IGNORE=INTERLOCK qualifier.

Regards,
Ketan

[The Gunners]

Guys thank you very much for the replies so far. I noticed that the cluster option has been mentioned several times. This might be worth exploring. Can I say that these two servers are in different locations physically (about 10 miles apart) so we would be 'clustering' over a network. Would this be possible and what would the steps be ? I hadnt considederd clustering at all due to this. The users are thinking of the second node as a sort of DR box that they would have their latest exe's if the first building went splat or flooded etc