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.

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

Migrating from Veritas Storage Foundation Volume to Windows Disk

Wally_Heim
Level 6
12 years ago
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
mikej1983
Level 2
12 years ago
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
Level 6
12 years ago
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
Level 2
12 years ago
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
Level 6
12 years ago
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
Level 2
12 years ago
Would it be possible to mirror using Veritas SFW without writing the Veritas signature to the newly presented disk?
Wally_Heim
Level 6
12 years ago
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
Level 6
12 years ago
This is possible in UNIX, but it looks more complicated in Windows. In UNIX this relies on the following 3 properties:

The Veritas Volume is on contiguous space on a single disk

You are able to create a native O/S partition in exactly the same position as the volume

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:

Add a new disk to the system the same size (actually slightly larger) as SFW volume

Create a partition on the disk the same size as volume in SFW,

Add the disk to the diskgroup which converts partition to a volume.

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

Delete converted volume

Mirror volume in SFW to the now empty disk

When mirror is synced, stop access to the volume (i.e stop apps and users writing to it) and then break mirror

Delete the volume on your new disk that was created when breaking the mirror

Remove disk from the diskgroup

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
Wally_Heim
Level 6
12 years ago
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

Level 6

12 years ago

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

Forum Discussion

Migrating from Veritas Storage Foundation Volume to Windows Disk

Related Content

NetBackup IT Analytics Foundation

Veritas Storage Foundation Standard vs Veritas Storage Foundation Enterprise

veritas storage foundation 5.1

Storage Foundation with VCS migration

Veritas Storage foundation manager