Video Screencast Help

Migrating from Veritas Storage Foundation Volume to Windows Disk

Created: 15 Jul 2013 • Updated: 18 Jul 2013 | 12 comments
This issue has been solved. See solution.

We are in need to migrate off one of our current Storage Foundation system disks to Windows disks. We are building a brand new Windows 2008 R2 failover cluster and will not be using storage foundation with this cluster. The plan is to just migrate the disk from the current server to the new server on the SAN side of things. Does anyone have a good method for doing this?

 

We are using Veritas Storage Foundation HA 5.0 Rollup Path 1A.

 

Thanks for any assistance.

Operating Systems:

Comments 12 CommentsJump to latest comment

Wally_Heim's picture

Hi Mike,

The problem that you have is that disks that are managed by SFW are not accessible on servers without SFW installed.  In order for you to move to non-SFW managed disks, you will need to backup and restore the data if you plan to use the same disks. 

If you are going to use different disks, then you can copy the data from the SFW managed disks to the new disks on the same server or on a different server.  The thing to keep in mind when using this approach is to use the correct copy program and syntax to maintain NTFS level permissions as needed for your situation.

Thank you,

Wally

SOLUTION
mikej1983's picture

I remember somewhere that there was a method for doing this with SFW. Something to do with presenting a new disk and then using SFW to basically do a sync to the new disk. The new disk won't have a SFW signature at that point. I have yet to be able to find the step by step instructions to do this work though as it was a video that I saw a couple years back.

Wally_Heim's picture

Hi Mike,

I've been working with the Windows version of this product for over 12 years now and this has never been possible for the Windows product.  Once the disk is included in an SFW Dynamic diskgroup, a system without SFW will not be able to import or access the data on the drive any longer without doing operations that destroy the data on the disk.  This is why a backup/restore or a file copy to non-SFW dynamic disks is recommended.

Thank you,

Wally

mikej1983's picture

Wally

For the backup/restore route. For our case we have several concatanated disks that create a 1TB LUN on the server. Would we then just present another 1TB disk to the server we want to migrate it to and then restore it there? Or is there some other steps we would need to work through.

Wally_Heim's picture

Hi Mike,

if you have storage available that you can present then I would use xcopy or robcopy to move the data from the SFW volume to the new disk or disks.  I would do things this way so that you have the original disks available if needed until you validate that your data has all been moved without issues.

You can use a single 1 TB disk with a basic partition on it or you can use multiple disks in a Windows compatible disk group with a volume made up of the multiple disks.  its really your call.

Windows compatible disk groups (Logical Disk Manager) can be accessed once SFW is uninstalled.

Thank you,

Wally

mikej1983's picture

Would it be possible to mirror using Veritas SFW without writing the Veritas signature to the newly presented disk?

Wally_Heim's picture

Hi Mike,

Sorry, SFW can only mirror to disks that are in a SFW dynamic diskgroup.  If you add the new disks to the disk group and mirror then you will still not able to access the data on the new disks once SFW is uninstalled.

Thank you,

Wally

mikebounds's picture

This is possible in UNIX, but it looks more complicated in Windows.  In UNIX this relies on the following 3 properties:

  1. The Veritas Volume is on contiguous space on a single disk
  2. You are able to create a native O/S partition in exactly the same position as the volume
  3. The deletion and creation of Veritas volumes and native O/S partitions does not change the data - i.e when you delete the volume or partition, the data remains intact and you are just removing the information in the private region or MBR  about where the volume resides on disk.

The problem on Windows is that point 3 does not seem to be true which is surprising.  So for instance in the simpler instance if you just delete a volume and then recreate (without formatting) then Windows Explorer says the volume is not formatted and the same is true of deleting and recreating a partition.  So I don't why the data region is been affected, but it maybe that Windows THINKS it is not formatted when it actually is - i.e maybe there is some flag in the private region/MBR that dictates if the data is formatted.

If 1 is not true then you can get round this my mirroring volume onto contiguous space on a single disk in UNIX and Windows

2 is possible in Solaris using tool mksdpart and is possible in Windows, in theory, if you:

  1. Add a new disk to the system the same size (actually slightly larger) as SFW volume
  2. Create a partition on the disk the same size as volume in SFW,
  3. Add the disk to the diskgroup which converts partition to a volume. 
  4. Check converted volume is exactly the same size in sectors as the volume in SFW and if it isn't then grow original volume (not converted volume) so it is the same size in sectors
  5. Delete converted volume
  6. Mirror volume in SFW to the now empty disk
  7. When mirror is synced, stop access to the volume (i.e stop apps and users writing to it) and then break mirror
  8. Delete the volume on your new disk that was created when breaking the mirror
  9. Remove disk from the diskgroup
  10. Create partition on the disk as in step 2

