Solved

Physical CV 9 commserve being P2Vd into vmware; its media agent can no longer mount it disk storage

  • 22 April 2021
  • 9 replies
  • 108 views

Badge +3

We have a physical server running CV 9 that we, unfortunately, need to keep running. In an effort to protect ourselves as much as possible, we have P2V’d that server into vmware. When the VM came online, I was able to recover backed-up data from its media agent… but when I tried to backup NEW data to that same media agent, I got an error: “Failed to mount media [name] with mount path [location] on media agent [MA name]. Folder1 already exists. Choose a new mount path.” Or something very like that. The mount paths on the media agent are its drives E, F, and G.

That media agent had been working fine on the physical server.

I don’t really understand why this problem should exist simply because we’re using a VM now.

I’m happy to answer any questions about this machine. I’m hoping someone may have a clue as to why recoveries work, but backups don’t.

 

icon

Best answer by ShawnH 29 April 2021, 19:33

View original

9 replies

Userlevel 7
Badge +23

Hey @ShawnH , questions on those mount paths….are they local drives (now virtual) or were they mounted from a NAS or something?

I’m wondering if the drive letters got mixed up.

Badge +3

Thank you for your willingness to engage on this!

So… the media agent is, in fact, a VM. Its library is made up of locally mounted drives. This storage works fine for both backups and restores on the physical commserve. When we brought up the VM commserve, it still saw the VM media agent, which looked the same (drive-wise) in the GUI, and I was able to recover data from it; backups, however, wouldn’t work.

When I posted my question, I forgot to mention that I would see ANOTHER error message after a short while, something about the DDB having a problem. I regret not writing that down. What I SHOULD have done was to try a backup without using dedup, to see if that would work… but I didn’t think of it in time.

We have moved back to the physical server, while we puzzle over what went wrong, and everything is working as before.

I think what we’ll try NEXT time is to STOP CV on both the commserve and the media agent, and THEN sync or redo the VM, and then try again.

I will report progress here.

Thank you, again.

 

Userlevel 6
Badge +14

Hi @ShawnH,

 

Inside the VM CommServe’s CommCell Console it may have been worth checking the Events.
- I suspect that the DDB May have needed Re-Synchronization.

You might see in there it re-tries every 15mins, If the Re-Sync failed then that would cause DDB offline. - Check the SIDBEngine.log if it did, for any related errors. 

 

Best Regards,

Michael

 

Userlevel 7
Badge +23

Thank you for your willingness to engage on this!

So… the media agent is, in fact, a VM. Its library is made up of locally mounted drives. This storage works fine for both backups and restores on the physical commserve. When we brought up the VM commserve, it still saw the VM media agent, which looked the same (drive-wise) in the GUI, and I was able to recover data from it; backups, however, wouldn’t work.

When I posted my question, I forgot to mention that I would see ANOTHER error message after a short while, something about the DDB having a problem. I regret not writing that down. What I SHOULD have done was to try a backup without using dedup, to see if that would work… but I didn’t think of it in time.

We have moved back to the physical server, while we puzzle over what went wrong, and everything is working as before.

I think what we’ll try NEXT time is to STOP CV on both the commserve and the media agent, and THEN sync or redo the VM, and then try again.

I will report progress here.

Thank you, again.

 

I was actually going to ask if any services were running or jobs in progress, etc. :grin:

I think between this and what @MichaelCapon is saying, that’s what happened.  The Ma was not in sync with what was expected…..restores worked because the required files were there, but laying down anything new was a problem because of the DDB being out of sync.

How soon do you plan to retry?

Badge +3

Thank you both!

How soon to retry? Probably not until at least next week. I’m not sure if the PTB will make us go through another RFC approval. I guess we’ll see about that.

I will provide an update as soon as something changes.

Thanks, again.

 

Userlevel 7
Badge +23

Sounds good; I’ll keep an eye out for your update!!

Badge +3

We did the P2V again, and the sync, this time with the CV services down… and it all worked like a charm!  Our CV 9 commserve is now a VM, and we have verified both backups and restores, including restores from just prior to the P2V.

My thanks to everyone who weighed in on this issue.

 

Userlevel 7
Badge +23

Awesome news!!!!  Very glad to hear you now have a viable solution :sunglasses:

Userlevel 7
Badge +19

A question just out of curiosity. Why are you still running CV 9?

Reply