Operating System - OpenVMS
1748219 Members
4828 Online
108759 Solutions
New Discussion юеВ

Re: Backup of system disk through Command View EVA snapclone

 
SOLVED
Go to solution
Ana M. Garc├нa Olivencia
Regular Advisor

Re: Backup of system disk through Command View EVA snapclone

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
Regular Advisor

Re: Backup of system disk through Command View EVA snapclone

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
Honored Contributor

Re: Backup of system disk through Command View EVA snapclone

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
it depends
Ana M. Garc├нa Olivencia
Regular Advisor

Re: Backup of system disk through Command View EVA snapclone

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.
Honored Contributor

Re: Backup of system disk through Command View EVA snapclone

DISPLAY_JOBS.COM is available at
http://dcl.openvms.org/stories.php?story=07/09/21/4385749
____________________
Purely Personal Opinion
Jon Pinkley
Honored Contributor

Re: Backup of system disk through Command View EVA snapclone

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
it depends
Hoff
Honored Contributor

Re: Backup of system disk through Command View EVA snapclone

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
Respected Contributor

Re: Backup of system disk through Command View EVA snapclone

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
Regular Advisor

Re: Backup of system disk through Command View EVA snapclone

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