I'm running Robocopy on a server that has one processor and isn't very powerful. When I launch Robocopy, the server hits very high CPU usage. How can I keep the CPU usage down?
If you must run Robocopy on that server, use the Start command with the /Low switch to start your Robocopy script. Alternatively, you could run Robocopy on another server, if you have a fast network connection.
I've heard that copying can cause fragmentation. How can I reduce
fragmentation?
Robocopy supports a /Create switch option that creates a folder structure of 0-byte files. Run an initial copy with this switch, then run a copy without this switch to actually copy the data. The robocopy.doc Help document that's installed with the resource kit explains the rationale for using /Create. Refer to the heading "Minimizing Directory Fragmentation."
When we performed an incremental Robocopy run, some recent permission changes didn't seem to come over properly. What happened?
Robocopy does copy security settings when you use the /Sec switch. However, the utility doesn't update the permissions each time you run it unless you use the /Secfix option. If you have a folder area in which permissions are frequently changed, always use the /Secfix option. Don't use the /Sec or /Secfix option when you've applied different permissions to the destination area and don't want Robocopy to overwrite these permissions. Remember that only NTFS volumes support file and folder permissions, so when you copy from an NTFS volume to a FAT or FAT32 volume, permissions will be lost.
We have standalone servers that use local groups for permissions. When we ran Robocopy with the /Sec switch to copy data from one server to another, it copied the data but not the security settings. What went wrong?
The local groups on the two standalone servers have different SIDs. The destination server didn't recognize the permissions because its local groups didn't have the right SIDs. You can use Small Wonders Software's Secure Copy if you need to create matching local groups on the destination server. The final answer at the end of this article has more information about Secure Copy.
Alternatively, you could use the Subinacl tool to replace the lost permissions on the destination server. The Microsoft article "Cannot Resolve Local Groups When You Migrate Files Between Windows NT 4.0 Member Servers" (http://www.support.microsoft.com/?kbid=250267) explains how. Keep in mind that Subinacl is a complicated utility. Preventing the problem with a product such as Secure Copy is easier than fixing it with Subinacl.
We have a standalone server that uses local groups for permissions and has a locally connected storage shelf full of older 9GB drives. We're going to upgrade to 36GB drives and must remove and replace all the drives at once. No other storage is available on this server. We have a second server that has the capacity to handle the data temporarily, but we're afraid we'll lose our elaborate permissions structure when we offload the data to the other server because it doesn't have the same local groups. What procedure can we use to accomplish this data migration and get the data back to the new storage with the permissions intact?
I have a procedure that I've used with good success, but I would advise you to test the procedure carefully on a small subset of folders to ensure that it works in your environment before you use it for your migration. Also, have a full backup available in case of problems.
Use the standard Robocopy syntax with the /Secfix switch to copy the data and permissions to the temporary server location. Robocopy will bring over the files with their permissions to the interim destination.
When you view the Security tab on a file or folder's Properties dialog box, you'll be unable to see the group name, but you will see the SID that represents the group on the source server. The group name is unknown on the interim server because the local group doesn't exist on this server.
After you've replaced the drives on the original server and created and formatted the new partition, run another Robocopy with /Secfix back to the original server. The data and the associated SIDs are now back on the original server on which the local groups reside and are again visible. Remember that you need to be extremely careful to verify both the source-to-interim and interim-to-destination copy operations.
Prev. page
1
2
[3]
4
next page 