This is quite convoluted, but it you could get point 3 to work, then this would quicker then copying the data for very large filesystems like the 1TB filesystem in your case. 

There are bound to be tools about to help you recover from a deleted partition, so you MAY be able to get this to work - it depends on how important it is to reduce downtime for converting your SFW volume to a partition

Mike

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

Wally_Heim's picture

Hi Mike and Mike B.,

The process that Mike B. outlines will not work on Windows and will result in the loss of all access to your data.  The act of creating a volume or a partition in Windows erases part of the volume that is used for the file allocation table.  The end result will be a completely blank volume.

This process/operation is not recommended by Symantec due to the data loss potential.

Thank you,

Wally

mikebounds's picture

I found my process does work if I use a utility to restore the MBR.  I used Mbrfix which is recommended at https://www-secure.symantec.com/connect/blogs/how-backup-and-restore-mbr  for backing up your MBR  and I did a test saving an MBR before and after formatting a partition and the saved files were different which seems to verify my earlier thought in my last post that the MBR contains some flag to signify the partition is formatted.  As my process restores the MBR, I don't do the act of creating a partition so it looks as though no part of the volume is erased.  

However this is a low-level process, and almost certainly won't be supported by Symantec, but this process does not change the original data, so there is no risk of corrupting or loosing your original data, but it is up to you to validate the "partition copy is the same as the original SFW volume and there is no loss or corruption on the copy.

Here is the output of the process run on my VMWare setup running SFW 5.1 on Windows 2003:

I have a SFW volume "sfw_vol" concatenated on 2 disks as follows:

 

O:\>vxprint -g dg1

Diskgroup = dg1
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
sd Disk1-01     sfw_vol-01   ENABLED  94208    0        -        -       -
sd Disk2-01     sfw_vol-01   ENABLED  94208    0        -        -       -
dm Harddisk10   Disk2        -        415681   -        -        -       -
dm Harddisk9    Disk1        -        16771797 -        -        -       -
dg dg1          dg1          -        -        -        -        -       -
v  sfw_vol      -            ENABLED  188416   -        ACTIVE   -       -
pl sfw_vol-01   sfw_vol      ENABLED  188416   -        ACTIVE   -       -
 
Step 1: Create a partition on a new disk of the same size (in sectors) and format with the same filesystem that is on your SFW volume:
 
O:\>vxassist create_part Harddisk11 188416s DriveLetter=N
Created NT Partition \Device\Harddisk11\Partition1
DriveLetter N assigned to the volume

O:\>format /FS:ntfs /Q N:
The type of the file system is RAW.
The new file system is NTFS.

WARNING, ALL DATA ON NON-REMOVABLE DISK
DRIVE N: WILL BE LOST!
Proceed with Format (Y/N)? y
QuickFormatting 94M
Volume label (32 characters, ENTER for none)?
Creating file system structures.
Format complete.
     96358 KB total disk space.
     94085 KB are available.
 
Step 2: Backup your MBR
O:\>MbrFix /drive 11 savembr z:\harddisk11.mbr
 
Step 3: Add disk to diskgroup:
O:\>vxdg -g dg1 adddisk Harddisk11
Successfully added disk(s) to the dynamic disk group dg1
 
You can now see I have new 3rd disk and new volume "Volume1" in my diskgroup which still contains N: drive which has no files
O:\>vxprint -g dg1

Diskgroup = dg1
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
sd Disk1-01     sfw_vol-01   ENABLED  94208    0        -        -       -
sd Disk2-01     sfw_vol-01   ENABLED  94208    0        -        -       -
sd Disk3-01     Volume1-01   ENABLED  192717   0        -        -       -
dm Harddisk10   Disk2        -        415681   -        -        -       -
dm Harddisk11   Disk3        -        206785   -        -        -       -
dm Harddisk9    Disk1        -        16771797 -        -        -       -
v  Volume1      -            ENABLED  192717   -        ACTIVE   -       -
pl Volume1-01   Volume1      ENABLED  192717   -        ACTIVE   -       -
dg dg1          dg1          -        -        -        -        -       -
v  sfw_vol      -            ENABLED  188416   -        ACTIVE   -       -
pl sfw_vol-01   sfw_vol      ENABLED  188416   -        ACTIVE   -       -

