🚀 go-pugleaf

>1) Nobody on this list in interested in this topic.  I find this hard
....
>2) Nobody is providing disaster recovery for VM/Archive.  Based on
....
>Which one is it?

At our site we are not taking Archive twins offsite.  It would be a good
thing to do someday but we will probably never take them offsite every day.
We currently have a scheme where we close tapes every three days and then
Merge/Purge them together, in order to optimize tape usage - our VMARCH
usage is so variable that we couldn't figure out a good DSSLIMIT (to avoid
both nearly-empty tapes and continuation reels) any other way.  It took a
while to get that set up and we are still fine-tuning it.  I suppose we
might be able to work offsite twins into this scheme but I agree that the
product is not exactly designed for that.  If you are going to start doing
routine Merge/Purges for combining tapes, bear in mind that it wants an
expired file in the set somewhere or it won't change the database.  At least
that's how it worked when we set up our Merge/Purge scheme, and we have a
VMSCHEDULE job that archives dummy files with very short retention periods
just to take care of this.

You said they told you to mark the twins missing.  I don't know if it is
related, but it reminds me of the situation where we had to set up VMBACKUP
to only do one recall at once so that it would not wind up insisting that
a (vaulted) VMBACKUP twin tape be mounted.  I think it would be nice if
Systems Center would have configuration options in VMBACKUP and VMARCHIVE to
say "Don't call for twins on recalls until further notice".

We have heard that they are reworking VMARCHIVE so we are waiting to see what
the next one looks like.  VMBACKUP 5.1 was certainly a world apart from
VMBACKUP 4.2.

Margaret King
Michigan State University