VMS Image backup

[dudharkar chandra]

I have source disk of size 250Gb and target disk of size 150GB. Data size 100GB approx.

Question.
1) Can I take image backup on target disk which is less in size than source disk.

2)What would be estimated time required to complete backup of above disk. Since till now we have taken image backup with 20Gb of disk.

[Robert Badar]

BACKUP/IMAGE is copy by files by default and target disk can be less in size than source.
Target disk size must be more than data.

Estimated time depends on several factors, disk speed, machine... then there is no answer to satisfy you.

[Jan van den Ende]

Chandra,

Robert answered one part nicely.

On the estimated time:
assuming you will use essentially the same system, and same speed periferals; how long did 20 GB take? 100 Gb will approximately take 5 times that. (if you DID mean 20 GB of data, disk size is irrelevant here).

Proost.

Have one on me.

jpe

[dudharkar chandra]

As per past experience when we take image backup with backup/image on Alpha ES45 machine having processor 1250 MHz it take 1.5 hrs appox for 15 GB of data. So shall I estimate in multiple of that time which comes
around 9-10 Hrs for 100Gb of data. It is not possible to take downtime of system for that much of time since disk is online and used for critical public application.

we are using command
$backup/image/ignore=(label,inter)- sourcedisk: targetdisk:

[Robert Badar]

1.5 hr for 15GB is pretty much, but it can be effected by a large number of files on disk, this is one of factors.

[P Muralidhar Kini]

Hi Dudharkar,
>> I have source disk of size 250Gb and target disk of size 150GB.
>> Data size 100GB approx.

Image backup would backup all the data that is present in the disk.
i.e. The data that is backed up will only be part of the disk that
is used up by the file system.

Physical backup would backup all the blocks that are present in the
disk(i.e. irrespective of whether the file system uses it or not).
The data that would be backed up would be of the same size as that
of the source disk. Hence the destination disk should be of size
same as source disk or more.

You are doing image backup and hence you need to worry only about
the size of data on the source disk. The disk size is 250GB and data
size is 100GB. Hence the destination disk should be 100GB or more.

150 GB destination disk is ok for the image backup.

Its difficult to give a estimate because it would depend on various
factors like disk speed, system speed, what other operations are going
on in the system at the time of backup and so on.

Regards,
Murali

[Robert Gezelter]

chandra,

I recommend caution on the /IGNORE=INTERLOCK. Ignoring the locks on files can lead to inconsistent file states.

While often used on BACKUPs of online system volumes, /IGNORE=INTERLOCK is done with the understanding that certain files (e.g., log files, SYSUAF) will not be in a consistent state. Often, other steps are taken to get backups of these files.

Caution is recommended.

- Bob Gezelter, http://www.rlgsc.com

[P Muralidhar Kini]

>> recommend caution on the /IGNORE=INTERLOCK. Ignoring the locks on
>> files can lead to inconsistent file states.
Good point.
Looks like the disk in question is online which would mean files on the disk
can getting modified on a continious basis.

If backup is taken with the "/IGNORE=INTERLOCK" qualaifier and if the file
that is being backed up is in the middle of modification by some application
then the latest data of the file may not always be backed up.

This is a known behavior and as robert has pointed out it needs to be used with caution.


Regards,
Murali

[labadie_1]

Some people wanted to rename the /ignore=interlock qualifier of backup to
/allow=corruption, which is more self-explanatory.

You should read carefully this article from the VMS Technical Journal V1 by John Gillings

http://h71000.www7.hp.com/openvms/journal/v1/backup.html

[Mobeen_1]

As many of the posts suggest use Backup/Image and if the disk is in use/online; then i would suggest that you use /ignore=interlock.

Second part of your question on the time....you cannot really extrapulate and calculate for 150 GB i.e. Backup A used to take 15 mins for 15 GB, therefore 150 GB will take 150 mins. This is because type of disk, contents in disk, performance and various other things play a role in determining the same

[Shriniketan Bhagwat]

Hi,

Image BACKUP archives only the occupied blocks (i.e. space occupied by the files) but not the free space as in case of physical BACKUP. Hence in your case you can backup the disk of capacity 250GB (containing occupied space 100GB) on to the 150GB capacity disk.

If you are using /IGNORE=INTERLOCK qualifier (online BACKUP), then there will be the slight difference between the data in the saveset as compared to the actual file which are locked during BACKUP. To have the consistence copy of the files, it is recommended to perform the offline BACKUP i.e. after business hours when the less activity on the disk is happening.

Regards,
Ketan

[Shriniketan Bhagwat]

Hi,

Some details about the /IGNORE= INTERLOCK qualifier.

/IGNORE= INTERLOCK qualifier processes files that otherwise could not be processed due to file access conflicts. Use this option to save or copy files currently open for writing by other applications. This qualifier instructs BACKUP save or copy operation to override restrictions placed on files such as interlocks. File system interlocks are expressly designed to prevent data corruptions, and to allow applications to detect and report data access conflicts. Use of the INTERLOCK keyword in BACKUP overrides these file data integrity interlocks. The data that BACKUP subsequently process/archives can then contain the difference as compared with that of open files.

Regards,
Ketan

[Jan van den Ende]

Chandra,

>>>
So shall I estimate in multiple of that time which comes
around 9-10 Hrs for 100Gb of data. It is not possible to take downtime of system for that much of time since disk is online and used for critical public application.
<<<

