Xbackup.cmd

 Executive Summary:

Do you need a fast, effective, no-frills tool for performing manual backups? Xcopy, which is one of the oldest tools around, is very effective. The trick is in knowing how to use Xcopy correctly as a backup tool. In this article I explain how to use Xcopy as a simple backup tool, including when to use particular options. I also discuss how to determine whether Xcopy is the right tool for your backup needs.

For the purposes of our discussion, let’s assume that you need to back up user data files on a PC on which the system and user files are on drive C, and that you're backing up to an external USB drive that has drive letter E assigned to it. You want to capture data for all your users. I’ll show you how to create a clean and simple command shell script that works for most systems.

How Xcopy Works
Many people use Xcopy in a literal fashion: They open a command prompt, change to the directory they want files copied to, and enter the command

xcopy /s *.*

You need to replace sourcepath with the source folder that contains the files to copy. The /s switch tells Xcopy to also copy subdirectories, if they aren’t empty.

To copy files from the PC’s C drive Documents and Settings folder to the USB device’s E drive, you’d open a command prompt and switch to the E drive by typing

e:

and pressing enter. Then, you’d type

xcopy /s "C:Documents and Settings"

Rather than changing to the E drive, you could instead supply the path as the second argument to Xcopy:

xcopy /s "C:Documents and Settings"  E:

Although you can use Xcopy in a literal fashion, doing so causes problems. For example, user profiles aren't necessarily located in C:Documents and Settings. They might be located in another folder or even on another drive. In the case of Windows Vista, even if you do see a Documents and Settings folder in the root of the C drive, the Xcopy command just given will fail because the folder is actually a junction point that redirects to C:users. In addition, having to manually change the working directory to E each time is easy to forget. In the case of removable drives, just using E: in the command line each time can cause bizarre problems. For example, if you happen to have another storage device already attached to the computer, the next time you connect the USB drive, the drive might be assigned another letter such as F or G. Moreover, the root of the USB drive will then be littered with folders for each user and the All Users profile. If you use the backup drive for more than one computer (e.g., in an office with a couple of peer machines), multiple file collisions can occur. These problems are manageable for an administrator who is consistently methodical, conscientious, and technically literate—but why deal with all these problems in the first place, if you can make the Xcopy operation work around them?

To prevent these problems, you can run a script containing the Xcopy command from the backup target drive. The script can use command shell variables to always correctly specify the user profile path and the backup drive letter, as follows:

xcopy /s "%userprofile%.."  %~d0%computername%users

In the source path (i.e., "%userprofile%.."), the %userprofile% variable is the path to the current user's profile directory—which is C:Documents and Settingsaka on my Windows XP system and D:usersaka on my Vista computer. Adding the .. to the end of the path raises the level by one, to the folder that contains all the user profiles—C:Documents and Settings on my XP system or D:users on my Vista system. Finally, the quotation marks prevent Xcopy from misunderstanding spaces in the path; without them, Xcopy would see the path "C:Documents and Settings" as three separate arguments: "C:Documents," "and," and "Settings."

In the target (i.e., %~d0%computername%users), the %~d0 is a batch parameter. (For more information about batch parameters, see the Microsoft Windows XP Professional Product Documentation article “Using batch parameters” at www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/percent.mspx.) Within a command shell script, arguments to the script are referenced by % followed by the numbers 0 to 9. The first argument, %0 (which a script always includes if it’s running), is the script’s own name—in this case, xbackup.cmd. Inserting ~ alerts the script to subsequent modifiers. The "d" modifier stands for drive. So what %~d0 translates into is "give me the drive portion of my full name." Thus, the script will always back up to the drive where it resides. If you're simply using this tool as-is to perform backups, note that you must copy the script specifically to the drive used for backup. If you're using a removable USB drive for backup, you must copy the script to that drive before running it.

The %computername% portion of the target just uses the computer's name as a top-level folder for the backup. If you have a couple of systems on a small peer network to back up, you won't have any confusion about where a particular user folder resides. The users on the end provides one more level of organization for copied files; all the user folders are clustered together in it. When I back up my test network, which includes PCs named XP1 and Vista2, I end up with the folders XP1 and Vista2 on the root of the backup drive.

An important bit to not forget is the trailing in the target path. If you don't have it, the first time you back up, Xcopy will ask whether users should be a file or a folder. An alternative to using is to add the /i switch to the Xcopy command line. However, I prefer the trailing because it's slightly more compact.

