Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
We are currently on DFM 4.0.2.8103 (4.0.2D12) and are planning to upgrade to the On Command 5.1 suite soon. We will likely install version 5.1 on a new server, and I would like to install it in a different location than our current 4.0.2 is installed in. I ran across this in the Installation and Setup Guide on page 79:
--------------------------------------------
If you are upgrading to the OnCommand Core Package while also migrating to a new system,
you should use the original DataFabric Manager server installation path to avoid errors caused
by changes to the path setting option for DataFabric Manager server databases.
--------------------------------------------
If I use the dfm datastore setup command to move our existing DFM installation to the desired path before we upgrade, will that alleviate the issue raised above? Does the dfm datastore setup command move everything in a DFM installation (assuming you don't specify that you only want to move a particular object)? Any help will be greatly appreciated!
Solved! See The Solution
1 ACCEPTED SOLUTION
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI Thomas,
Is my understanding of your move correct as I updated in my earlier post ? If YES then the ISG test is not accurate and not applicable here.
For example I had been doing this personally for another activity.
A dfm backup from 4.0.2D12 running on linux restored it on a 5.1 DFM running on W2K8 by just copying the .ndb file and executing the cli dfm backup restore.
Just think, is it possible to move the linux path to windows as per the text in the ISG ? I don't understand why it was written and in what context.
But for sure I know its not applicable for your situation if my understanding was correct as per my summary earlier.
This situation is applicable only when you restore the monitordb.db file and not the .ndb file. In such situation the sql will not start if you dont set the dbdirlog to same as what it was in the monitordb.db. But this is something internal and not supported or recommended for customers.
Regards
adai
17 REPLIES 17
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Thomas,
Let me see if got your situation correctly. You are currently running version 4.0.2D12 on server A. You would like to Install version 5.1 on server B and restore the db backup from server A on B. Is my understand correct ?
If the above is correct, all you have to do is the following.
- Install OCUM 5.1, (though I would suggest you to go for 5.2 which will be GA in couple of weeks) in your preferred location in server B
- Take an archive backup of the DFM 4.0.2D12 on SeverA.
- Copy the backup taken in step 2 to <installdir>/DataFabric Manager/data directory of Server B
- Execute the cli dfm backup restore <backup filename>
When you restore the db location of the server is taken care and the one on the backup file is ignored.
The install and setup guide is incorrect, let me open a bug and get it corrected.
BTW the dfm datastore setup will move things like, database, perf dir and script-plugin dir etc.
Regards
adai
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Adaikkappan! So, just to be certain I am following this, are you indicating that the following quote from the Installation Guide is invalid? I just want to be sure this is correct before I move forward with developing a migration plan. I had spoken with Phil Bachman from NetApp a few weeks ago and he seemed to think that this quote was accurate, but he may have been mistaken. If the quote is accurate, I would need to do something like the dfm datastore setup command I described earlier. Thanks for the help!
--------------------------------------------
If you are upgrading to the OnCommand Core Package while also migrating to a new system,
you should use the original DataFabric Manager server installation path to avoid errors caused
by changes to the path setting option for DataFabric Manager server databases.
--------------------------------------------
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI Thomas,
Is my understanding of your move correct as I updated in my earlier post ? If YES then the ISG test is not accurate and not applicable here.
For example I had been doing this personally for another activity.
A dfm backup from 4.0.2D12 running on linux restored it on a 5.1 DFM running on W2K8 by just copying the .ndb file and executing the cli dfm backup restore.
Just think, is it possible to move the linux path to windows as per the text in the ISG ? I don't understand why it was written and in what context.
But for sure I know its not applicable for your situation if my understanding was correct as per my summary earlier.
This situation is applicable only when you restore the monitordb.db file and not the .ndb file. In such situation the sql will not start if you dont set the dbdirlog to same as what it was in the monitordb.db. But this is something internal and not supported or recommended for customers.
Regards
adai
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Adai,
Thank you very much as this is a big help! In my case I am moving from a Windows 2003 server to Windows 2008, but the principle is the same based on what you are saying. Thanks again! You have just made this project a whole lot easier!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would like to mark this as answered but don't see an interface button for it. Where/how can I mark this post as answered?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
BTW Thomas,
I suggest you wait for a week or so and upgrade to 5.2 which would be GA instead of 5.1.
Also there are quite a few improvements in 5.2 Compared to 5.1
Regards
adai
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Adai! I will have to recheck the Interoperability Matrix to ensure that this version is compatible with everything else, but if it is I will definitely try version 5.2!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
BTW starting today UM 5.2 is GA.....
Regards
adai
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Adai! I will check it out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Adai,
I noticed on the Interoperability Matrix that SnapDrive still doesn't show compatibility with OnCommand Suite 5.2 - does it just need to be updated or is this accurate?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which version of Snapdrive and for which purpose? Snapshot backups or DR functionality?
Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are currently on 6.4.2. We use SnapDrive on several servers to host LUNs, and we schedule snapshot backups through SMSQL or SnapDrive scripts, including DR replication.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The versions of SnapDrive listed in the IMT from the Unified Manager perspective are either for UM based snapshot backups (as opposed to archive) or DR style mirroring of the database location.
I recommend that you will want to review the SnapDrive IMT components for integration compatibility with versions of UM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank kryan. I was not sure if the lack of compatibility with SD 6.4.2 mattered in our environment. What I believe I'm hearing you say is that SnapDrive compatibility only matters if we are using UM to perform snapshot backups/DR mirroring vs. using SnapDrive itself or SMSQL. Is that accurate?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was referring to note 5521 under UM Core IMT fields discussing the versions of SDW/SDU that can be used for snapshot style UM backups (its own database/perf data) and the DR feature that can be used to mirror the UM data.
I expect that the SnapDrive IMT records will state UM Core compatibility and after checking I observed that SDU lists UM 5.2 compatibility whereas SDW only shows UM 5.1.
I am investigating the status of the SDW IMT records.
Compatibility does indeed matter - if you do not see a particular combination of versions listed within IMT you can assume it was not tested to work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks kryan, that's why we were planning to just install 5.1 for now, and upgrade to 5.2 when SnapDrive compatibility is added.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would like to mark your post as the 'answer' but don't see the buttons. I notice they do appear on this other post of mine: https://communities.netapp.com/thread/30470. I notice that post shows 'thread' in the URL while this one says 'message' ... is that the difference?
