Skip to main content
Question

Error - The medium is already reserved by some other job on VSA restore

  • October 28, 2024
  • 2 replies
  • 238 views

Forum|alt.badge.img+4
  • Byte
  • 13 replies

Hello,

I am trying to recover a backup of a client VSA virtual machine from a secondary copy that was copied to tape approximately 5 years ago.

The index version of the VSA client is V1 (I plan to migrate this VSA client to V2 next month. It’s the last client I have left to migrate). The Commvault version is 11.36.24

The restoration I am performing is for the entire virtual machine.

When attempting to restore, I get the following error message: "The medium is already reserved by some other job. 

We rarely perform tape recoveries, and what surprised me while researching is that this type of error seems usually appears in multi-stream database recoveries, but there’s no mention of VSA clients.

You can see information here:
https://kb.commvault.com/article/53924
https://documentation.commvault.com/11.20/combining_source_data_streams.html

Before open the case (#241023-299), I tested different restorations. Also checked that no other job is using this media. We even restarted the library and the media to clear any possible SCSI reservations before run the restore again.

When reviewing logs, I see the following: 

Also:

The first engineer who reviewed the issue mentioned that the error "62:348 - The medium is already reserved" is technically not an error, and in part, he is “correct” because the job doesn’t remain in a “Pending” state; it stays in “Waiting”. However, the restore doesn’t complete, likely due to reservation and waiting errors, as seen in the logs.

The case is still open. 

Has anyone else encountered this issue when restoring a VSA client job from a tape copy?"

===========================================================================

Additionally, I want to provide details about my infrastructure to align with the information in this KB: https://kb.commvault.com/article/53924

My tape library has 4 drives. The configuration I have for the secondary copy is as follows (I believe that 5 years ago, the multiplexing value was set to 25, now is 9, but we have always had 4 drive tapes).

 

Storage policies usually have the following copies:

- The Primary copy is a combination of IntelliSnap for VMware + BackupCopy.
- Primary is stored in the disk library at the HQ site.
- Then, that first copy is copied via aux-copy to the DRP site.
- On the weekend, selective copies (week, month, annual) are written to tape (if they are eligible).

 

 

This is a Storage Policy for VMware, but I use the same pattern for other Storage Policies like HANA, DB, etc; when multiplexing and launching aux-copies against the same secondary copy (according to retention), the tapes often contain a mix of different types jobs: VMware, HANA, DB, etc.

===========================================================================

Tomorrow, I will provide more information about the different restore tests I have performed and their results.

2 replies

Forum|alt.badge.img+4
  • Author
  • Byte
  • 13 replies
  • October 31, 2024

The support engineers are still analyzing the logs. These are the restores I have been testing on my own.

 


Forum|alt.badge.img+4
  • Author
  • Byte
  • 13 replies
  • December 27, 2024

Update:  Set the AdditionalKey “UseSingleArchiveReader” on VSA Access Node. The restore (slow, obviously) was successful.

 

Still working with Commvault Support...


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings