Using xcopy for backups

For DOS purists everywhere, you can use the Windows XCOPY command to carry out simple but effective backups as follows:

G:\BK> xcopy/s/e/d/y/r/h/c C:\*.*

This command will copy every file on C: to G:\BK and will include all subdirectories (/s) including empty ones (/e), copying only files that have actually changed (/d). It will also presume yes to any questions asked (/y), overwrite read-only files (/r), copy hidden and systems files also (/h) and continue if errors occur (/c).


  • The /c parameter is useful for when you want to skip past (system) files that are in use (normally reported as sharing violations)
  • The /d is only useful if your target disk drive has been formatted using NTFS (for me this is the most powerful and useful parameter.
  • Even though you might think that you don’t want hidden/system files to be copied, bear in mind that Windows Media Player stores the artwork images for albums and songs as hiddent JPG files so if  you leave out the /h parameter you wouldn’t necessarily be backing up everything in your music collection.

Backing up MRTG files using TAR

We use MRTG on a number of test servers and have a simple backup solution in place that uses tar to take a copy of the MRTG configuration files as well as the graph data files. However, of late we have noticed that tar has run into trouble when it coincides with a scheduled MRTG update.

In the main, one of two things happens:

  1. Some of the .tmp files generated by MRTG (during its update) are present when tar compiles its list of files to be archived, but are gone again when it goes to add them to the archive.
  2. Some of the .old files maintained by rateup are changed while tar is trying to add them to the archive, causing tar to fail with the error: file changed as we read it.

Our solution to the first point was to add a --exclude=*.tmp to the tar command. However, the second issue was more interesting because it is not clear whether the .old files in question are actually something worth backing up or not.

As it turns out, they are not. Although not very well documented, our testing showed that these files are simply copies of the previous .log files and can also be excluded from the tar command without issues.