BillW50 said:
In my experience, no. Although you can do sector by sector cloning and
then it has to clone everything and that takes longer. Although ignoring
the free space is just as fast as backing up and usually takes less
time. Since the computer doesn't have to work on compression, since
there are none when cloning.
If you clone without considering the white space, there could be
information leakage.
If I was using a software product, which does "intelligent sector copy",
I would zero the destination disk first.
dd if=/dev/zero of=/dev/sda
That overwrites the destination disk. Later, the unused sectors
will be full of zeros.
Acronis Clone step...
That step, copies only the occupied sectors, from one disk
to another. It does not define the unused sectors. A forensic
expert could sift through your unused sectors, looking for
old files on the destination disk and so on.
So no, strictly speaking, an "intelligent" clone operation
(which takes less time), isn't complete. It leaves old sectors
around, in the white space areas, while copying the active files
from the source disk. Depending on what you're doing, and
who you are, this could be a liability.
I know at least a couple people in these newsgroups, who
are paranoid enough to worry about this. For the rest,
the distinction is a "don't care" situation.
If you clone this way, it copies all the sectors, and
the only information leakage, is whatever illicit content
is on the white space of the source drive.
dd if=/dev/sda of=/dev/sdb
And that example is not proper Windows syntax, but is
intended to illustrate what I'm talking about. That's
shorthand for a full, disk-to-disk copy, of every sector.
You can easily overwrite the white space on your partitions
with zeros, even on a running disk, so if you're worried about
the undeleted sectors on a drive, they can be cleaned up.
This is not as good as using Heidi Eraser (as some of your
files could actually be stored in the $MFT), but it's
a big improvement over doing nothing.
dd if=/dev/zero of=E:\bigfile.bin
What that would do, is run until all free space
is full on E:. Then, after the command has failed
(because it "ran out of space"), you drag the new
E:\bigfile.bin to the Trash. The end result, is
minty fresh (zeroed) white space on the E: partition.
That method works fine for NTFS.
For FAT32, it requires a small obvious modification.
I have a script to overwrite the white space on my
FAT32 partition. Each line zeros out a ~4GB chunk
of white space. You need to create enough of these,
do finish the job (i.e. run until partition is "full").
dd.exe if=/dev/zero of=E:\big01.dd bs=65536 count=65535
dd.exe if=/dev/zero of=E:\big02.dd bs=65536 count=65535
....
I zero white space on occasion, as a step before making
a clone copy of a disk drive (as a means of backup). It
aids in the compression step(s) that comes later.
Most of my backups here, are efficient .mrimg ones.
But I also happen to make (infrequently), full disk
clone-style images. Just... in... case...
And the white space on those clone-style images,
is minty fresh and full of zeros. It means my
imaged drive, can be stored in about 60GB of
space after compression. And can be restored
from Linux (which has a copy of 7ZIP to do
the decompression step in a pipelined command).
Paul
