Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm using Robocopy to sync data from our server's hard disk to an external disk as a backup. It's a pretty simple solution but pretty much the best/easiest one we could come up with - we use two external disks and rotate them offsite.

Anyway, here's the script (with the comments taken out) that I'm using to do it. It works very well, it's quick and almost 100% complete - however it's acting pretty strange with a few files (note company name has been changed in paths to protect the innocent):

@ECHO OFF
set DATESTAMP=%DATE:~10,4%/%DATE:~4,2%/%DATE:~7,2% %TIME:~0,2%:%TIME:~3,2%:%TIME:~6,2%

SET prefix="E:\backup_log-"

SET source_dir="M:\Company Names Data\Working Folder\_ADMIN_BACKUP_FILES\COMPA AANY Business Folder_Backup_040407\COMPANY_sales order register\BACKUP CLIENT FOLDERS & CURRENT JOBS pre 270404\CLIENT SALES ORDER REGISTER"


SET dest_dir="E:\dest"
SET log_fname=%prefix%%date:~-4,4%%date:~-10,2%%date:~-7,2%.log
SET what_to_copy=/COPY:DAT /MIR
SET options=/R:0 /W:0 /LOG+:%log_fname% /NFL /NDL

ROBOCOPY %source_dir% %dest_dir% %what_to_copy% %options%

set DATESTAMP=%DATE:~10,4%/%DATE:~4,2%/%DATE:~7,2% %TIME:~0,2%:%TIME:~3,2%:%TIME:~6,2%
cscript msg.vbs "Backup completed at %DATESTAMP% - Logs can be found on the E: drive."
:END

Normally the source would just be M:\Comapany name data\ but I altered the script a bit to test the problem.

The following files in the source are not copied to the dest:

Someclient\SONICP~1.DOC
Someclient\SONICP~2.DOC
Someclient\SONICP~3.DOC

However, files in the same directory named:

TIMESH~1.XLS TIMESH~2.XLS

are copied. I'm able to open the files that aren't copied with no trouble at all, and they certainly weren't opened when I ran robocopy so it's not a locking issue. Robocopy is running as administrator so it's not a permissions issue.

There's no trace these files were even attempted to be copied as there are no errors being output in the log or in my command prompt.

Does anyone have any suggestions as to what this might be? Busted hard disk?

Cheers, John.

share|improve this question
    
What do you get in your logs if you remove the /R:0 /W:0 options which effectively instructs robocopy to skip files if there is some error? –  Zoredache Jan 20 '11 at 0:40
    
R retries and W waits between retries, but for my test I disabled /NFL and /NDL.. there is no error, the log just displays as though they copied successfully even though they don't appear on the destination. Very weird. –  John Hunt Jan 20 '11 at 1:48
add comment

4 Answers

Are you sure the account doing the robocopying has read access to those files? Maybe someone edited the permissions on just a couple of files...

EDIT: re-read the post and realized you already tested permissions.

If you want to test just those files, why not try copying them manually with the GUI? If that works then just run this one line:

robocopy "M:\Company Names Data\Working Folder\_ADMIN_BACKUP_FILES\COMPA AANY Business Folder_Backup_040407\COMPANY_sales order register\BACKUP CLIENT FOLDERS & CURRENT JOBS pre 270404\CLIENT SALES ORDER REGISTER\<filename_that_isn't_working>" E:\dest

Start from the most basic operations and add things back in until you hit a problem.

share|improve this answer
add comment

You might be bumping up against the maximum path length, which, including the terminating file name, is only 260 characters.

I've run into this kind of thing before with subversion repositories that have deep directories, and work just fine on UNIX/Linux systems, but then people on Windows systems cannot perform a complete checkout because some of the paths are too long.

share|improve this answer
    
It's running on windows XP and I think the limit for the older versions of robocopy is 255 chars (these paths are around 230 chars.) So it shouldn't really be a matter of path lengths, considering it's successfully copying paths longer than the ones it's failing on too. Good point though. –  John Hunt Jan 20 '11 at 1:13
add comment

I would try wiping that particular directory and then see if the file get written correctly.

Also run a chkdsk on your external drive.

And what's the file system on the target and is that the same type as the source file system?

share|improve this answer
add comment

Maybe you can try with /Z option

/Z : Copy files in restartable mode (survive network glitch).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.