Migration from NetWare 6.5 SP7 to SLES10SP2-OES2SP1 Hiccup


After doing a pre-migration of a Volume from NetWare 6.5 SP7 to SLES10-SP2 w/ OES2-SP1 all of the file structures appeared to be correct. We did this “Pre-migration” in order to copy the bulk of our user files prior to doing a final sync and pointing to the new volume on the new server. But after the sync, we found that some of the source files and the destination files had the EXACT same size, creation date, and modified date, but the content was different. Here is how it went down.

The initial pre-migration was done on a Tuesday and the final sync was performed that Saturday. What we found was that after the final sync was performed, the destination file contained the content as of Tuesday, but did not include any updates that occurred between Tuesday and Friday. The last modified would not be modified and the size did not change at all. In 90% of these cases, the files were either Excel, Word, or Powerpoint files, but in an organization with almost a terabyte of user data, this was a very large number of files. We could duplicate this behavior over and over. Just open a file on the source, make modifications, and save. The file size would still show to be exactly the same. If you did a sync on that directory, the target would not get updated. The migration tool was not smart enough to recognize that the file had changed since the size, time, and date stamps were identical. Working with Novell Technical Support (NTS) we finally found a nss switch that would resolve this behavior, but thus, the damage was already done. We already had users who had updated files since the final sync on the target. The resolution to keep this behavior from occurring was to run the FlushFilesImmediately=VOLUME command at the prompt on the NetWare Server.

To further complicate things, rsync was not smart enough to notice the changes either. After doing a full rsync, the issue still remained. Next we turned to a 3rd party program called Beyond Compare. With this utility we did a binary compare of the source and target and manually copied over the files that had the same dates, but different content. This was a long and painful process.

So, how could this have been avoided? I have not been able to confirm this yet, but NTS said that there had been several updates in the Miggui utility in OES2SP2 that should have been able to pick up these updates. So, it might be beneficial if you are migrating from NetWare to migrate directly to OES2SP2 using the newer utility. The second way would be to not do a pre-migration. Had we not done the migration on Tuesday and then tried to sync the differences on Saturday, we would have been o.k. It was the “sync” that could not pick up the changes. Also NTS said that it is definitely best practices to disable logins on the server and clear connections prior to starting the migration. This was also lacking in the documentation. In the miggui in OES2SP2, I was told that there is check option to disable logins for this purpose. We have successfully used the migration utility to migrate almost 40 other servers successfully without any of these issues. All I can say is, “it only takes one for you to feel the pain.”

(Visited 1 times, 1 visits today)


  • darrenjthompson says:

    Did you turn on the “checksum check” { option -c} function in rsync first?

    I have found that change detection is not foolproof unless you force a full CRC compare (It does slow things down considerably).

  • Leave a Reply

    Your email address will not be published. Required fields are marked *