Thread: Disc imaging
View Single Post
  #21  
Old May 19th 18, 08:55 PM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Disc imaging

Ed Cryer wrote:
...w¡ñ§±¤ñ wrote:
Ed Cryer wrote:
I like safety in my backups. So I regularly do both a System image
with Win10's Win7-style app, and then a Macrium Reflect one.

I did two today; Win10 took almost 2 hours, Macrium took 19mins.

1TB spinning HD, C partition occupies it all, apart from a few small
ones for reset etc. Which means that Macrium had even more to write.

Why is this? Why does Windows take so long? It's not doing anything
more than Macrium, and, in addition, it comes from MS themselves, the
creators of this system, the supposed connoisseurs.

Ed


The Win10 included app was designed and pretty much unchanged for much
older o/s than Win10.

Imo, you'd be better off to discontinue use of the MSFT ancient 'tool'
and make 2 Macrium backups if no other software is readily available.
- my personal approach is create 'duplicate time' images. One with
Acronis True Image and another with Macrium.




I've never had Macrium let me down; never, over many years. Take an
image, restore it, I've restored umpteen times.
I think I'll just cut the old "tool" (It's slow under Win7 too), and
have just Macrium.

Ed


Macrium can let you down. In an example here, it was bad RAM
in the computer, that corrupted the .mrimg on writes.
The data was being corrupted, after the step where
Macrium computes the checksum/hash, as the data was headed out
to the destination disk.

The build-in verify caught the issue some months later.
I was scanning my collection, looking for just the right
MRIMG and was idly running Verify on them, and two of them
showed up bad, and this was during the time interval where I
detected and corrected a RAM problem in the machine. I
put a whole new set of sticks in the machine, because I
could not fault-isolate to the nearest stick (the problem
would go away, with any config other than four DIMMs in
place). The bad memory was apparently some place the
OS uses for buffers, not in a location that an application
would crash - this gave all sorts of weird symptoms while
using the machine.

And yes, it takes a long time to run a verify, as
it cannot go any faster than the hard drive can go.
If you have a 1TB MRIMG, that will take a while.

The Restore will also stop, if it hits a verify
error during the run. So if you only own *one*
image, and are restoring over top of something,
this behavior should give you pause. You could
be left with *nothing* if you're not careful.

*******

As for the Win10 version of "Win7 Backup", I don't
recollect seeing a verify function in there. The Win10
version stores one partition per .vhdx file. Maybe I missed
the verify function in there somewhere.

Paul
Ads