If, after a copy, I compare the number of bytes at the source and destination locations and I notice that Robocopy failed to copy a file and hasn't logged the failure, how can I locate the file?
If you have a large folder structure, finding the uncopied file or files can be like finding a needle in a haystack. If only one file wasn't copied, you can use the Search (Windows XP or Win2K) or Find (NT 4.0) utility to search for the file by size. In Win2K or NT 4.0, Search or Find locates a range of files because the utility can search only for files that are bigger or smaller than a specified size. XP improves the Search utility with searches for an exact number of kilobytes.
Alternatively, you can use the Dir command on the source location to find the number of bytes you're missing from the destination location. For example, if a 5402-byte file were missing from the destination location, you could use the syntax
dir /s D:\source | find "5,402"
to discover which file might be the culprit on the source location. Another approach is to run the Dir /S command on both the source and destination areas and redirect the output to two log files. Compare these two files and see which entries in the source file are missing in the destination file.
You can also use the WinDiff utility in the Win2K Support Tools or the NT 4.0 resource kit to make file and folder comparisons. Third-party tools such as TimeAcct Information Systems' Disk Triage and JAM Software's TreeSize can also show where two folders vary in size.
I've been running incremental copies every night to prepare for a big data migration and have seen really long copy times and thousands of files that are new in the log files each night along with thousands of Extra files that have been deleted. The size of the area isn't in creasing much, so what might be causing this activity?
This phenomenon could have several causes. Your shares might be undergoing significant data churn. Users might be replacing old data with new data much more frequently than you realized. Or, a user might be changing the name of an upper-level folder. When such a change occurs, Robocopy considers all the files and subfolders in that folder to be new and recopies them. A user changing a top-level folder that affects the location of thousands of files will void your prediction of how long your final copy operation might take. If you use Robocopy's Purge option, the utility takes time to delete the old file structure that has changed. These situations don't signal problems; they just mean longer copy runtimes. Other possible explanations for a slow copy operation might be network or CPU usage problems caused by scheduled tape backups running simultaneously with the copy operation or overhead created by your antivirus software scanning outgoing or incoming files. Overhead is involved when Robocopy traverses the folder structure and compares the source and destination areas, even if it doesn't copy any files.
If you're copying a few hundred or a few thousand files and you don't have 24 x 7 file usage, minimizing the copy time probably isn't that crucial. If you're dealing with half a million files, you really want to minimize the final copy time. Plan to run the final copy operation with the files either offline to users or in read-only mode. If you leave the share online and let users modify files, you might end up with an earlier version of the file or missing files on the new location. You'll also have difficulty getting the sizes of the source and destination areas to match because file sizes will be changing during the copy.
If you're running copies in a tight time period, as you get closer to the final cutover to the new area, you'll want to run more frequent copies. This practice ensures that the final cutover copy makes as few changes as possible and, therefore, that user offline time is minimized. The practice also minimizes surprises such as permissions problems, path length problems, or illegal characters during the crucial cutover time. Discovering and resolving these problems is easier when you aren't under the time pressures of the cutover.
Prev. page
1
[2]
3
4
next page 
