Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
DataMigrator experiences in a MSCS Cluster
- Thread starter dc99
- Start date
Hi
I have MSCS 2-node cluster setup and did some initial testing of the Data migrator. I found that the stub recovery times very noticeably high.
There appears to be registry value that needs to be updated on W2k3 which reduces the time it takes to recover a stub file but that did not make agreat difference in my instance.
Other than that, the actual Data migration process works as it should having defined the aging and space rules in CV.
I have MSCS 2-node cluster setup and did some initial testing of the Data migrator. I found that the stub recovery times very noticeably high.
There appears to be registry value that needs to be updated on W2k3 which reduces the time it takes to recover a stub file but that did not make agreat difference in my instance.
Other than that, the actual Data migration process works as it should having defined the aging and space rules in CV.
- Thread starter
- #3
ArmchairJedi
Technical User
Hi,
We installed DM on our MSA1000 cluster and had all sorts of trouble initially. The predition tool in 6.1 didn't work so we used the 5.9 version and that was ok. After that the actual migrator couldn't scan our file structure because it had a probelm with '%' in filenames. This issue was patched overnight by Commvault. Eventually we got it to run an uit free'd up about 50% of our data - that is it was not changing and didn't need backing up each night.
After that problem arose with the retrieval time of the stub files and some people complaining of corruption in their file.
the files of course were not corrupt - what they'd opened was the stub file. Apparently if the client is useing XP and does a cut n paste of a stub it doen't trigger a file restore... so if they cut n paste onto their laptop and then go home and try to read the file... it doesn't work.
The problems caused us to reverse our migration completely. We still intend to use the software but unti the cut n paste issue is resolved its of no use.
Anotehr issue we had was the scoping of what gets migrated - because we had been using Arcserve (spit hiss) the date stamps on our fiels had been getting updated every time the file was backed up. So we couldn't use accessed date as our key - we used modofied date instead which of course meant that a lot of reference material - pdfs etc got migrated initially.
I intend to get and test the data classifier which apparently allows for a more specific targeting of what gets migrated.
Despite the problems I have nothing but praise for the Commvault suport team and help desk - throught all issues with our Commvault system they have been extememly good at support.
I'd be interested in reading about other peoples experiences with migrator too!
We installed DM on our MSA1000 cluster and had all sorts of trouble initially. The predition tool in 6.1 didn't work so we used the 5.9 version and that was ok. After that the actual migrator couldn't scan our file structure because it had a probelm with '%' in filenames. This issue was patched overnight by Commvault. Eventually we got it to run an uit free'd up about 50% of our data - that is it was not changing and didn't need backing up each night.
After that problem arose with the retrieval time of the stub files and some people complaining of corruption in their file.
the files of course were not corrupt - what they'd opened was the stub file. Apparently if the client is useing XP and does a cut n paste of a stub it doen't trigger a file restore... so if they cut n paste onto their laptop and then go home and try to read the file... it doesn't work.
The problems caused us to reverse our migration completely. We still intend to use the software but unti the cut n paste issue is resolved its of no use.
Anotehr issue we had was the scoping of what gets migrated - because we had been using Arcserve (spit hiss) the date stamps on our fiels had been getting updated every time the file was backed up. So we couldn't use accessed date as our key - we used modofied date instead which of course meant that a lot of reference material - pdfs etc got migrated initially.
I intend to get and test the data classifier which apparently allows for a more specific targeting of what gets migrated.
Despite the problems I have nothing but praise for the Commvault suport team and help desk - throught all issues with our Commvault system they have been extememly good at support.
I'd be interested in reading about other peoples experiences with migrator too!
- Status
Similar threads
- Locked
- Question