How do I clone/backup a hard disk under Windows?

Copyright 1998-2000 The Navas GroupSM, All Rights Reserved.
Permission is granted to copy for private non-commercial use only.

Posted as <>. 

NOTE: This information was compiled by the author and is provided as a public service. The author is not responsible for any errors or omissions, or for any consequential problems that might result. USE AT YOUR OWN RISK.


Important Notes:


XCOPY/XCOPY32, Windows Explorer, PKZIP, WinZip, CD-R/CD-RW mastering programs, and even most Windows backup programs do not preserve the short file names that are automatically generated by 32-bit Windows for files with long file names. This is a problem because the short form is often stored in the Registry, INI files, and shortcuts, rather than the long form. (Just search your Registry for "~" to check this on your own system.) As a result, when these files are restored, your system may not be able to find them!


For proof, run the following commands (e.g., with a BATch file) in a Windows 95/98 Command Window:
mkdir $$SOURCE
xcopy /s /e /c /r /h /k $$SOURCE $$$DEST\

Then look at the short file names in the $$SOURCE and $$$DEST directories:

 Directory of C:\$$SOURCE
LONGNA~2                 4  12-17-98  8:41a LONGNAME2
LONGNA~3                 4  12-17-98  8:41a LONGNAME3
 Directory of C:\$$$DEST
LONGNA~1                 4  12-17-98  8:41a LONGNAME2
LONGNA~2                 4  12-17-98  8:41a LONGNAME3

If LONGNA~2/LONGNA~3 were registered or otherwise linked, changing the names to LONGNA~1/LONGNA~2 would break those links, or worse, point to the wrong files -- note that LONGNA~2 now points to LONGNAME3 instead of LONGNAME2!

Why you haven't heard

You may be asking yourself, "if this really is a problem, how come I haven't heard about it before now?" You may be tempted to assume that the problem is rare.
  1. Some people don't have the conditions that can trigger the problem; i.e., they don't have multiple short file names other than those that end in "~1".
  2. There is a chance that new short files names generated during a copy are in the exact same order that they were created on the source, so that they match.
  3. The problem can be hard to notice until a good deal of time has passed; i.e., you may not experience it until you happen to use a particular function in a particular application (e.g., your spell checker mysteriously stops working).
  4. When you do notice a problem, you may not attribute it correctly, particularly if a lot of time has passed since the damage was done. (Many people expect Windows systems to be flaky.)
These last two reasons are why it is not safe to assume that the problem is too rare to worry about -- many people may have been affected, but simply not know what really happened.

Microsoft Knows

Microsoft acknowledges this problem in:

Microsoft actually exacerbates this problem with its own practices by prefixing so many file/directory names with "Microsoft". Here is an actual example of installed Microsoft software:
 Directory of C:\Program Files

MICROS~1       <DIR>        06-16-97  9:52p Microsoft Exchange
MICROS~3       <DIR>        01-06-98 12:27p Microsoft Image Composer
MICROS~4       <DIR>        07-16-98  4:38a Microsoft Chat
MICROS~2       <DIR>        07-16-98  4:38a Microsoft NetShow
MICROS~5       <DIR>        07-16-98  4:38a Microsoft FrontPage Express
MICROS~6       <DIR>        09-03-98  7:20a Microsoft Office
MICROS~7       <DIR>        11-07-98  8:09p Microsoft Games

When these are cloned/restored, the short file names may well get scrambled if the software does not preserve them. This matters because these short file names were stored and used -- here's an example:


(Note that even "Program Files" is a potential problem.)

Cloning Programs

A good solution for disk cloning is to use a special "cloning" program that preserves both long and short file names; e.g., You may be able to get a free cloning utility from your hard disk manufacturer. Possibilities (not all of which have been tested by this author) include:

Other alternatives (not all of which have been tested and verified by this author -- use at your own risk) include:

The following alternatives are not recommended (for the reasons stated):

Important Notes:

  1. Conversion of FAT16 partitions to FAT32 and/or partition resizing may not be supported by some of these utilities. Be sure to check if you need these capabilities.
  2. FAT32 partitions larger than 8 GB with a cluster size less than 8 KB will cause errors in Disk Defragmenter (Defrag.exe) and ScanDisk (Scandskw.exe). See Q229154 "Err Msg: Your Computer Does Not Have Enough Free Memory to Defrag the Drive" and "Scandisk and Defrag give error messages when used on a new hard drive".

Backup Programs

Some Windows backup programs do preserve short file names when you restore from DOS (sometimes called "emergency restore"); e.g., VERITAS Backup Exec Desktop Edition (verified by this author for Version 2). Check to be sure! (These same programs do not preserve short file names when you restore under Windows.)


Another alternative is to use Microsoft's LFNBK utility (included on the Windows 95/98 CD):
  1. Use LFNBK to remove and save all long file names;
  2. clone or backup using only short file names;
  3. and then use LFNBK to restore long file names.
This way the short file names won't change. See "Using the LFNBK Utility for Temporary Compatibility" in "Administrative Considerations for Long Filenames". LFNBK for Windows 95 (not Windows 98) can also be downloaded.

A shareware alternative (not been tested by this author) to LFNBK is DOSLFNBK.


Popular misconceptions:
  1. The right set of command line switches will make XCOPY/XCOPY32 work properly.

  2. In fact there are no switches that correct this problem. (Note that the /N switch wipes out long file names.)
  3. "I used XCOPY/XCOPY32 and didn't have any problems."

  4. See "Why you haven't heard" above.
  5. XCOPY32 behaves differently than XCOPY.

  6. In fact Windows 95/98 XCOPY just launches XCOPY32.

This page has been accessed COUNTER times since September 26, 1999.

Button [The Navas Group home page]

Trademarks belong to their respective owners.