J. P. Gilliver (John) wrote:
In message , G. Ross
writes:
[]
Got it hooked up and it works fine for 30% then stops with error Read
Failed. Said was blocked from reading files in root. I disabled
firewall, had already turned off any running programs. Turned off
windows defender and windows firewall and antivirus. It still stalls
at 30%.
What else should I do?

G.Ross

See Paul's reply for if it is failing to read files because there's
something wrong with the disc. If it's just failing because it's trying
to read files that Windows is using, then don't try running it from
within Windows anyway, but boot the system into Macrium from the Macrium
CD, which you have made, haven't you ... (-:

By using VSS shadow copy, it should be able to copy
anything on the hard drive. That's the default method.

It's possible if you were doing something to files during
the quiescence period (the ten seconds during which a VSS
shadow copy is prepared), you have the possibility of
capturing the old version of a file or the new version
of the file. You'll still capture something.

Any files created after a VSS snapshot is taken, are written to
disk, but are not backed up by Macrium. They will be picked up
in the next backup however. Just as a file created a day
from now, would be picked up in a backup made a week from now.

If there is a known subsystem that cannot be quiesced, there should
be a VSS failure message indicating no provider is available.
For example, if your desktop machine was running a Microsoft Exchange
server, I wouldn't expect that to end well. There are some items
that need more research, when it comes to configuring backups
for them.

For desktops, this is normally pretty easy and there are enough
provider types to handle everything for you.

And there's no difference between cloning and imaging. They
can both use VSS.

If VSS is unavailable (you trashed it on purpose), the backup
software will try to use PSS (PS Snap), but any busy files
are likely to cause a problem. PSS would be acceptable for
non-OS drive copies, as an example (where the files are normally
"not busy").

If there's a good reason for a copy to not be possible,
an error message should indicate as much. If something
just stops dead or rails, suspect hardware.

And when problems like this arise, it's not a time for a lot
of experiments. If the cloning tool has an option to "ignore
bad sectors", that's about as good as gddrescue, and may be
quicker to implement. If the cloning still fails, now
you're taking a risk by booting your Linux OS drive and
running gddrescue from there. I had a case once, where turning
off the power, meant the hard drive did not start on the
next power cycle, and 40GB of data was gone. That's how suddenly
it can happen with known badass disk drives (Maxtor 40GB). I
tried to leave the power up as long as I could, took the chance,
and lost. The drive could no longer be seen in the BIOS
or the OS. There were no burn marks or visible
symptoms (some failures back then, there was a burn
mark on the motor controller IC).

In 2018, we can use a USB stick with Linux on it, so
the power doesn't have to be cycled. If the drive is
SATA, there's no hardware RESET signal, so the SATA drive
will be unpreturbed by your OS change. If the drive is
IDE ribbon cable type, the cable has a RESET signal,
and during RESET, the Service Area is reloaded and
the CPU on the disk drive reboots. And in that case,
you're taking as much risk with the IDE drive as you
would by power cycling it. SATA is a little better, in
that you can change OSes, without the drive spinning
down.

Paul