How to do Windows Backups with Robocopy – Tips & Tricks
I’ve been using a handy little Microsoft tool for many years now called ROBOCOPY which is a great command line tool for copying large sets of folders and files from one place to another, especially over a network. It has a nifty network-restartable mode (/Z option) which means if it fails, you can just re-run the command and it will pick up where it left off – essential when you’re moving Gigabytes and Terra-bytes of data. It’s also great for mirroring data between file shares on servers.
From a command prompt (usually with Administrator rights), here is how I use it:
robocopy /Z /E /R:0 /W:0 <source-path> <dest-path> /XD "Temp" "Temporary Internet Files" /XF pagefile.sys hiberfil.sys
- /Z – this is the network restartable mode, it checks the destination to see if the file already exists and skips, and also provides a % counter as the file copies
- /E – this tells it to copy sub-folders, including empty ones
- /R:0 – the default for Robocopy if it can’t get a lock on a file is to retry 3 times, but if it can’t lock a file for reading the first time, it usually never will, so I set it to zero.
- /W:0 – this is the number of seconds to wait if retrying, because we don’t retry I just set this to zero.
- <source-path>, <dest-path> should speak for themselves
- /XD – this is to exlude folders such as “Temp” and “Temporary Internet Files” which I never bother backing up, they should never contain anything useful.
- /XF – this is to exclude certain files, such as the system Paging and Hibernation files which are really big and are re-created if you ever restore a system.
Why not use XCOPY instead?
Good question, I just got so used to using ROBOCOPY and the few times I tried XCOPY it didn’t seem to do what I wanted as reliably. And as it turns out Microsoft agrees with me, and has actually deprecated Xcopy in favour of Robocopy – so stop using Xcopy today! Robocopy is now shipped by default with Windows Vista/7 and Server 2008 and onwards; it used to have to be installed separately from a Resource Kit.
Here’s a big tip that you might come across
There is a known issue with some Windows Vista/7 machines (usually the ones that have been upgraded from a Windows XP install) – you’ll get an infinite loop problem during backup that will cause the “Application Data” folder to be nested so many times that it will eventually cause a “file name too long” error in the NTFS path.
- /XJ – Exclude NTFS junction points, to avoid the endless “Application Data” folder nesting on some Windows Vista/7 machines.
for /f "delims=" %X IN ('dir /x /b /s "Application Data"') do ren "%X" "ad"
Note: the command above is quite destructive so please only run it over a backup set that you’re trying to delete, but can’t because of the “file name too long” error.
A note about full Windows machine backups and Robocopy
Long path tool is the best solution for your problem. try it and solve your problem.
Thanks for mentioning Long path tool. I had a look, but it’s not something I would generally use because I tend to be suspicious of free tools like that unless they are downloaded from an official source.
When I have ran across the path too long issue I found it simple to create a new, empty source directory and then use robocopy with the /mir switch to copy the empty directory over the top of the back-up set or file location with the path too long issue. Once it runs you can delete the old folder or re-run your set back into that location. Very effective!!!
Try and download ” Long Path Tool ” is also useful in situations where you see these error messages: Cannot read from source file or disk, there has been a sharing violation, cannot delete file or folder, the file name you specified is not valid or too long, the source or destination file may be in use and many other file managing errors.
I tried robocopy and encounter a serious limitation. It can’t backup opened files!
I’m trying to overcome this limitation with diskshadow.exe. But I think Windows Server Backup will do everything except maybe for the network resume?
For other backup solutions, can they restore with NTFS ACLs permission preserved? And can they be backed up to linux-base NAS and still preserved NTFS ACLs permissions? I know robocopy won’t be able to preserve them if the backup destination is not NTFS formatted.
Old thread but topic still valid. Robocopy tends to leave me with folders full of 0 byte files. Xcopy though deprecated is still useful. Example. Robocopy won’t copy a single file not in a folder or directory. For xcopy I use xcopy c:\filesorfoldersource\*.* /s /e /f c:\filesorfolderdestination.
The addition of *.* greatly helps. I won’t copy a Windows install disk with Robocopy. I like your use with Robocopy but I add /Zb in place of /z and add /s to copy system files. Also add /xx /copyall /secfix /eta /v. Sometimes ad /it /is for tweaked and changed files and /xo to skip older files I want to keep. I’m still not sure about /xj if it copies with out the junction loop or if it just skips those files.
Recently, I have create robocopy batch file the following are the code use:
rem Copy folders and subdirectories.
robocopy “C:\Users\Owner\Desktop\New folder” “K:\New folder” /e /w:1 /r:5 /zb
robocopy “C:\Users\Owner\Desktop\New folder (2)” “K:\New folder2” /e /w:1 /r:5 /zb
rem Copy specified files in the folders and subdirectories folders.
robocopy “C:\Users\test\Documents” “D:\Outlook” “Bowling Competition 2015 (Inter-Site).xlsx” /w:1 /r:5 /zb
After running the batch file as administrator, I receive the following error: The filename, directory name, or volume label syntax is incorrect. But the file has been transfer successfully, and I am able to view the file. Anyone has any solutions or did I need to add in additional commands in order to rectify the error.
Never try that one