3

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.

John Hunt
  • 428
  • 2
  • 10
  • 20
  • 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 00: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 01:48

5 Answers5

3

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.

August
  • 3,114
  • 15
  • 17
  • I'm not sure this *is* the best solution, but I long since stopped working at that company. This however does seem like the best solution and had the most upvotes so I've ticked it. – John Hunt Jun 10 '15 at 10:39
0

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.

ttyS0
  • 469
  • 2
  • 4
  • 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 01:13
0

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?

DutchUncle
  • 1,265
  • 8
  • 16
0

Maybe you can try with /Z option

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

jet
  • 475
  • 4
  • 8
0

You say your log does not contain any valuable informations, but you asked robocopy to NOT log filenames and directory names: /NFL /NDL

You really should push the logging options to the max until you find what is your problem.

/x Reports all extra files, not just those that are selected
/v Produces verbose output, and shows all skipped files
/fp Includes the full path names of the files in the output
/np disable progress bar

To solve your problem, you can try with:
/zb Uses Restart mode. If access is denied, this option uses Backup mode

If anything fails, try (I don't remember what those options do): /is Includes the same files
/it Includes "tweaked" files

Gregory MOUSSAT
  • 1,737
  • 2
  • 25
  • 48