In message , Paul
writes:
J. P. Gilliver (John) wrote:

I can't think of a good reason for making separate images for each
partition, _if_ you're anticipating restoring the original
configuration anyway. Or, for that matter, if you aren't - though in
that case, I'm not sure I'd image some of them at all. But I'll be
interested to see others' answers to your question!

That's to control "fault size".

If you have a large disk, you put all the partitions in
one .mrimg, all it takes is one error to break the "Verify".

Separating the partitions, backing up one at a time,
each .mrimg has a copy of the MBR partition table, so

I didn't know that; thanks. So if you restore an image that contained
just your D: partition, say, the MBR is refreshed?

you should try to keep a backup set "consistent" in
terms of the partition structure. While it's not
the end of the world to have modified something, I
don't know if there are any corner cases you might
care about.

You could probably afford to put several 20GB partitions
into one .mrimg.

But if the partitions are 2TB and take half the day to
write, chances are those should be done individually.
Then if one is ruined, the others might not be ruined.

I definitely take your point there! I image my C: and any hidden
partitions, which comes to a few tens of GB; for my data partition, I
copy, rather than imaging - I use synctoy. So that I could - though have
never had to - access individual files without needing the
image-unwrapper (such as Macrium); and, also, your fault size limit
principle, of not putting all eggs in one basket. (I'd rather not image
C: either, but the practicalities - I think started as an antipiracy
measure, but developed to include lots else since - mean imaging is the
only practical backup for most of us.)

I haven't researched what mechanisms exist to "step over"
an error. Presumably part of the backup operation, is
writing out clusters in cluster_order. At the end of the
backup is some sort of directory structure (because there's
a delay at the end, implying something is going on when

I'd noticed that delay - hadn't occurred to me that it might be for that
reason though!

it hits 100%). If some clusters were damaged, the restore
process should be able to consult the directory structure
and say what is damaged. But it didn't work that way for
me when I had a couple bad .mrimg files. The restore
just stopped. (The bad files were caused by bad RAM, not
[]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Odds are, the phrase "It's none of my business" will be followed by "but".