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.
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:
Start from the most basic operations and add things back in until you hit a problem.
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.
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?
Maybe you can try with /Z option
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