Monday, October 8, 2007

The pitfalls of ROBOCOPY

I have been using ROBOCOPY for a lot of reasons - Home folder replication for disaster recovery purposes, file-copy utility for custom transaction log shipping for SQL Server, etc. It has been a very useful tool for me, especially when you talk about disaster recovery. But what a lot of people do not realize is that this will become a very big headache if not used properly. One scenario I have seen is a database log file being replicated over to another server. Database log files are being locked by the service or application responsible for running the database engine. In this case, depending on how it is configured, ROBOCOPY will try execute the copy command until such time that it can do so. Now what will happen if it cannot copy the file due to a lock caused by the service? It will enter an infinite loop. And if you're like me who likes to log every activity done by any utility or script, you will configure ROBOCOPY to do so as well. When this happens, the log file generated will become so huge that it would be very difficult to open with Notepad. Just a word of caution when using ROBOCOPY - DO NOT use the utility on files that are being locked or used by services or applications.

2 comments:

Anonymous said...

Or using these command line arguments has Robocopy continue if it encounters a locked file...

/W:1 /R:0

bassplayer said...

Thanks for the tip, I really appreciate that. The problem with using ROBOCOPY on locked files is that the files may be corrupted if it continues. This is going to be a big issue when you're dealing with database files or those that have something to do with backup files. Again, thanks for the tip

Google