07-15-2013 09:07 AM
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.
Solved! Go to Solution.
07-15-2013 12:20 PM
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
07-15-2013 12:20 PM
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
07-16-2013 06:55 AM
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.
07-16-2013 07:04 AM
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
07-16-2013 07:21 AM
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.
07-16-2013 07:34 AM
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
07-17-2013 02:30 PM
Would it be possible to mirror using Veritas SFW without writing the Veritas signature to the newly presented disk?
07-17-2013 02:50 PM
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
07-18-2013 12:56 AM
This is possible in UNIX, but it looks more complicated in Windows. In UNIX this relies on the following 3 properties:
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:
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
07-18-2013 05:56 AM
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
07-18-2013 08:10 AM
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 - -
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.
O:\>MbrFix /drive 11 savembr z:\harddisk11.mbr
O:\>vxdg -g dg1 adddisk Harddisk11 Successfully added disk(s) to the dynamic disk group dg1
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
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 - -
O:\>vxassist -g dg1 remove volume n: Successfully deleted volume / drive \Device\HarddiskDmVolumes\dg1\Volume1
O:\>vxassist -g dg1 mirror sfw_vol Harddisk11 Added mirror to the volume \Device\HarddiskDmVolumes\dg1\sfw_vol
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 - -
O:\>echo "App shutting down" > file2.txt
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.
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
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.
O:\>vxassist -g dg1 remove volume m: Successfully deleted volume / drive \Device\HarddiskDmVolumes\dg1\Volume01
O:\>vxdg -g dg1 rmdisk Harddisk11 Successfully removed the disk \Device\Harddisk11. Moved it to basic disk group
O:\>MbrFix.exe /drive 11 restorembr z:\harddisk11.mbr You are about to Restore MBR, are you sure (Y/N)? y
O:\>vxassist rescan Successfully rescanned
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.
07-18-2013 08:28 AM
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
07-18-2013 09:06 AM
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