ntfsclone

mount -t ntfs -o loop ntfsclone.img /mnt/ntfsclone

Windows Cloning

If you want to copy, move or restore a system or boot partition to another computer, or to a different disk or partition (e.g. hda1->hda2, hda1->hdb1 or to a different disk sector offset) then you will need to take extra care. Usually, Windows will not be able to boot, unless you copy, move or restore NTFS to the same partition which starts at the same sector on the same type of disk having the same BIOS legacy cylinder setting as the original partition and disk had. The ntfsclone utility guarantees to make an exact copy of NTFS but it won't deal with booting issues. This is by design: ntfsclone is a filesystem, not system utility. Its aim is only NTFS cloning, not Windows cloning. Hereby ntfsclone can be used as a very fast and reliable build block for Windows clonning but itself it's not enough. You can find useful tips following the related links on the below page
http://wiki.linux-ntfs.org/doku.php?id=ntfsclone

Sparse Files

A file is sparse if it has unallocated blocks (holes). The reported size of such files are always higher than the disk space consumed by them. The R du command can tell the real disk space used by a sparse file. The holes are always read as zeros. All major Linux filesystem like, ext2, ext3, reiserfs, Reiser4, JFS and XFS, supports sparse files but for example the ISO 9600 CD-ROM filesystem doesn't.

Handling Large Sparse Files

As of today Linux provides inadequate support for managing (tar, cp, gzip, gunzip, bzip2, bunzip2, cat, etc) large sparse files. The only main Linux filesystem having support for efficient sparse file handling is XFS by the XFS_IOC_GETBMAPX ioctl(2) . However none of the common utilities supports it. This means when you tar, cp, gzip, bzip2, etc a large sparse file they will always read the entire file, even if you use the "sparse support" options. bzip2(1) compresses large sparse files much better than gzip(1) but it does so also much slower. Moreover neither of them handles large sparse files efficiently during uncompression from disk space usage point of view. At present the most efficient way, both speed and space-wise, to compress and uncompress large sparse files by common tools would be using tar(1) with the options -S (handle sparse files "efficiently") and -j (filter the archive through bzip2). Although R tar still reads and analyses the entire file, it doesn't pass on the large data blocks having only zeros to filters and it also avoids writing large amount of zeros to the disk needlessly. But since R tar can't create an archive from the standard input, you can't do this in-place by just reading R ntfsclone standard output. Even more sadly, using the -S option results serious data loss since the end of 2004 and the GNU R tar maintainers didn't release fixed versions until the present day.

The Special Image Format

It's also possible, actually it's recommended, to save an NTFS filesystem to a special image format. Instead of representing unallocated blocks as holes, they are encoded using control codes. Thus, the image saves space without requiring sparse file support. The image format is ideal for streaming filesystem images over the network and similar, and can be used as a replacement for Ghost or Partition Image if it is combined with other tools. The downside is that you can't mount the image directly, you need to restore it first. To save an image using the special image format, use the -s or the --save-image option. To restore an image, use the -r or the --restore-image option. Note that you can restore images from standard input by using '-' as the SOURCE file.

Metadata-only Cloning

One of the features of R ntfsclone is that, it can also save only the NTFS metadata using the option -m or --metadata and the clone still will be mountable. In this case all non-metadata file content will be lost and reading them back will result always zeros. The metadata-only image can be compressed very well, usually to not more than 1-8 MB thus it's easy to transfer for investigation, troubleshooting. In this mode of ntfsclone, NONE of the user's data is saved, including the resident user's data embedded into metadata. All is filled with zeros. Moreover all the file timestamps, deleted and unused spaces inside the metadata are filled with zeros. Thus this mode is inappropriate for example for forensic analyses. Please note, filenames are not wiped out. They might contain sensitive information, so think twice before sending such an image to anybody.

Clone NTFS to the non-existent R FILE . If FILE is '-' then clone to the standard output.

Clone NTFS to R FILE , overwriting if exists.

Save to the special image format. This is the most efficient way space and speed-wise if imaging is done to the standard output, e.g. for image compression, encryption or streaming through a network.

Restore from the special image format specified by SOURCE argument. If the SOURCE is '-' then the image is read from the standard input.

Ignore disk read errors so disks having bad sectors, e.g. dying disks, can be rescued the most efficiently way, with minimal stress on them. Ntfsclone works at the lowest, sector level in this mode too thus more data can be rescued. The contents of the unreadable sectors are filled by character '?' and the beginning of such sectors are marked by "BadSectoR\0".

Clone ONLY METADATA (for NTFS experts). Moreover only cloning to a file is allowed. You can't metadata-only clone to a device, image or standard output.

Ignore the result of the filesystem consistency check. This option is allowed to be used only with the --metadata option, for the safety of user's data. The clusters which cause the inconsistency are saved too.

Forces ntfsclone to proceed if the filesystem is marked "dirty" for consistency check.

Show a list of options with a brief description of each one.

ntfsclone --overwrite /dev/hdc1 /dev/hda1 Save an NTFS to a file in the special image format: