Micky wrote:


Not to me. There's no reason any of those methods can't be set up in
advance, put in a bat file if needed, put on the scheduler and run
automatically. In fact I've already done that.

Related to what you have written below: I've already gathered together
almost all my data, except my Firefox profiles, and soon I'll include
them and a couple other areas, so I'll have almost all files that
change, so I can run the data backup quickly, either to a separate
data backup partition or to the clone partition, or usually, both.

So the question remains, is there any way that updating specific files
in a clone will take away the clone's bootability?

Isn't the bootability in the boot sector and one or two other areas
that don't get changed during a file backup? Not in any file as
such?

Looking at it the other way, are there any files that should not be
backed up, not because it's a waste of time like the swap file or the
web cache but because they will mess up the bootability of the clone
drive? Because if there are, two of my back-up choices above allow
the user to make exceptions.

And if the bootabilty is undamaged, how come I don't see this method
suggested more often?

P.S. And these data-only backups have the advantage that they don't
require rebooting via a CD or external drive, and they still update
the clone, so that later no restore is needed. If there is a problem,
all one has to do is just use multi-boot to boot the other drive, or
use a CD to change which physical drive is the boot/system drive,
either of which leaves the original possibly malfunctioning drive as
it was when it broke.

This doesn't work for laptops but in a desktop if the clone is the
second harddrive, it also allows for testing the clone without risking
hosing the "C: drive".

Doesn't it?

Micky

C:\Windows has a bunch of stuff.
C:\boot\BCD perhaps, on a modern OS.
Maybe a few things like winload.exe or winload.efi.
But for the most part, I think you already know
where the OS portions are.

You've got the Program Files folder. There's AppData.
That stuff affects usability, but not booting. Maybe
if you trash the user-specific profile files, that
stops the desktop from appearing. (ntuser.*)

But the basic boot stuff is far enough away from
where you'd be normally working, you wouldn't be
in danger of screwing it up.

You can have permission issues.

You can have file system objects that resist handling.
Such as junction points that don't stand out
like they should.

And rather than "bootability" being an issue, it's
an issue with making up the right sort of command line
parameters to xxcopy.

For example, Robocopy has a "don't go down Junction Points"
command line argument, which is part of dealing with NTFS.
It's rather like a golf course, filled with sand traps,
trees, and gophers. It sounds like you're on the fairway
right now, but you could easily go off into the woods.

Paul