Migrating B2D disks to new storage system

[YonatanC]

Hi, Here's my scenario: - We have a Backup Exec 2010 R3 SP4 Media Server installed on a Cisco UCS blade as a Windows 2008 x64 machine. - We have a Netapp 3270 storage system. - The Backup Exec system disks (c: system, d: data, e: page file) are all SAN volumes on the storage, presented to the OS as RDMs so the machine is configued to boot from SAN. - We also have 4 other volumes on the NETAPP dedicated for B2D (3 volumes for daily incremental backups and 1 volume for weekly full backup). - All the b2d volumes are presented to the OS as local disks. - Out daily backups are kept for one week and are than overwritten (Backup job option set to overwrite). - Our weekly backups are also kept for one week and are overwritten the next weekend (Backup job option set to overwrite). We're now in the process of migrating to a new Netapp FAS8040A storage system. For the system disks we're using a script provided by netapp which will transfer the volumes to the new storage automatically. For the B2D volumes, we do not want to transfer them all to the new storage as they are pretty big and it's time consuming. Instead, this is what we're planning: 1. Stop the BE services. 2. In the OS, change the drive letters of the current B2D disks. 3. Create 4 new volumes on the new storage and present them to the OS with the drive letters of the old disks. 4. Create the relevant folders on the new disks, as they were on the old disks. 5. Start the BE services. 6. The BE won't feel the difference and will actually backup to the disks on the new storage. I guess that in the GUI I'll see all the B2D files as not present (with the "minus" icon on them)? 7. In case we'll need to restore we'll just Inventory the folders on the old disks. 8. After a week it will be safe to delete the old volumes completely. Is there anything I'm missing in this plan? Thank you

[Colin_Weaver]

1) If you have GRT enabled backup sets (especially if using Incremental backups involving GRT) then changing the drive letter of the disk storage after the backup may give a problem restoring from those sets and you might hjave ot oput the original drive letter back (tempoirarily) to do GRT restroes. Possibly OK for just temp cover for a week but somethign you do need to be aware of.

2) Make sure you restart all incremental and differential jobs with a new sequence starting tiwth a full backup (especially if GRT is enabled) when you start using the new drive so that nothing tries to link itself to the original sets on the original drive letter.

3) You will probably have to create a new b2d device on the new disk and then retarget your backup jobs as we don't just store the drive letter of the B2D volumes, we also store GUID type identifiers and adjust the drive letter should we find that the identifier is linked with a different letter.

[YonatanC]

Hi Colin, I'll start with no. 3: Let's say the current drive letter is H: I have two folders on drive H: - "h:\DailyBackup" and "h:\DailyBackupGRT". You're saying that if I just change this drive letter to X: for example, and present a new drive to the OS with the letter H: and create the exact two folders on it, it still won't work in BE? I will have to create new b2d devices and link them to the new H drive? And is there a way to retarget a large amount of jobs at once? No 2.: I don't quite understand why would something try to link itself to the original sets on the original dirve letter. and even if so, the new drive letter is the same as the original so why would that be a problem? Anyway, we have a lot of backup jobs running every night (more than 100) and we only backup fully on the weekend (Fri+Sat). So if I'll make the switch on Sunday morning, than a new incremental cycle will start that night and it'll be fine? No. 1: I do have GRT enabled backup sets. I'll keep that in mind.

[Colin_Weaver]

For 3:

You can test this. With your B2D still set to H: sto[p all the Backup Exec services.

Use Windows Disk Manager to change teh drive letter to say J:

Start the BE services and open the BE console

You will probably find that after a few minutes the B2D devcie comes onlien and if you look at teh peroperties you wil see that teh drive letter has changed.  Obviously oput this back after you have done this test.

What this shows is that if you change the drive ltter BE will know it is the same B2D and if you do not edit the jobs that will just write to the new drive letter and that tro use the new drive you would have to cerate a new B2d and retarget the jobs.

The only way I know of to retarget the jobs in a block is to setup the new B2d and then in the beconsole delete the old B2D which will then prompt for what you want to do with the jobs that use it, although it is possible you could do something with BEMCLI scripting.

-----------

For 2: I kind of have to give miore info against 1 first

What I am saying is that if you do you full backup of a GRT enabled set to H:\B2DGRT

That it will create something like

H:\B2DGRT\IMG0005\<a number of files>

and if an incremental of the same source data is then also run it might create

H:\B2DGRT\IMG0008\<a number of files>

As part of the content of the files created within IMG0008 there are config records that link directly back to IMG0005 and these config recoreds use the full path including the drive letter

If you then change the drive letter these config records will point to the wrong drive letter causing problems for the GRT restore from the incremental (although you wil probably still be able to restore from the full.

This does not affect none GRT (bkf file) content as this is purely handled by catalogs and the media inventory and not linked to drive letters

Now to explain 2 - If your full is still on the old drive and your incremental is on the new one there will be a link as defined above. Hence the recommendation to run full jobs to start this change of drives.

[YonatanC]

Thanks for the detailed explanation. So, if I'll create a new b2d device on the new disks I will then need to delete the old b2d device and all the corresponding jobs will be redirected to the new device. This won't delete the backup files themselves that are on the old disks, correct? Also, there's actually no need to keep the original drive letter since I'm creating new b2d devices and redirecting all the jobs anyway, isn't it? In case I will need to restore from them, I will just need to create a new b2d device from the old disks and run an inventory on them, is that correct?