Restoring files with a robotic library in 10 (and before) sometimes requires importing media not in the changer. Once you import the new media, you need to inventory the changed slots of the library; however, the inventory request will not execute - it gets queued because there are no devices free to do the inventory: The device in question is busy performing a restore.
So far, the only two workarounds I've found are as follows:
1. Cancel the restore, then inventory the slots with changed content. 10 makes this easier, since it saves all the job specifications, allowing me to rerun it without much difficulty; however, this means any restore progress is lost, and the procedure must be restarted from the beginning.
2. Anticipate which media will be required for the restore, and import and inventory all of them before even running the restore. While this option is quite feasible, it strikes me as a primitive solution.
If the restore requires more media than will fit in the changer, neither workaround will work. In such a situation, the restore must be segmented into several restores, and perspicaciously sequenced.
What I expect Backup Exec to do in such a situation is hold the restore, and make the device available for executing the inventory. In fact, since Backup Exec requested that the new media be inserted into the changer, and actually doing this always requires the slots to be inventoried, it would be rather nice if there were a single, compound function, Swap Media for Restore, which would execute on the selected slots. This function would perform the following steps on the set of slots:
1. Export slot set
2. Import slot set
3. Inventory slot set
...after which, the restore could continue seamlessly, with minimal user interaction and time consumption.
Is there already a clean way to deal with this scenario?
Am I stuck using my time-wasting workarounds?
Can I look forward to the implementation of an elegant feature like the one I suggested?
Thanks!
