HTnM data migration between Windows and Linux
Sometime ago I was trying to migrate HTnM data, more precisely HTnM agents datastore history information, from Windows to Linux and want to share my story. Migrating HTnM configuration and its data from Windows to Linux is very easy, just follow the documentation steps verbatim. But moving historical data from the HTnM agents, whether it’s RAID or SAN, is a different thing. One may think that it’s a straightforward operation, well it really is, but the documentation doesn’t quite agree on that.
OS groups that can be migrated
OS groups are defined as follows for the Tuning Manager series. Store database migration can only be performed for the same OS groups.• Windows groups:
• Windows Server 2003 (x86)
• Windows Server 2003 (x64)
• Windows Server 2008 (x86)
• Windows Server 2008 (x64)
• HP-UX groups:
• HP-UX 11i V2 (IPF)
• HP-UX 11i V3 (IPF)
• Solaris (SPARC) groups
• Solaris 9 (SPARC)
• Solaris 10 (SPARC)
• Solaris (X64) group:
• Solaris 10 (X64)
• AIX groups:
• AIX 5L V5.3
• AIX V6.1
• Linux groups:
• Linux4 (x86)
• Linux5 (x86)
Moreover, it says that this is unsupported (I have opened the case in HDS and they confirmed my sneaking suspicions). Period.
Thankfully, I had some spare time to prove the documentation wrong. Sounds over-confide, I know. ;-)
Anyway, I tried to pretend that I hadn’t read that part that stated that this was unsupported and went through the steps as I was migrating data between Windows-based machines. First, I boldly tried to migrate directly from Windows (HTnM 6.4) to Linux (HTnM 7.1) and everything went very nice until I tried to restore the data from RAID agent on Linux server. When I ran jpcrestor tool I was told that data model of the agent on the migration destination (Linux server) differed from the migration source (Windows) version. JFYI, HTnN ver. 6.4 uses data model ver 7.6, whilst HTnM ver. 7.1 has data model ver. 8.0. For me it meant that before being able to migrate the store database I had to convert from older to newer version. Hitachi provides a special tool just for that:
# /opt/jp1pc/tools/jpcdbctrl dmconvert -d /tmp/export/ KAVE05847-I Data model conversion of backup data will now start. (dir=/tmp/export/) KAVE05099-E An internal command terminated abnormally. (/opt/jp1pc/bin/jpccvtmdl -sdict "/tmp/export//STDICT.DAT.bak" -ddict "/tmp/export//STDICT.DAT" -stdir "/tmp/export/" -wkdir "/tmp/export//cvtwork" -directdbdir "/tmp/export/") KAVE05849-E Data model conversion of backup data ended abnormally. (dir=/tmp/export/)
As I mentioned before, I opened a case with HDS and was “pleased” to hear that what I was doing was unsupported. So I was on my own. But I didn’t give up. I’d decided to upgraded HTnM on Windows to version 7.1 and repeat everything once again. To my surprise, since I didn’t have to mess around with converting data model to the same format, agent’s data were restored swimmingly. Important note. I had to run dos2unix against jpcsto.ini file since it contained Windows CRLF line terminators which is expected since I was migrating from Windows server. Once I did that, there were no more hurdles to overcome:
# ./jpcresto agtd /tmp/hdsb inst=uspv-array Directory receiving backup data = /opt/jp1pc/agtd/store/uspv-array Directory supplying backup data = /tmp/hdsb Clearing indexes... Appropriate indexes removed. Replace in progress. Replacing /tmp/hdsb/STDC.DB to /opt/jp1pc/agtd/store/uspv-array/STDC.DB ... Replacing /tmp/hdsb/STDC.IDX to /opt/jp1pc/agtd/store/uspv-array/STDC.IDX ... Replacing /tmp/hdsb/STDM.DB to /opt/jp1pc/agtd/store/uspv-array/STDM.DB ... Replacing /tmp/hdsb/STDM.IDX to /opt/jp1pc/agtd/store/uspv-array/STDM.IDX ... Replacing /tmp/hdsb/STAM.DB to /opt/jp1pc/agtd/store/uspv-array/STAM.DB ... Replacing /tmp/hdsb/STAM.IDX to /opt/jp1pc/agtd/store/uspv-array/STAM.IDX ... Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDS.DB to /opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDS.DB ... Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDS.IDX to /opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDS.IDX ... Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_CLPS.DB to /opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_CLPS.DB ... Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_CLPS.IDX to /opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_CLPS.IDX ... Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDE.DB to /opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDE.DB ... Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDE.IDX to /opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDE.IDX ... Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_PTS.DB to /opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_PTS.DB ... ... SKIPPED ... Replacing /tmp/hdsb/STPD/2011/0726/001/PD_RGC.DB to /opt/jp1pc/agtd/store/uspv-array/STPD/2011/0726/001/PD_RGC.DB ... Replacing /tmp/hdsb/STPD/2011/0726/001/PD_RGC.IDX to /opt/jp1pc/agtd/store/uspv-array/STPD/2011/0726/001/PD_RGC.IDX ... Replacing /tmp/hdsb/STPH.DB to /opt/jp1pc/agtd/store/uspv-array/STPH.DB ... Replacing /tmp/hdsb/STPH.IDX to /opt/jp1pc/agtd/store/uspv-array/STPH.IDX ... Replacing /tmp/hdsb/STPA.DB to /opt/jp1pc/agtd/store/uspv-array/STPA.DB ... Replacing /tmp/hdsb/STPA.IDX to /opt/jp1pc/agtd/store/uspv-array/STPA.IDX ... Replacing /tmp/hdsb/STPT.DB to /opt/jp1pc/agtd/store/uspv-array/STPT.DB ... Replacing /tmp/hdsb/STPT.IDX to /opt/jp1pc/agtd/store/uspv-array/STPT.IDX ... KAVE06006-I Restore processing of the Store database terminated normally.
More than that, when I logged onto HTnM web interface and searched my one year old data from USP-V array – they were all their for my observation. Sweet. What’s the gist of this post, you may ask. Well, not only don’t ever give up but always take every recommendation, even if it comes from a vendor’s support team, with a grain of salt. Peace.