Migrate B2D Target / Change drive letters

[M_Strong]

Good day,

As a part of a larger hardware migration/upgrade, we have the opportunity to provide our BE server with additional B2D target space on an additional iSCSI LUN, however we also wish to reclaim the LUN on which the current B2D target(s) volumes are located.  (This is all in vm-space, so I have some flexability here)

Currently we have a 600 GB LUN dedicated to B2D target volumes, due to logical size constraints with earlier versions of vmfs, we were forced to split the LUN up into 3 - 193 GB volumes which were presented to the Windows server on which BE is running and from there 3 B2D targets were created.  Having added physical storage capacity, I now have a ~1 TB LUN that I would like to dedicate to B2D storage and reclain the previous 600 GB LUN which is on a different physical array that we want to re-dedicate to another purpose.

That said, I'd like to accomplish this with the least amount of reconfiguration possible.  I'm thinking that I can do something similar to the following:

Stop all BE services
Create/presenet/configure additional volumes to the Windows Server from the new LUN
Copy/xcopy all data from the existing B2D volumes to the new volumes - (including existing backup job set files and the B2D configuration folders)
Swap drive letters so that the new B2D volumes have the same drive letters that the previous B2D volumes had
Restart BE services

The advantage I'm hoping for here would be that I shouldn't have to reconfigure any of my backup jobs, they should all continue to the designated B2D volume - since the job's target does not indicate the drive letter, but the B2D target name given to BE when the target is created.
The only downside that I can think of would possibly be the storage statistics might be out of whack as they were built on smaller volumes, but those should correct themselves over time.
As long as BE identifies the B2D targets that have been conifgured by way of the Windows drive letter, I don't see why this shouldn't work.  If BE identifies the target by some hardware ID or GUID,than this might not work.

Any thoughts?

Thanks,

[CraigV]

Check the TN below...it should help you with the steps:

https://support.symantec.com/en_US/article.HOWTO22738.html

Thanks!

[Colin_Weaver]

The article quoted by Craig is slightly out of date (both by Product version and when it was written)

The method you are considering is probably a better idea, especially if you have incremental or differential GRT backups, as the links between the incremental or differential sets and the previous sets in the same chain back to the full are coded by drive letter and if you change the drive letter it can break the links and result in inability to restore from the existing older GRT sets (Note: non-GRT sets should not have this problem.)

The only thing that slighly concernes me is whether we use the volume GUID and the drive letter (which we do against USB disks) and as such it might still be seen as a new B2D folder. If this is true then using Craig's method but changing the drive letter afterwards may be more sucessful.

[M_Strong · Accepted solution]

So just to provide an update on this project and in case anyone else is looking to accomplish the same operation - in short, it didn't work as anticipated, so save yourself the time.

I went through these steps:
--Shutting down BE services;
--Creating the additional volumes (partitions) in Windows
--Xcopying all data over from the current volumes to the new volumes
--Changing the drive letter on the existing B2D targets to free up the drive letters that are known by BE
--Set the new volumes to the same drive letters known by BE
--Fired up BE services and BE GUI

(When Xcopying, it helped to use the Exclude switch in xcopy to filter out copying of [recycle bin] and [system volume information] folders - the first volume I xcopied failed on system volume information folder and hosed up the permissions on the root of the volume which had to be fixed manually.  In the end none of this made any difference as I ended up having to blow the partitions away completely from within Windows storage manager and recreate the partitions before the BE storage configuration wizard would even see the new volumes for addition to the storage resources.)

Afte all that, BE recognized the changed drive letters and kept right on going as if nothing had happened.  The properties page of the existing B2D volumes reflected the new drive letters, so BE is smarter than I thought.  In retrospect, the XML file in the BEControl folder of the B2D target volume keeps a thumbprint / guid of the volume for reference purposes which is probably how it found the volumes despite the drive letter changes.  Xcopying the data to the new volumes without making the old volumes unavailable before firing up BE again didn't cause BE to see the new volumes as it's B2D targets.  I didn't want to make those previous B2D targets immediately unavialable in case the operation failed for some reason as I had current backup sets on those volumes.
In fact, it ended up confusing BE a little bit that multiple volumes had the same guid as when I attempted to add the new volumes to storage resources, the configure storage wizard was displaying incorrect data about the volumes that were avialable and even included some (but ont all) of the voumes that were existing B2D targets as if I could re-add them as new B2D targets.
After that, the configure storage wizard couldn't see the new volumes at all, even after re-formatting them to wipe out what I had xcopied over from the existing volumes it was if they didn't exist even though I could see and browse them using Windows explorer.

So, back to square one:  I shut down BE services again, deleted and recreated the entire partition on each of the new volumes so that Windows had a fresh GUID on each of them, assigned drive letters, fired up BE services and the GUI and immediately ran the Configure Storage Wizard.  This time it saw the new volumes and I just went through setting them up from scratch.
Then I had to adjust all of my backup jobs to point to the new B2D target(s) - which was the singular step I was trying to avoid by way of this operation.  Set the to-be-retired B2D volumes as offline in the BE GUI and waited to see that backups would target the new volumes correctly - which they did.

So, long story short - just add new storage targets from scratch and retire the old ones manually.  If I had made the old volumes unavailable before firing up the BE services again, BE might have recognized the new volumes, however I would have a concern about how BE might react to the the volume size suddenly changing, whether or not that would cause additional problems.

Thanks again Craig, Colin for the feedback and suggestions.  Hope this experience helps someone else avoid wasting time and effort.