Backup of system disk through Command View EVA snapclone

[Ana M. García Olivencia]

Hi all.

I was wondering if it's possible to backup an OpenVMS system disk making a snapclone through Command View. The versions are:

OpenVMS 8.3 with the latest patches.
Command View 7.00.01

The steps I've followed are:

1. Shutdown of the system.
2. Make a snapclone of the system disk.
3. Make the snapclone bootable through the writeboot utility.
4. Boot from the snapclone disk. At the beginning it seems ok but a warning message appears and, at the end, a bugcheck follows. These are the messages:

********************************
P00>>>b
(boot dga1.1001.0.4.0 -flags 0)
kgpsaa0.0.0.4.0 Link is down.
block 0 of dga1.1001.0.4.0 is a valid boot block
reading 1226 blocks from dga1.1001.0.4.0
bootstrap code read in
base = 200000, image_start = 0, image_bytes = 99400
initializing HWRPB at 2000
initializing page table at 1f2000
initializing machine state
setting affinity to the primary CPU
configuring I/O adapters...
ncr0, hose 1, bus 0, slot 1
isp0, hose 1, bus 0, slot 3
isp1, hose 1, bus 2, slot 0
floppy0, hose 0, bus 1, slot 0
pks0, hose 0, bus 0, slot 3
kgpsa0, hose 0, bus 0, slot 4
tulip0, hose 0, bus 0, slot 5
jumping to bootstrap code


OpenVMS (TM) Alpha Operating System, Version V8.3
� Copyright 1976-2007 Hewlett-Packard Development Company, L.P.


%SMP-I-SECMSG, CPU #01 message: P01>>>START
%SMP-I-CPUTRN, CPU #01 has joined the active set.
%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port


**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****

** Bugcheck code = 0000019C: INCONSTATE, Inconsistent I/O data base
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: VSCI0
** Supported CPU count: 00000004
** Active CPUs: 00000000.00000003
** Current Process: SWAPPER
** Current PSB ID: 00000001
** Image Name:


**** Starting compressed selective memory dump at 15-JAN-2009 10:21...
................
...Complete ****

halted CPU 0

halt code = 5
HALT instruction executed
PC = ffffffff80087b24

CPU 0 booting

(boot dga1.1001.0.4.0 -flags 0)
.........

*****************************

I have been looking for this error (PORT_WAIT) but I haven't found anything.

Any advice will be very appreciated.

Thanks in advance.

Regards.

Ana

[Jon Pinkley]

Ana,

A snapclone is an identical copy of the original disk. So yes it is possible to make a backup with a snapclone. I.e. it is equivalent to a backup/physical to another disk.

I am not sure why you used writeboot; as long as the original disk was bootable, the snapclone will be (assuming wwidmgr has made the device available to SRM).

Are you booting the snapclone on the same machine or some other Alpha?

Jon

[Ana M. García Olivencia]

Jon.

I used writeboot because, although I haven't told you before, the first time after making the snapclone, I booted the snapcloned disk WITHOUT executing the writeboot utility, and with the same error message. Thinking that this could be the reason, I executed the utility, but with the same result.

