Peter,
Some random comments:
Do you know the reason backups are taking a long time? Is it due to reading the data from the source disks or the writing to tape? If it is because you are reading many small files, then disk to saveset on disk may not speed things up substantially. However, writing to a saveset will in general be faster than file to file, especially for many small files.
It appears that the output disk is on the same SCSI controller as the input disks, which can cause some additional contention for the same resource. Depending on what the DKB devices are, that may not be an issue. Hopefully your tape drive has its own dedicated SCSI controller.
I haven't seen anyone mention incremental backups yet. With VMS backup you have the ability to do a backup/image/record which makes a complete backup of the device, and tags each file with a backup timestamp.
Once that is done, you can do a
$ backup device:[000000...]*.*;*/modified/since=backup/fast ! differential backup
to create a "differential" backup; all files modified since the image backup. To save space, but increase the work necessary to recreate a volume from the backups, you can use
$ backup device:[000000...]*.*;*/modified/since=backup/record/fast ! incremental backup
This will tag each file backed up with a new backup timestamp, so the next incremental backup will only copy files that have been modified after the previous incremental backup. I prefer to use /record only with the full image backup.
To address your points:
----------------------------------------
Overnight processing window is shrinking
Have an easier recovery mechanism
Have an alternate backup for tape failure
----------------------------------------
The following I have not tried, but I think it should work, based on what I have read about the shadowing product. We are using controller based mirroring and snapshots at this time, so I have no recent experience with HBVS (since WBM optimizations).
To really cut your backup window, and to make it possible to have a meaningful verify pass, you need some way to get point-in-time snapshots.
One possibility is host based volume shadowing (HBVS, extra license required), and write bitmaps to track what has changed while the snapshots are not members of the shadowset. This would require using LDDRIVER to partition your DKB500 drive. Because DKB500 could easily become a bottleneck, you will probably not want to have more than one LD device as a shadowset member (SSM) at any point in time (too much contention for the underlying device). However, if only a small percentage of the disk space is modified during a single day, you could bring a single LD device back into the shadowset using the write bitmap (WBM), and only the data that had changed would need to be copied to resynchronize the LD to the DK device (the granularity of the bitmap is around 128 blocks (it may be 127, someone that knows will chime in).
Once synchronized, you would reinit the write bitmap, and split off the LD member, which would then be a point-in-time snapshot of the DK device, and VMS will remember what chunks of the DK disk get modified while the LD member was absent from the Shadowset, making the next resynchronization much quicker that a complete copy.
If there is a period of time that has little write activity, you could potentially have multiple LD devices shadowed with the corresponding DK devices. Note Well: if you do this, and you have write activity to multiple DK devices, the write performance is going to be much slower. The potential advantage is that you could quiess the system once, and dismount the LD SSMs within a short period of time. This would be the "down time" from the users perspective.
Summary of this scenario:
DKB500:[000DSK]D100.DSK ! LD container file for mirroring DKB100: This will be LDA100:
DKB500:[000DSK]D200.DSK ! LD container file for mirroring DKB200: This will be LDA200:
DKB500:[000DSK]D300.DSK ! LD container file for mirroring DKB300: This will be LDA300:
DKB500:[000DSK]D400.DSK ! LD container file for mirroring DKB400: This will be LDA400:
DSA100: (DKB100) ! normally only a single member.
DSA200: (DKB200) ! normally only a single member.
DSA300: (DKB300) ! normally only a single member.
DSA400: (DKB400) ! normally only a single member.
Initial copy (one at a time to reduce contention on DKB500) This will take much longer than mini copies with WBM.
Add LDA100 to DSA100: mirror and wait for normalization. When complete, create WBM for DSA100 and remove LDA100:
Add LDA200 to DSA200: mirror and wait for normalization. When complete, create WBM for DSA100 and remove LDA100:
Add LDA300 to DSA300: mirror and wait for normalization. When complete, create WBM for DSA100 and remove LDA100:
Add LDA400 to DSA400: mirror and wait for normalization. When complete, create WBM for DSA100 and remove LDA100:
Before backup, but during period of low activity on system:
Add LDA members back into shadowsets using the WBM so only modified segments are copied. If multiple LD devices will be members of shadowsets at the same time, wait until previous members have completed copy before adding the next. This is to reduce contention on the common DKB500: which hosts the LD devices.
When all members are normal, initialize WBMs.
Quiess system, remove LD snapshots (specifying WBM)
Mount LD devices readonly.
Continue processing. Backups can be done at any time, as long as they are complete before the next cycle. Note that verify can be done, as the LD devices are not changing.
The LDA device will not be returned to the shadowsets until just before the next snapshot is taken. We are not using shadowing for redundancy, we are using it for point-in-time copies.
Note that with this scenario, you will have an "online" readonly copy of the data that is on the most recent backup; the readonly LD devices. Very easy for users to restore their own files (file protections are just like the real copy). And you have one day's worth of "tape protection". I.e. if you come in to find there was a tape parity error, or the tape filled, etc., you can just start backup over again. The data is still the same.
I will now let the experts that actually use Host Based Volume Shadowing chime in.
Oh, you will need to be running a recent version of VMS for this to work with WBM optimizations.
RE: By the way, how do you find new messages to respond to?
The notes with the latest activity float to the top of the list.
Have fun, and welcome to the forum.
Jon
it depends