O:\>n:

N:\>dir
 Volume in drive N has no label.
 Volume Serial Number is 0470-43D5

 Directory of N:\

File Not Found
 
Step 4: Check new volume is the same size, which in this case it is not as SFW volume is 188416 and new volume is 192717 which is slightly larger.  If new volume is larger, then increase size of SFW volume by the difference (4301 sectors in my case), but you must NOT change the size of the new volume.
O:\>vxassist -g dg1 growby sfw_vol 4301s
Successfully extended volume \Device\HarddiskDmVolumes\dg1\sfw_vol

O:\>vxprint -vg dg1

Diskgroup = dg1
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
v  Volume1      -            ENABLED  192717   -        ACTIVE   -       -
v  sfw_vol      -            ENABLED  192717   -        ACTIVE   -       -
 
Step 5: Remove new volume:
O:\>vxassist -g dg1 remove volume n:
Successfully deleted volume / drive \Device\HarddiskDmVolumes\dg1\Volume1
 
Step 6: Mirror SFW volume on to new disk
O:\>vxassist -g dg1 mirror sfw_vol Harddisk11
Added mirror to the volume \Device\HarddiskDmVolumes\dg1\sfw_vol
 
Now you can see that the mirrored data in plex sfw_vol-02 is in a subdisk (Disk3-01) which is in exactly the same location and is exactly the same size as the volume that was upgraded from the partition - i.e it is at offet 0 at the beginning of the VM disk
O:\>vxprint -g dg1

Diskgroup = dg1
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
sd Disk1-01     sfw_vol-01   ENABLED  94208    0        -        -       -
sd Disk2-01     sfw_vol-01   ENABLED  98509    0        -        -       -
sd Disk3-01     sfw_vol-02   ENABLED  192717   0        -        -       -
dm Harddisk10   Disk2        -        415681   -        -        -       -
dm Harddisk11   Disk3        -        206785   -        -        -       -
dm Harddisk9    Disk1        -        16771797 -        -        -       -
dg dg1          dg1          -        -        -        -        -       -
v  sfw_vol      -            ENABLED  192717   -        ACTIVE   -       -
pl sfw_vol-01   sfw_vol      ENABLED  192717   -        ACTIVE   -       -
pl sfw_vol-02   sfw_vol      ENABLED  192717   -        ACTIVE   -       -
 
Step 7: When mirror is synced, if you are doing this for real, then you should now stop your app as the next step is to break the mirror, so I am simulating this by just creating a file
O:\>echo "App shutting down" > file2.txt
 
You should also run some verification of your data, so you can check it afterwards
O:\>dir
 Volume in drive O has no label.
 Volume Serial Number is 6003-3684

 Directory of O:\

18/07/2013  14:17                39 file1.txt
18/07/2013  14:42                22 file2.txt
05/08/2009  21:55           123,904 MbrFix.exe
18/07/2013  14:34            11,638 MbrFix.htm
               4 File(s)        135,603 bytes
               0 Dir(s)      95,962,624 bytes free

O:\>chkdsk o:
The type of the file system is NTFS.
The volume is in use by another process. Chkdsk
might report errors when no corruption is present.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
Windows has checked the file system and found no problems.

     96358 KB total disk space.
       132 KB in 4 files.
         4 KB in 8 indexes.
         0 KB in bad sectors.
      2508 KB in use by the system.
      2048 KB occupied by the log file.
     93713 KB available on disk.

       512 bytes in each allocation unit.
    192716 total allocation units on disk.
    187427 allocation units available on disk.
 
Step 8: Break the mirror
O:\>vxassist -g dg1 break sfw_vol plex=sfw_vol-02 DriveLetter=M:
Successfully broke the mirror for the volume \Device\HarddiskDmVolumes\dg1\sfw_vol
New volume name is \Device\HarddiskDmVolumes\dg1\Volume01
DriveLetter M: assigned to the volume
 
At the moment, this is a supported way to get copy of your data, but I noticed chkdsk showed one extra file and this is because when I broke off the mirror a hidden "System Volume Information" folder was created so it is probably better to run validation after breaking the mirror:
O:\>M:

M:\>dir
 Volume in drive M has no label.
 Volume Serial Number is 6003-3684

 Directory of M:\

