From Newsgroup: alt.comp.os.windows-10

On 2025/7/4 9:38:37, Carlos E.R. wrote:
[]

So, when I create backup images from windows, I will keep using dd+compression. No fancy stuff. Some *zilla stuff. Clonezilla? No,
something else :-?

When I create a backup image, I boot from a bootable Macrium DVD I made
- it isn't "fancy". (I think the other similar - Acronis, EAseus, etc. -
are similar.) [For Windows 7 and earlier, Macrium 5 or 6 - either will
do - will actually fit on a mini-CD, but won't work with recent Windows
10.] Macrium lets one choose (from a very simple 3-option dropdown) the
level of compression - none, moderate, or more - defaulting to the
middle one.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

One of my tricks as an armchair futurist is to "predict" things that
are already happening and watch people tell me it will never happen.
Scott Adams, 2015-3-9
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Fri, 7/4/2025 8:40 PM, J. P. Gilliver wrote:

On 2025/7/4 9:38:37, Carlos E.R. wrote:
[]

So, when I create backup images from windows, I will keep using dd+compression. No fancy stuff. Some *zilla stuff. Clonezilla? No, something else :-?

When I create a backup image, I boot from a bootable Macrium DVD I made - it isn't "fancy". (I think the other similar - Acronis, EAseus, etc. - are similar.) [For Windows 7 and earlier, Macrium 5 or 6 - either will do - will actually fit on a mini-CD, but won't work with recent Windows 10.] Macrium lets one choose (from a very simple 3-option dropdown) the level of compression - none, moderate, or more - defaulting to the middle one.

The Macrium compressor is not much of a compressor.

That's because it can't afford to burden the user
with a slow backup. I don't know if it is stated somewhere,
exactly what compressor it uses.

And Macrium won't "use all your cores" either. It's
not that kind of program.

The Windows 7 Backup, is potentially "the fastest backup going".
But when you go to restore, does it always work ? Dunno.
I don't think the Windows 7 Backup program uses checksums,
and there is no "Verify" for the VHD/VHDX containers it collects.
I've never spotted any metadata that suggests otherwise.

*******

"dd" as a backup works, but you have to be patient.

I think the fastest "useful" backup I've made on Macrium,
is one minute thirty seconds. Whereas a "dd" could take
five hours. That's the definition of patient.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On 2025/7/5 7:49:45, Paul wrote:
[]

The Macrium compressor is not much of a compressor.

That's because it can't afford to burden the user
with a slow backup. I don't know if it is stated somewhere,
exactly what compressor it uses.

Since I only tended to backup what's needed to restore a working system
(C: plus any hidden partitions Macrium finds [I keep all my data -
including downloaded installers - on D:, so C: is just OS plus
_installed_ software), I tended to select no compression (on the basis
one less thing to go wrong), or if not enough space on the backup drive,
the medium compression.>

And Macrium won't "use all your cores" either. It's
not that kind of program.

The Windows 7 Backup, is potentially "the fastest backup going".
But when you go to restore, does it always work ? Dunno.
I don't think the Windows 7 Backup program uses checksums,
and there is no "Verify" for the VHD/VHDX containers it collects.
I've never spotted any metadata that suggests otherwise.

Since I was never quite sure what the inbuilt backup backed up - e. g.,
how much work I'd need after a restore to get things back how I wanted
them - I never used it. (I might have once, just to _have_ that sort of backup, but never used what it made.)>

*******

"dd" as a backup works, but you have to be patient.

That's always looked too complicated for simple me (despite help from
those like yourself who try to explain it to us). Macrium Free _seems_
not too bad - though of course I know it's to some extent a matter of familiarity.>

I think the fastest "useful" backup I've made on Macrium,
is one minute thirty seconds. Whereas a "dd" could take

Wow! I think my last (remember, only a small C: and some tiny
partitions), was about a quarter of an hour; I presume yours was to an (internal?) SSD of some sort. (Mine was to an external spinner, albeit
via USB3.)

five hours. That's the definition of patient.