Differential Backups
Completely copying a directory tree is no fun, even with a simple command line. It's time consuming, it’s CPU intensive, and it causes wear and tear on hard drives over time. The bulk of user data files on a system tend to be static; since they don't change, they don't need to be backed up again.

The Xcopy command has a /d (for date) switch. I won't go into the details of using a specific date with this switch, because its basic form—just the /d alone—provides a simple way to minimize backup work. Simply add /d to the backup command:

xcopy /s /d "%userprofile%.."  %~d0%computername%users

The /d switch tells the script to copy files only if they are newer than the file they would overwrite. The first time you run the script, there are no files to overwrite, so everything is copied. On successive uses, Xcopy compares the file dates before doing anything, and skips copying if the file on the backup target is as new as the one on the PC.

In my experience, this switch is the crucial feature that makes Xcopy a viable backup tool. After you perform the initial backup, successive backups are extremely quick and nondisruptive.

Note that even if you delete or rename files on the source drive, they will remain on the backup. This can be an advantage if you accidentally delete an important file or if you need a previous version of a file that you've renamed. However, the amount of data on the backup drive will grow over time.

Additional Options
You can optimize certain interaction details for general backups. For example, Xcopy will fail and exit if it encounters an error because of a file it can’t copy. In general, this problem won’t occur with normal user documents; even if a file is open, Xcopy will work as long as it doesn't encounter the file while it’s being written to. Adding the /c (for continue) switch tells Xcopy to proceed with the rest of the backup, skipping the locked file. For unattended use, this switch ensures that the backup operation works properly. If you're watching the backup when a locked file is encountered, you'll see a sharing violation error in the script's console window. You can then shut down applications that might be interfering and rerun the backup. If you’re using the /d switch, the repeat backup will be only for the affected files. Certain system files simply can't be backed up because they're always in use (e.g., registry hives).

By default, Xcopy prompts you before overwriting existing files. Because you clearly do want to copy changed files, you need to suppress this prompting. Adding the /y (for yes) switch to the Xcopy command causes files to be automatically overwritten.

Finally, Xcopy displays the full path to every file it copies. This can be useful in some cases if you're watching the job, but if you're trying to run it as an automatic backup, the scrolling output can be annoying. The /q (for quiet) switch suppresses normal output. You’ll still see warnings for sharing violations, and at the end of the process Xcopy will tell you how many files it copied.

File Verification
Older versions of Xcopy’s documentation for MS-DOS (the text-mode OS, as opposed to the cmd.exe shell) state that if you use the /v switch, Xcopy verifies each file written to make sure it’s identical to the read file. As a result, many Microsoft OS veterans (myself included) habitually use the /v switch in all Xcopy operations. However, the MS-DOS documentation isn't accurate; all the /v switch does in MS-DOS is test whether the written file is readable (e.g., whether the sectors the file was written to are good disk sectors). In any case, the XP Help file for the shell commands (%windir%helptcmdcs.chm) clearly states in Xcopy's remarks section: "/v: Windows XP does not use this command. It is accepted only for compatibility with MS-DOS files."

The Complete Script
The complete xbackup.cmd script comes down to one line:

xcopy /s /d /c /y /q "%userprofile%.."  %~d0%computername%users

If you want the script to be more compact, you can glob the switches /s /d /c /y /q into /sdcyq:

xcopy /sdcyq "%userprofile%.."  %~d0%computername%users

Xcopy has several additional options that I haven't discussed. For example, you can include hidden and system files with the /h option (although you’d probably want to also use the /exclude switch, to avoid backing up the enormous quantities of temporary files that users tend to accumulate). For information about additional options for extending the xbackup.cmd script, see Xcopy’s Help files (xcopy /?).

When to Use Xcopy
Although using Xcopy isn’t a substitute for a real backup solution on a network, it can provide extremely simple insurance for systems where user-critical data isn’t already protected by backup infrastructure. My motivation for developing the xbackup.cmd script was systems I encountered where traditional backups simply didn't take place. By reducing the backup task to simply attaching a backup device and clicking a script that incrementally backs up—no installation and no choices involved—xbackup.cmd reduces the work to a bare minimum. The script also works as a handy tool for quickly capturing data if you know a system is going down and you don't have time to check for backups. In situations where centralized solutions aren't getting the job done, a simple script such as xbackup.cmd can be an effective tool to prevent the loss of important data.