GPT disk reinitialized?
Posted: Wed Nov 19, 2014 9:05 am
We are experiencing a weird behaviour of Starwind free NAS ver.6.057
The setup of our test environment
Starwind free NAS is installed on the top of Windows Server 2012 R2 + Supermicro`s SuperStorage Server (RAM 16GB, 2x CPU INTL Xeon, 24x3TB Seagate Constellation giving 2x RAID6 LUNs with 16 and 35TB capacity). The disk subsystem is healthy and Starwind logs contain only minor issues. There are 6 different iSCSI targets currently published from the Starwind server. Two deduplicated LUNs are connected to HP Dataprotectors server (installed on Windows Server 2012 R2) via Microsoft iSCSI initiator as an external storage space for the backup server. Both servers are connected via 10G LAN. The backup storage is utilized rather easily and there is more than 50% of free space on the 35TB LUN.
The problem
There were two identical unplanned outages on the backup server within the last three months. They were caused by "reinitailization" of the Starwind iSCSI disk in the windows OS of the Dataprotector server. Probably the iSCSI target was disconnected from an unknown reason. When it was reattached automatically after a while, OS didn´t recognize the GPT sector on it. Finally Disk manager in OS indicated the volume as a new one and wanted to reinitialize it. Because the disk contained important backup data we didn’t want to do so. As a remediation, we successfully used the testdisk utility to recreate the volume without losing the data on it.
We discussed the problem with a Dataprotector expert, who indicated, that the problem is probably not with malfunctioning backup sofware and suggested troubleshoot primarily the iSCSI initiator or the Starwind software.
The question(s)
Can such behavior come from a wrong interpretation of iSCSI commands at operating system level or whether could it be caused by Starwind NAS itself? Because as I know, normally there is no possibility to accidentally reinitialize a disk in the operating system after you format it (which means it is impossible for an application also). Up to now we had absolutely no problems with other iSCSI targets coming from the same Starwind server (but they are connected to vSphere). Can here help an upgrade to the newest version of Starwind and if so, is there a safe way to provide the upgrade without losing data on our LUNs?
We are seriously considering a production deployment of Starwind NAS in our IT environment, so it is very important for us to find a satisfactory answer for the described problem.
Thank you in advance for any suggestion,
tomas.
The setup of our test environment
Starwind free NAS is installed on the top of Windows Server 2012 R2 + Supermicro`s SuperStorage Server (RAM 16GB, 2x CPU INTL Xeon, 24x3TB Seagate Constellation giving 2x RAID6 LUNs with 16 and 35TB capacity). The disk subsystem is healthy and Starwind logs contain only minor issues. There are 6 different iSCSI targets currently published from the Starwind server. Two deduplicated LUNs are connected to HP Dataprotectors server (installed on Windows Server 2012 R2) via Microsoft iSCSI initiator as an external storage space for the backup server. Both servers are connected via 10G LAN. The backup storage is utilized rather easily and there is more than 50% of free space on the 35TB LUN.
The problem
There were two identical unplanned outages on the backup server within the last three months. They were caused by "reinitailization" of the Starwind iSCSI disk in the windows OS of the Dataprotector server. Probably the iSCSI target was disconnected from an unknown reason. When it was reattached automatically after a while, OS didn´t recognize the GPT sector on it. Finally Disk manager in OS indicated the volume as a new one and wanted to reinitialize it. Because the disk contained important backup data we didn’t want to do so. As a remediation, we successfully used the testdisk utility to recreate the volume without losing the data on it.
We discussed the problem with a Dataprotector expert, who indicated, that the problem is probably not with malfunctioning backup sofware and suggested troubleshoot primarily the iSCSI initiator or the Starwind software.
The question(s)
Can such behavior come from a wrong interpretation of iSCSI commands at operating system level or whether could it be caused by Starwind NAS itself? Because as I know, normally there is no possibility to accidentally reinitialize a disk in the operating system after you format it (which means it is impossible for an application also). Up to now we had absolutely no problems with other iSCSI targets coming from the same Starwind server (but they are connected to vSphere). Can here help an upgrade to the newest version of Starwind and if so, is there a safe way to provide the upgrade without losing data on our LUNs?
We are seriously considering a production deployment of Starwind NAS in our IT environment, so it is very important for us to find a satisfactory answer for the described problem.
Thank you in advance for any suggestion,
tomas.