So, now is the time to get YOUR knowledge of YOUR system to work.
- What account is running BACKUP? Using a dedicated account with parameters optimised for Backup for YOUR environment (if you are not already doing that) can make a big difference. I have not yet seen what disk config you have, but take into account that SAN controllers react quite unfavorable to the "older" optimisation suggestions!
- Does your data have (easily identifiable) big ( say, at least 30 % ) parts of rarely or never changing data? Then you can make (at least 2) BACKUPs of those files. Store them SAFELY. And then
$ SET FILE /NOBACKUP for those files.
But remember that when you need a restore, you must get those from their own backups.
And if you have to modify any of that, you need to refresh their BACKUPs.
For that action, do NOT forget /IGNORE=NOBACKUP in that BACKUP command.
- The previous can be made much easier if you can split the stable and the volatile data over different drives. (Logical Names can be a big help in that!). Now you make regular backups of the "volatile" drive, and only after changes, of the "stable" data drive.

hth

Proost.

Have one on me.

jpe

[Shriniketan Bhagwat]

Hi,

In this case for the long run, to reduce the BACKUP window, you can prefer the combination of image and incremental backup strategy.

Regards,
Ketan

[Art Wiens]

"It is not possible to take downtime of system for that much of time since disk is online and used for critical public application."

If it's "critical", then some money needs to be spent on additional disk storage and software licensing resources - set up volume shadowing. A disk member containing the data can then be removed from the shadow set (leaving the application available) for backup purposes.

Uptime has associated costs.

Cheers,
Art

[Stanley F Quayle]

100 GB of data might not fit in a 150 GB disk.

A 1-byte file will occupy a number of disk blocks equal to the cluster factor.

Another reason is the maximum number of files on the disk, which is related to the cluster factor.

Both of these values are determined when the disk is initialized. In VMS versions prior to V7.2, there was a set formula for the cluster size. On big disks, that can result in a cluster size of hundreds or thousands of blocks.

If you are using V7.2 and later, I suggest you check out HELP INIT/CLU and HELP INIT/MAX.

If you use a non-standard cluster factor, your BACKUP command will have to include the /NOINIT parameter on restore, or else BACKUP will initialize the disk.

[P Muralidhar Kini]

Hi dudharkar,

Ya right. Similar suggestion from me.
If the disk in question is critical then its best to either setup volume
shadowing or have raid configuration, so that you have a backup disk in
case of disk failure.

In case of volume shadowing, you can pull out one disk for backup while
your applications continue to use the other disk for data.
Once the original disk is put back, volume shadowing would ensure that
both the disk would have updated data.

Regards,
Murali

[dudharkar chandra]

If I use /log as qualifier after backup command then will it impact on time taken for backup.

[P Muralidhar Kini]

Hi dudharkar,

>> If I use /log as qualifier after backup command then will it impact on
>> time taken for backup.

Yes. The "/LOG" qualifier determines whether the file specification of
each file processed is displayed to SYS$OUTPUT or not.
The default is "/NOLOG" in which case the file specifications for
each file processed is not displayed to SYS$OUPUT.

i.e. IF "/LOG" qualifier is used then for each file that is processed,
extra time would be taken to display file specification to SYS$OUTPUT.
It would take more time when compared to backup done with "/NOLOG" but
i dont think it would drastically bring down the time taken for the
backup as the data present in the disk itself is large (100GB).

In general image backup of a disk having 100GB worth of data is going
to take time.

Regards,
Murali

[Shriniketan Bhagwat]

Hi,

Yes, /Log qualifier impacts the time taken by the BACKUP process.

To make your BACKUP faster, set the process quota values as described in the System Managerâ s Manual, Volume 1: Refer the section Setting Software Parameters for Efficient Backups. Link is provided below.
http://h71000.www7.hp.com/doc/82final/aa-pv5mj-tk/aa-pv5mj-tk.html

Also execute below command before performing the BACKUP.

$ SET RMS/BUFFER=127/ EXTEND=5000.

This command allows BACKUP to use more larger buffers when writing save set blocks to disk. The larger extend value reduces the impact of extending the save set file during a save operation.

Regards,
Ketan

[Hoff]

>...To make your BACKUP faster, set the process quota values as described in the System Managerâ  s Manual...

And if you're already there and have your quotas set to the recommendations, then the next step is usually faster hardware; finding the bottleneck and removing it. That's usually the input disk drive, though can be the bus or the target tape drive.

Correctly-tuned BACKUP is generally limited by how fast it can get data off a disk (eg: fragmentation), within about 10% or so of the theoretical maximum bandwidth of the slowest device in the I/O path.

If you need yet faster, an alternative approach (and described over in the shadowing manual) involves splitting a member off a shadowset, then backing that member up. That's a moment-in-time backup, though the snapshot might not be entirely consistent if you catch any multi-part write I/O activity in flight.

[P Muralidhar Kini]

>> Correctly-tuned BACKUP is generally limited by how fast it can get data
>> off a disk (eg: fragmentation),
You can degrament the disk on a regular basis so that the disk is not badly
fragmented. You can use DFO for the defragment operation and may be
schedule it to run when there is less load, say once a week or any other
frequency that suits best based on the disk usage.

Regards,
Murali