18/07/2013  14:17                39 file1.txt
18/07/2013  14:42                22 file2.txt
05/08/2009  21:55           123,904 MbrFix.exe
18/07/2013  14:34            11,638 MbrFix.htm
               4 File(s)        135,603 bytes
               0 Dir(s)      95,945,728 bytes free

M:\>chkdsk m:
The type of the file system is NTFS.
The volume is in use by another process. Chkdsk
might report errors when no corruption is present.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
Windows has checked the file system and found no problems.

     96358 KB total disk space.
       132 KB in 5 files.
         4 KB in 9 indexes.
         0 KB in bad sectors.
      2524 KB in use by the system.
      2048 KB occupied by the log file.
     93697 KB available on disk.

       512 bytes in each allocation unit.
    192716 total allocation units on disk.
    187394 allocation units available on disk.
 
Step 9: Remove the volume on your new disk that was created when breaking the mirror:
O:\>vxassist -g dg1 remove volume m:
Successfully deleted volume / drive \Device\HarddiskDmVolumes\dg1\Volume01
 
Step 10: Remove the disk from the diskgroup:
O:\>vxdg -g dg1 rmdisk Harddisk11
Successfully removed the disk \Device\Harddisk11. Moved it to basic disk group
 
Step 11: Restore MBR:
O:\>MbrFix.exe /drive 11 restorembr z:\harddisk11.mbr
You are about to Restore MBR,
are you sure (Y/N)? y
 
Step 12: Rescan disks to see the new volume
O:\>vxassist rescan

Successfully rescanned
 
If after the rescan, the driveletter as assigned in Step 1 is not present then go into VEA and assign a letter to the partition.
 
Step 13: Validate your data and if it is ok, you can now change drive letters so your app now access the data on the partition, rather than the SFW volume:
 
N:\>dir
 Volume in drive N has no label.
 Volume Serial Number is 6003-3684

 Directory of N:\

18/07/2013  14:17                39 file1.txt
18/07/2013  14:42                22 file2.txt
05/08/2009  21:55           123,904 MbrFix.exe
18/07/2013  14:34            11,638 MbrFix.htm
               4 File(s)        135,603 bytes
               0 Dir(s)      95,945,728 bytes free

N:\>type file1.txt
"This file resides on an SFW volume"

N:\>type file2.txt
"App shutting down"

N:\>chkdsk n:
The type of the file system is NTFS.
The volume is in use by another process. Chkdsk
might report errors when no corruption is present.

WARNING!  F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
Windows has checked the file system and found no problems.

     96358 KB total disk space.
       132 KB in 5 files.
         4 KB in 9 indexes.
         0 KB in bad sectors.
      2524 KB in use by the system.
      2048 KB occupied by the log file.
     93697 KB available on disk.

       512 bytes in each allocation unit.
    192716 total allocation units on disk.
    187394 allocation units available on disk.
 
Although this is convoluted, there is no outage until step 7, so potentially you can perform this process with a very small outage.
 
Mike

 

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

Wally_Heim's picture

Hi Mike B,

The forum post that you are referring to is from a forum member and not a Symantec Employee.  The utility (mbrfix.exe) that it mentions and that you are using in your process is not a Symantec or native OS utility.  As such, I cannot say for sure what exactly it does and Symantec does not recommend its use.

While the process that you mention does work, it might not work in all cases and 1 mis-step can result in the loss of data.  And it requires addtionial disk space that not all users will have available.  As such, a Backup and Restore is still the Symantec recommended process to convert from SFW Dynamic to non-SFW Dynamic disks.

Thank you,

Wally

mikebounds's picture

I agree the recommended process should be backup and restore if you have no problem getting downtime.

I also agree there is a risk of data loss on the copy if you miss a step, but you always have the original copy to go back to.  As with most processes like upgrades there is a risk of loss of data which is why it is recommended to do a backup first, but in this case you have an automatic backup on disk.

If anyone is contrained by only being allowed a small outage then this procedure should certainly be tested first by just omitting step 7 so you don't stop the app and then verify files that have not changed since the mirror break off are the same.  You could even create 2 mirrors and break off at the same time and leave one as a Veritas volume and remove the other to convert to a partition - that way you can compare the SFW  mirrored break-off volume with the partition in great detail like comparing the check sum of each file.

Of course you don't need to use Mbrfix - you can use whatever utility you like to backup and restore the MBR - all you are doing is copying the 512 byte header on the disk to a file and then copying it back. 

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below