My horror story in Long Time, No…Post? prompted DCoTer Matthew to tell his own story. He talks about how a client changed the file permissions on a server so that he was unable to copy the files over when it came time to migrate. In the end, the error was found too late.

Matthew then asks:

When moving data I always do a screen dump of the dir /s with amounts of folders/files and sizes just before and after a move, just for a quick visual check. […] My visual check was not foolproof. Any thoughts?

Should I do a ‘take-ownership’ on all files every time we do a data migration? Any ideas?

Well, Matthew, I think the take-ownership idea is a good one but the problem that you run into later is that you will have ownership of all the other files. This may not be all bad but if your client requires the ownership to stay the same or some applications decide to go belly up because they reference the owner of the file, this could also cause you some pain!

Down with Authority!

What I would suggest is that you subvert the authority of the operating system. This sounds more nefarious than it actually is. What I mean by this is that all of the file permissions are enforced when you go through the the Windows operating system. If you can do the migration below that level, then you do not need to worry about permissions at all.

But how do you do this? I’m glad you asked. I’ve got a couple of ideas.

Option 1: Imaging Software

Whenever I am migrating data, I remember the old saying, “Just because you are paranoid doesn’t mean that they aren’t out to get you!” I go on the assumption that something is going to go wrong with the data migration and that I need to have an exact copy of the data available to me somewhere else. I find that the best way to do this is through drive imaging software.

There are several different imaging packages out there. Some of the more common ones are:

Many of these packages will allow you to boot from a floppy disk (do they still make those?) or boot CD and then copy the actual date right from the hard drive. Who cares about file access lists? Then, you not only can copy everything over to the new box (including file security permissions) but you also have an extra backup in case you kill your drive in the process.

One thing to keep in mind with this option is that you may need to have and use the SCSI or RAID controller drivers from the boot media. This is hit and miss as I have had several systems work with very little configuration while others were like pulling teeth!

Option 2: Don’t Use Microsoft

The other way that you can bypass the file permissions is to boot from a boot CD or floppy that used a non-Microsoft NTFS driver. This can be done from a Linux boot CD such as KNOPPIX or create your own boot disk and use either NTFSDOS, NTFS Reader, NTFS4DOS or Scrounge NTFS. Then just move the data over to a different drive.

Migration Policy

Whenever I do a migration, I make sure that I keep the original drives intact for one month and let people know that they have until the end of that month to check that all of their data is available and correct. I also keep a copy of the original imaged drives in a safety deposit box indefinitely as extra insurance in case someone comes back a year later saying, “I know I had a month to check my stuff and I thought it was all there but…” This way, you can pretend that you have to go to a lot of effort and you will “see what I can do”, then come out looking like the hero!

Anyway, Matthew, I hope this provides you with some ideas to lessen the pain for that next data migration.

If you found this post useful, why don't you buy me a cup of coffee to show your gratitude?

Trackback link - http://www.dailycupoftech.com/2006/11/14/howto-cover-your-butt-when-migrating-data/trackback/
Tim Fehlman