philo said:
I generally do not use Win7 but my wife does. Yesterday I decided to
back up the data on her machine to an external 1Tb drive.(about 140gigs
of data)
I was appalled that as soon as I initiated the copy process, Windows
went into a "calculating" process that took something like 20 -30
minutes before it actually started copying the data. If I ever need to
do another backup, I was wondering if there is a way to improve this
undesirable situation.
Years ago I experienced something similar (but a bit worse) on a Vista
machine I was working on...and was shocked to see the same "foolishness"
carried over to Win7.
FWIW: On my own machines running either Linux or XP...
if I need to copy files...the copy process simply starts at once
as one would expect.
I did a Google search and the problem is well documented...
the solutions I saw suggested a 3rd party "fast copy" utility.
If that's the best solution...any suggestions on which utilities
actually work.
Windows 7 has a System Image function which is about as fast
as you can get the data off the disk.
The System Image function built into Windows 7, stores data
in a .vhd file. And Windows can mount those. With the
right tool, it might be possible to even mount one of
those in WinXP. As another usage scenario, when I backup
the Windows 7 laptop, I can copy the 26GB .vhd file to
my desktop computer and use VPC2007 and any other OS, to
mount that .vhd as a "second disk" so I can look at the
data as I wish.
System Image is VSS based, so can handle "busy" files on
the source. VSS based copies, basically copy all the busy
sectors on the partition, files or metadata as far as I know.
Any unused sectors should not get copied. Which keeps the
destination image file at a reasonable size.
Macrium Reflect Free is also VSS based.
Any of these kind of tools, you prepare a "recovery CD",
so you have an OS to boot from if a new hard drive
needs to be put in the laptop, and restored from backup.
The built-in System Image has an item in the menu, to
prepare the recovery CD.
System Image data should be stored on an external disk.
By default, if a week from now you make another System Image,
it overwrites the existing System Image. So that mode of
operation isn't archival (unless you move the first copy
out of the way). There is a second file-by-file backup
feature in Windows 7, which I don't use, which doesn't
require fiddling with, to keep more copies. I would rate
neither method as being strong in terms of managing
the output data.
*******
And I wouldn't do a drag and drop copy, when I have Robocopy.
I run it in Mirror Mode, which wipes anything non-related off
the target. So don't just blindly copy this, without knowing
what it does. This is the command I use. I generally check
and recheck the source and target specification, because
bad things happen if you make a mistake! This command copies
all the files off Y: onto F:. If I repeated this a week from
now, unchanged files should not be copied again. But I don't
typically use it that way.
robocopy Y:\ F:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v /log:y_to_f.log
That is mainly for non-system partitions. I expect it runs
into the usual "busy file problem" if you did it with entire C:
as the source. But then, any VSS based solution (like
System Image), would solve that problem.
As far as I know, Robocopy uses async transfer, meaning
it can read and write simultaneously, which is most
evident if your source and destination are on different
disk drives. I expect the Windows 7 explorer copy would
be doing that as well. On some of the older OSes, the
file system is async capable, but hardly any utility
ever utilized the capability, choosing to "block" instead
and do sync I/O.
A fairly recent version of Robocopy should be already in
the OS. On older OSes, it was a separate download. And
for older OSes, it's preferable to use a certain minimum
version of the program. Wikipedia has details.
*******
The "preparing in advance" phase of file copying, can be
done in an attempt to compute the exact size of space
needed on the destination device. Other than that, I
don't know what purpose would be served in looking ahead.
In theory, mapping all busy clusters required in the copy
operation, might allow optimization of head movement, but
I've never seen any evidence that any command does that :-(
File by file copy... seems to be handled, file by file in
terms of updating structures. Perhaps that's for file
system integrity reasons.
On other platforms, the command can simply fail when the destination
runs out of space, leaving the copy "half done". And as far
as I'm concerned, that's a perfectly acceptable outcome.
I share your lack of amusement, waiting for Windows to start
copying. Same thing, with deleting a few hundred thousand files.
Quite annoying. It's one of the reasons I don't use the waste
basket to "clean off a partition", preferring to reformat as
it's faster. For example, fat32formatter that I use, can
blank a partition in around 1 second. As it just writes a new
FAT. That's preferable to waiting and waiting, when you
want to clean off all the files.
Paul