Indeed! I remember once _restoring_ (for a friend) from a Macrium DVD
took an unconscionable time to _boot_ (half an hour maybe? - With long
pauses when it didn't seem to be doing anything), though once it _had_
booted, the actual restore was fine and not too long.>

Paul

John (G.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

When I'm good, I'm very good. But when I'm bad - I'm better! (Mae West)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Sat, 7/5/2025 11:52 AM, J. P. Gilliver wrote:

Indeed! I remember once _restoring_ (for a friend) from a Macrium DVD took an unconscionable time to _boot_ (half an hour maybe? - With long pauses when it didn't seem to be doing anything), though once it _had_ booted, the actual restore was fine and not too long.>

    Paul

John (G.)

The Macrium ReScue OS, is stored as a .wim file, and it is
loaded as a RAMDisk. when booted, the OS partition is called
X: which leaves the letter C: available if it were needed to
some purpose. It should be a "straight read of 300MB of material",
followed by the usual Microsoft code load behavior.

If you aren't doing anything with the media of importance,
you might notice that ejecting the Macrium OS media, affects
the session not-at-all. That's because the OS is now in the\
RAMDisk X: set up on your machine and references to the boot
.wim are no longer needed..

To restore an MRIMG, I suspect the program starts by examining
some indexes it stored at the end of the session. It has to load
some of that info, before the restore-proper can begin. This is
important if you are restoring and changing the size of the partition
as you restore (making it smaller).

If the MRIMG data being restored is on optical media, that's a
pretty slow source. Once the restore gets going, the reads should
be sequential.

IDK, I don't know if I'm patient enough, to allow a thing like that
to proceed without some optimizing.

I did once test a Windows 7 Backup to DVD media, and the Microsoft
burn utility did not have code for erasing re-writable media. I was
flipping out the DVD, and erasing it with ImgBurn, then popping it
back in so the Microsoft backup code could do its thing. I think it
took me two hours and four pieces of media, and I was fit to be
tied by the time I was finished.

Today, I would think you would need a title similar to
Mother Theresa for attempting such a stunt :-) So so slow.
I could row a boat faster than this.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On 2025/7/6 7:41:52, Paul wrote:

On Sat, 7/5/2025 11:52 AM, J. P. Gilliver wrote:

Indeed! I remember once _restoring_ (for a friend) from a Macrium DVD took an unconscionable time to _boot_ (half an hour maybe? - With long pauses when it didn't seem to be doing anything), though once it _had_ booted, the actual restore was fine and not too long.>

    Paul

John (G.)

The Macrium ReScue OS, is stored as a .wim file, and it is
loaded as a RAMDisk. when booted, the OS partition is called
X: which leaves the letter C: available if it were needed to
some purpose. It should be a "straight read of 300MB of material",
followed by the usual Microsoft code load behavior.

Interesting.>

If you aren't doing anything with the media of importance,
you might notice that ejecting the Macrium OS media, affects
the session not-at-all. That's because the OS is now in the\
RAMDisk X: set up on your machine and references to the boot
.wim are no longer needed..

Useful to know.>

To restore an MRIMG, I suspect the program starts by examining
some indexes it stored at the end of the session. It has to load
some of that info, before the restore-proper can begin. This is
important if you are restoring and changing the size of the partition
as you restore (making it smaller).

If the MRIMG data being restored is on optical media, that's a
pretty slow source. Once the restore gets going, the reads should
be sequential.

No, it was on an external HDD (USB2) [Macrium booting from DVD]. But I'm pretty sure the unconscionable wait was _before_ the restore started
(before it asked us to select which restore file, or something like
that). Before the Macrium screens appeared. IIRR - it was some years
ago. _Might_ have been when the system in question had a slow internal
HDD.>

IDK, I don't know if I'm patient enough, to allow a thing like that
to proceed without some optimizing.

I doubt I could optimise Macrium.>

I did once test a Windows 7 Backup to DVD media, and the Microsoft
burn utility did not have code for erasing re-writable media. I was
flipping out the DVD, and erasing it with ImgBurn, then popping it
back in so the Microsoft backup code could do its thing. I think it
took me two hours and four pieces of media, and I was fit to be
tied by the time I was finished.

I can see that! I've not yet played with rewritable DVD; I remember
rewritable CDs being something of a pain reliability-wise. (I used to
use them in the giant-floppy mode - often proprietary with the drive
drivers in those days! - for transferring between machines [e. g. work
and home].)>

Today, I would think you would need a title similar to
Mother Theresa for attempting such a stunt :-) So so slow.
I could row a boat faster than this.

Paul

(-:
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Sarcasm: Barbed ire
--- Synchronet 3.21a-Linux NewsLink 1.2