And, yes, I am booting from the same system (it's a test system).

Thanks.

Ana

[Jon Pinkley]

Ana,

Was the snapclone presented with the same o/s unit id, or did you present it using a different one. I.e. was the original system disk $1$dga1 or was it something else?

Did you use wwidmgr so SRM is seeing the new device?

If it is a test system, here is what I would try.

P00>>>wwidmgr -clear all
P00>>>wwidmgr -quickset -udid 1

If you have dump off system disk, then you need to use quickset to that unit too
P00>>>wwidmgr -quickset -udid P00>>>init
P00>>>b

Jon

[Ana M. García Olivencia]

Jon.

The original system disk is presented as os_unit_id 1; the snapclone disk is presented as os_unit_id 4444, and these setting have not been changed during the tests. Os_units_id 8883, 2 and 9999 below have nothing to do with this topic.

At console, each time I booted from the snapclone disk, I have followed these steps:

***********************************
P00>>>wwidmgr -clear all

P00>>>init

P00>>>wwidmgr -show wwid
[0] UDID: 1 WWID:01000010:6005-08b4-0006-cb32-0000-c000-01f5-0000 (ev:none)
[1] UDID:8883 WWID:01000010:6005-08b4-0001-1e88-0000-a000-037a-0000 (ev:none)
[2] UDID: 2 WWID:01000010:6005-08b4-0006-cb32-0000-c000-0217-0000 (ev:none)
[3] UDID:9999 WWID:01000010:6005-08b4-0006-cb32-0000-c000-0204-0000 (ev:none)
[4] UDID:4444 WWID:01000010:6005-08b4-0006-cb32-0000-c000-021d-0000 (ev:none)

P00>>>wwidmgr -quickset -item 4 -unit 1

Disk assignment and reachability after next initialization:


6005-08b4-0006-cb32-0000-c000-021d-0000
via adapter: via fc nport: connected:
dga1.1001.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebd8 Yes
dga1.1002.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebdc Yes

>>>init

>>>show bootdef_dev
bootdef_dev dga1.1001.0.4.0 dga1.1002.0.4.0

>>>boot

(The messages you know)

***************************************

When I want to boot from the original system disk, I repeat the same steps but this time, the command I execute is:

.....
P0>>>wwidmgr -quickset -item 0 -unit 1
....

and all works ok.

Thanks.

Ana

[Martin Vorlaender]

Ana,

>>>
[4] UDID:4444 WWID:01000010:6005-08b4-0006-cb32-0000-c000-021d-0000 (ev:none)

P00>>>wwidmgr -quickset -item 4 -unit 1
<<<

AFAIK, the unit number and the UDID must be the same for VMS. So, try it with '-unit 4444'.

>>>
When I want to boot from the original system disk, I repeat the same steps but this time, the command I execute is:
.....
P0>>>wwidmgr -quickset -item 0 -unit 1
....

and all works ok.
<<<

...because unit number and UDID are the same.

HTH,
Martin

[Uwe Zessin]

How about:

>>>> wwidmgr -quickset -udid 4444

[Jon Pinkley · Accepted solution]

Ana,

Can you back up and give us a bit of info about the purpose of the "backup"? Is it so you will have a fallback position for an upgrade, for testing something, etc?

Short answer: The o/s unit id must match the unit number device name you boot from at the SRM >>> prompt.

In other words: if the following is true

6005-08b4-0006-cb32-0000-c000-021d-0000
via adapter: via fc nport: connected:
dga1.1001.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebd8 Yes
dga1.1002.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebdc Yes

>>>init

>>>show bootdef_dev
bootdef_dev dga1.1001.0.4.0 dga1.1002.0.4.0

>>>boot

Then the o/s unit id associated with vdisk with wwid 6005-08b4-0006-cb32-0000-c000-021d-0000 must be 1. If it is not, you will see the bugcheck.

You have two options:

1. If it is important to maintain the same physical device name $1$DGA1:, then you need to unpresent the original disk (I like to change the o/s unit id as well, although I don't know that it is a requirement as long as it is not presented). Then create a snapclone specifying 1 as o/s unit id. After the snapclone copy starts, you can present the vdisk to the VMS host. I don't think you will be able to change the o/s unit id until the copy operation completes. You will need to run wwidmgr to associate the new wwid with the udid (I am pretty sure udid == o/s unit id, is that correct Uwe?) Then boot as usual. This operation is analogous to putting a different CD in the same drive.

2. If you aren't in a cluster or using DOSD (dump off system disk), then you should be able to make all your operations "physical disk name independent" and "system disk label name independent" by using names like sys$sysdevice instead of $1$DGA1: or DISK$APLHASYS:. Then after presenting the snapclone vdisk, run wwidmgr to associate the new o/s unit id with the device unit, and boot form the new device name. for example:

>>> wwidmgr -quickset -udid 4444
>>> init
>>> show dev dga
>>> b dga4444.whatever show device displayed

Alternatively set SRM environment variable bootdef_dev to dga4444... and >>>b

Good luck,

Jon

[Robert Atkinson]

I though VMS had problems with presented unit numbers above 255?

Rob.

[Uwe Zessin]

I think that that was a limitation on CI.

It's quite common to have a served device like $1$DKA500 or $1$DGA301.

[Ana M. García Olivencia]

Hi all.

I didn't know the unit number and the udid must be the same for OpenVMS. Until now, I always presented the vdisks with the same unit I wanted them to be referenced, but I thought I have tested the other possibility before.

In this case, the reason not to use the same method was only to save Command View operations because it was a test and I was convinced that it worked ok.

Jon. The reason for doing that is to have another alternative to have a system disk backup ready to boot. Therefore, I think that, in case of need, the best way is to unpresent the original system disk and present the snapcloned disk as os_unit_id 1.

Robert. In my experience there is no limitation above 255 because I usually present vdisks with os_unit_id 9999. I don't know if there is an upper limitation.

Well, I think that my problem has been solved.

Thank you very much for all your information
and help.

Regards.

Ana

[Ana M. García Olivencia]

Hi all again.

This is only for your info.

I have created a new snapclone of the system disk but this time, without doing a shutdown (the system up) and without executing the writeboot utility (as Jon had said).

I booted from the snapcloned disk and it was ok.

Ana

[Jon Pinkley]

Ana,

Just FYI, when you snap a mounted system disk, if the queue manager's database is on the system disk, the jobs in the queues will be lost. That is intentional, i.e. it was designed to work that way. Most of the time that is the behavior you want. If it didn't behave that way, the next time you booted, there may be many time released jobs that would immediately start executing, since there is a potential for a long elapsed time since the last time the system ran from that copy.

If you normally have jobs that are scheduled for times in the future (for example month end jobs that resubmit themselves), you will need to make provisions to have them resubmitted at boot time if they do not exist.

Jess Goodman has a good tool (DISPLAY_JOBS.COM) to snapshot the jobs in all queues and it creates a command file that can be edited and jobs resubmitted. Note that the jobs that get resubmitted will not have the same entry numbers, so any job synchronizing on an entry number will not work as expected.

John Gillings and Hoff will want you to know that any method of backing up a disk that is mounted is not guaranteed to work.

My opinion is that for the system disk, a snapclone is extremely likely to be bootable, at least if the disk would be bootable when you did a reboot. That said, it would be best to take the snapclone when there was not a lot of activity on the disk, and not while you have people adding new SYSUAF accounts, or adding new identifiers or granting identifiers. These operations all add records to indexed files; while that operation is in progress it is possible that the file as stored on disk be in an inconsistent state for short periods of time.

Of the available options to make backups of the system disk while the system is up, a snapclone is better than a backup/ignore=interlock. It is similar to removing a member of a shadowset.

If the purpose is just to have a bootable backup available, there is no need to assign an o/s unit id or present the snapclone. Those operations can be done later when you need to use the snapclone.

My preference is to have a snapclone around that I have booted from as a fallback. You can take periodic snapclones so they have any changes made to SYSUAF, system startup procedures etc. The reason for keeping a snapclone I have booted from is that it is a known working copy. There are things that can cause the system disk to be unbootable that aren't detected during normal operations. There is the possibility that someone broke something in the system startup procedures, and if the system hasn't been booted for 6 months, you might not be aware of the problem until it is too late.

Bottom line: A good time to take a snapclone is after a successful boot. If you have scheduled downtime, that's also a good time to verify booting from the snapclone.

Good luck,

Jon

[Ana M. García Olivencia]

Jon.

I have decided to reopen the thread because I want to ask another question and I want to give points to the answers.

>>> Just FYI, when you snap a mounted system >>> disk, if the queue manager's database is >>> on the system disk, the jobs in the
>>> queues will be lost. That is
>>> intentional, i.e. it was designed to >>> work that way. Most of the time that is >>> the behavior you want. If it didn't
>>> behave that way, the next time you
>>> booted, there may be many time released >>> jobs that would immediately start
>>> executing, since there is a potential >>> for a long elapsed time since the last >>> time the system ran from that copy

I didn't know this point, although, as you say, it's logical. Thanks for the info.

>>> If you normally have jobs that are
>>> scheduled for times in the future (for >>> example month end jobs that resubmit
>>> themselves), you will need to make
>>> provisions to have them resubmitted at >>> boot time if they do not exist.

Yes, we have a procedure that, at boot time, checks the existence of the jobs.

>>> Jess Goodman has a good tool
>>> (DISPLAY_JOBS.COM) to snapshot the jobs
>>> in all queues and it creates a command
>>> file that can be edited and jobs
>>> resubmitted. Note that the jobs that get
>>> resubmitted will not have the same entry >>> numbers, so any job synchronizing on an >>> entry number will not work as expected.

Is it possible to get that procedure?.

>>> John Gillings and Hoff will want you to >>> know that any method of backing up a
>>> disk that is mounted is not guaranteed >>> to work.

Thanks for the recommendation. As I told you at the beginning of this thread, I was testing some possibilities of backup up a system disk but I know that the more accessed the system disk is, the less possibilities to work ok when booting from it. So, as you suggested, to take a snapclone of the system disk is another possibility similar to "bakckup/ignore=interlock" and, that it's better to do it when it's hardly accessed.

In our case, our daily system disk backup is through Data Protector at night (with minimum access) and I think (correct me if I am in a mistake), is the same case as mentioned in the above paragraph. So, the snapclone for us is a quick way to do a googd backup when, for example, installing patches or whenever the system is down due to other reasons, and to have a possible good backup (a last chance whenever the other possibilities fail) when doing it when the system is up.

Thank you very much again for your exhaustive information.

Regards.

Ana

[Ian Miller.]

DISPLAY_JOBS.COM is available at
http://dcl.openvms.org/stories.php?story=07/09/21/4385749

[Jon Pinkley]

Ana,

Ian has pointed you to a downloadable version of DISPLAY_JOBS.

I don't use DataProtector, so I can't give you much useful information about it. I believe I have seen mention of having DataProtector use a "snapshot" of a real disk, and I think that is controlled by command procedures that DP can schedule.

See this thread as a teaser http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=602664

As far as whether DataProtector can do the equivalent of backup/ignore=interlock, I don't know. I don't think that DP is generally used for restoring a bootable volume, at least not directly.

See this thread http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1153412

Guenther Froehlin states that it is possible to restore a system disk with a few extra steps (initializing the disk prior to restore, and using writeboot after the restore). Also, you need to tell DP to handle alias entries correctly.

For upgrades, I generally make an initial snapclone of the original disk before doing anything, then snapshots after the a "major upgrade", (i.e. changing from 7.3-2 to 8.3) as I tend to take multiple snapshots along the way when applying patches and updates. It is possible to return the source vdisk to the state of a snapshot, and that has saved me in several cases when an update goes bad for some reason. After I am satisfied that things are working, I delete the snapshots, and do another snapclone, which is my new baseline. I generally keep the previous snapclone around for a while. (it can be a vraid5 vidsk on slow disks, its just there for emergencies and reference).

Snapshots and snapclones each have their advantages and disadvantages. The biggest disadvantage of snapclones is that once a snapclone starts, you can't take another one until the first one completes the copy. For a system disk, that isn't normally an issue, unless you have a system disk that is larger than it should be. But for a 500GB data disk, a snapclone can take a while to complete. Just something to consider. The other issue is the amount of space used.

Jon

[Hoff]

Why even back up a system disk? At all. Seriously.

Back it up once (after an upgrade, etc) with the correct tool (that's BACKUP /IMAGE and not DP, IMHO), and keep your volatile files (SYSUAF, et al) on another disk.

With the (good) backup, you can do a restore.

With the volatile stuff on another disk, the system disk is static.

And if you do this disk-level separation in any sort of a reasonable fashion, you can rebuild the disk from just the non-static files and the distros and/or an old backup. I keep all the startup and shutdown (customized) stuff off to the side, too.

[Robert Atkinson]

Hoff, as you can see, the system disk is not quite that static :-

ALPHA_ROB$$ dir sys$sysdevice:[*...]/mod/sin=1-jan/grand

Grand total of 118 directories, 8276 files, 24333206/25453880 blocks.


Although I'm being quite flippant, the reality is that people do have data on the system disk that is probably changing, e.g. TCP/IP stack changes, SYSTARTUP, SYLOGIN, SYLOGICALS, etc, etc.

Even if you're lucky enough to be running a system that hasn't been touched in 10 years, I'd still take regular backups in case that tape you though would recover you is lost or damaged.

Rob.

[Ana M. García Olivencia]

Jon.
Thanks for the references and the explanations. I'll use the snapclone as a system backup, whenever the system is down, when upgrading and installing patches, and we'll continue with our Data Protector policy doing daily system disks backups at night and taking sporadic snapclones as alternatives. In my case, I'll test in my next patch installation at our production systems if it's use doing a snapclone or a snapshot (according to the time spent).

Hoff.
I agree with Robert that the system disk is not as static as you say, specially in our case that main procedures and system files are in the own disk.

Well, thanks again to all of you because all your information has been very useful for me.
I think that, if there are no more answers, I'll close the thread in a few days.

Regards.

Ana