Currently the customer's DFM server is running extremely slowly on Windows 32-bit with only 4 GB of RAM. Many Snapmanager products are in use, including SME, SMSQL and SMO.
Can you tell us how many SnapManagers ? The SnapManager datasets are little heavier compared to the normal dataset and puts load on the dfm server.
1) migrate the DFM server to windows 64-bit with much more memory (I'm thinking 16GB).
Given that you already have quite few dataset, pls increase the memory further to 24 GB or some thing. As compared to 4.x which was a 32 bit application 5.x being a 64bit application will give better performance as it scales with the hardware.
2) upgrade DFM from 4.0.2 to 5.1.
Given that you have lot of SnapManager I am sure you have quite a lot of mark-deleted objects, I recommend you to run the dfm purge too and upgrade or upgrade and run the dfm purge tool. This way in one maintenance window you will be able to do both, as the purge tool requires downtime.
3) remove the old server (olddfm.local) from the domain
4) join the new server to the domain as olddfm.local
5) install 5.1 and restore/recover the DB from the backup I made in step
I would probably do it this way to reduce the impact or downtime to backup/Schedule
Setup the new server ( with temp domain name)
Install 5.1 in 7-Mode
Backup up the db using dfm backup create in existing 4.0.2
Remove the 4.0.2 dfm server from domain
Change the new server DNS names to olddfm.local
Restore the backup taken in step 3
Run the purge tool
BTW if you have perf advisor enabled you may see some sluggishness initially after upgrade to 5.1. As we purge all the stale perf data due to clones created by SnapManager and later in a week or 2's time you will see a marked performance improvement.
I'm particularly worried about losing the existing backups/datasets. Is this the right approach?
Since you are doing a restore of the database you will not loose any backups or datasets. What you are doing is perfectly correct and right approach.
This environment has 11 datasets involving SMO, SME and SMSQL. Is that a lot? I'm thinking about running the Purge Tool now as the DFM server in question is very slow. To the point that SME backups sometimes timeout in attempting to get DFM to update their application datasets.
Re: Migrating and upgrating a DFM server with lots of Snapmanager Datasets
When you said many I mistook it for 100+. 11 is not at all a big number or lot for DFM as well. In fact I would suggest you to run the purge too couple of days after you upgrade to 5.1 for the following reason. Starting 5.0 we turned the options of jobsPurgeOlder than from OFF to 90 day. This will purge any protection jobs older than 90 day. In order to reclaim/de-fragment the data a db reload and unload is required, even purge utility also requires the same. So the purge tool couple of days after 5.1 will upgrade will give you maximum benefit in minimum down time.