Skip to main content

Good day all

This one is a bit complicated, so will try keep it as brief as I can.

The customer has a faulty storage device with the backup data on it.
They’ve received a loan VAST unit which uses it’s own deduplication engine in addition to the Commvault dedupe in place.
 

We would like to turn the Commvault deduplication off as we’re having errors on the DDB which may require us to seal it.

The concerns I have are below, and I’m hoping to get some clarity on it.

The faulty storage and VAST storage are in the same Data Centre (DC1).
We want to turn DDB off in this DC and do a Move Mount Path(s) from the faulty storage to the VAST.

At the same time, new backups are running to the VAST device on different Mount Paths.

When this is all complete and the faulty storage is replaced (it won’t have it’s own DDB capabilities, so Commvault will handle that), we will move the VAST Mount Paths back to this storage.

With Commvault DDB off, does non-deduplicated data get deduplicated during a ‘Move Mount Path’ operation by Commvault if DDB is enabled prior to the operation?

Following on from this, we have backup data in another Data Centre (DC2).

The Aux copies from the VAST will need to make a secondary copy to DC2, and DC2’s backup data makes a secondary copy to DC!1 (VAST).

With no deduplication enabled in DC1 (VAST) does the DASH copy option handle deduplication regardless if it’s enabled on the storage?

I hope this makes sense.

Thanks,
Mauro

Hey @Mauro !

I have another suggestion that might be easier:

why not just set up an Aux Copy to the VAST storage, let it complete, promote it to the Primary, then get rid of the faulty storage copy (once you feel safe doing so)?

This should get around your concerns about moving mount paths.

Regarding the DASH copy, the dedupe is handled for that copy, regardless of what happens on the primary.  It has its own DDB and everything.


Hey @Mauro !

I have another suggestion that might be easier:

why not just set up an Aux Copy to the VAST storage, let it complete, promote it to the Primary, then get rid of the faulty storage copy (once you feel safe doing so)?

This should get around your concerns about moving mount paths.

Regarding the DASH copy, the dedupe is handled for that copy, regardless of what happens on the primary.  It has its own DDB and everything.

Hi Mike

Thanks so much for this suggestion.
I’ll be going this route rather as we’re having issues moving mount paths the traditional way at the moment. Not sure what the cause is, but happier to just move everything via an Aux copy.

I’m leaving the thread open momentarily as I have another issue on this.

I know SMB shares are the recommended option for Windows Media Agents. We’re experiencing disconnects and the customer is unable to pinpoint the issue.
We not seeing the disconnects with NFS, but I know it’s not recommended on Windows.

How big an issue could I face if I use NFS to move this data? It will be on the VAST for 2-3 months and then will move back to it’s original storage which is directly connected.

Thank you again.

Regards,
Mauro
 


@Mauro , when you say use NFS to move the data, are you meaning to not have CV do the copy at all, or use NFS as a destination?

Want to be sure I’m framing any reply properly :nerd:


@Mauro , when you say use NFS to move the data, are you meaning to not have CV do the copy at all, or use NFS as a destination?

Want to be sure I’m framing any reply properly :nerd:

Hi Mike

Sorry for the vague question.
So Commvault will do the move to an NFS share.(destination) using a UNC path.

Thanks.
Mauro


The destination should be rather agnostic, though I’m more concerned about the disconnects.  You will see errors in the Aux copy if the library connection is not reliable.


Hi Mike

Just want to update you with our progress. 
We’re running data verification on the jobs specifically, as we know there is corruption there. Once complete and we can exclude failed jobs, we’ll commence the move.

Will update on progress once we get the Aux Copy running.

Thanks again.


Please do, @Mauro !  Thank you for keeping us posted!


Reply