Forum Discussion
Hi guys,
Thanks for your reponses.
BENT, Sorry... I've been using Backup Exec since the days of Arcada (pre Seagate/Veritas and Symantec) and ironically, the acronym seems to fit better with 2012 (sorry, couldnt resist that one)!
I am aware of the way in which, BEWS and BENT before it, works with tape media that is overwrite or append protected. My issue is as follows:
1. BEWS detects the media as not being suitable for the current backup type of the job currently running. This can be because of operator error, allocating a tape to the wrong media pool. Or, in my specific case, this appears to have been the job engine, somehow, allocating the blank (scratch media pool) tape to a media set that is overwrite protected, before it started to write the data for the backup job, thereby locking iteslf out from using the blank tape).
1.2. As BEWS has detected the media issue it issues a media removal alert and ejects the tape. A little point aboput this alert is that it can be acknowledged or cancelled.
Hmm... If there is only one outcome then "Cancel" is pointless and this alert should only be acknowledgeable... Unless the cancel option gives us a chance to remediate the issue with the media and save the backup job (see below)!
3. My issue is that because it has ejected the tape, in an unattended backup scenario, the remote operator is not able to remediate the incorrect tape media set association, until somebody attends the site to push the tape back in. Thereby making proper unattended operations not possible.
4. This situation would be better handled as follows:
4.1. BEWS detects the media as not being suitable for the current backup type of the job currently running.
4.2. BEWS issues a media removal alert, but does not eject the tape yet.
4.3. The remote operator now has a chance to take a look at the media properties and ensure the media is either associated with the correct media set or ejected. If the tape is to be ejected the operator acknowlegdes the media removal request and the tape is ejected.
4.4. However, if the tape can simply be allocated to the correct media set, the operator can cancel the media removal request and the backup job can continue.
Hooray!
The key think here is that, all that needs to happen is the tape eject should not be made the default behaviour, as there is no benefit to this. Media set protection has done it's job and paused the job awaiting input from an operator. If the tape is not ejected the job can be recovered remotely. All that Symantec developers need to do is simply move the event of the tape being ejected, from a default state, regardless of what's going on, to something that only happens when the operator acknowledges the tape to be removed. Simple really...
PS: Just because something has always been or behaved the same, does not mean it is right or cannot be improved upon. If this was the case we would all still be running around in furs clubbing eachother on the head.
Related Content
- 2 years ago
- 10 years ago
- 11 years ago