Re: Beware 32-Bit Ghost v11.5 on GPT Disk

Paul <[email protected]>
Newsgroups alt.comp.microsoft.windows,alt.comp.os.windows-11
Organization A noiseless patient Spider
Message-ID <[email protected]>
On Mon, 11/10/2025 1:03 PM, Java Jive wrote:
> On 2025-11-04 14:40, Java Jive wrote:
>>
>> I was using Ghost v11.5 32-bit in a 32-bit Win PE environment to make the backup images, and it was failing.
> 
> And, JFTR, I've now proved that the 64-bit version fails in the same way.  
> Both seem fine with MBR partitioned disks, but with GPT partitioned disks
> both fail in the same sort of way that was previously described.

The AI could find a web page (AOMEI) that claimed Ghost could
not handle GPT but AOMEI could. A Google couldn't even dig up that
much info.

Absolutely no result, looked like a spec sheet for Ghost.
Whatever properties Ghost had, they have gone to the grave with it.

The Macrium idea should work. It can do some basic things like
back up NTFS, FAT32, and EXT4. And it can do that in smart mode
(does not copy white space).

*******

If you use "dd" to do the backup, that copies white space.

White space can be cleaned with this, prior to a "dd" run.
The zerofree utility can be used to clean an EXT4 (check
ubuntu synaptic package manager).

 https://learn.microsoft.com/en-us/sysinternals/downloads/sdelete

    sdelete64 -z C:       # Does not affect C: files, zeroes out white space.
                          # This makes a "dd" of C: easier to compress.
                          # (Would need Administrator to mess with the MFT.)

To clean an EXT4, you boot your Linux LiveDVD so the partition
needing the treatment is at rest and not mounted. We don't know
if this is absolutely the best method, but it is the method on offer.

    sudo zerofree -v /dev/sdb1    # clean white space with zeroes
                                  # /dev/sdb1 must not be mounted for this to work
                                  # On a GPT disk, the slash might be /dev/sdb2

After you have wasted a lot of time "conditioning" a disk, you can
waste more time doing a dd of it. The advantage of the method, is that
the method is so simple, it cannot fail to restore to the same disk later.

Here are my notes when I was puttering around. To show some amount of savings.

laptop2014Apr.dd      raw backup            320,072,933,376 bytes
laptop2014Apr.dd.gz   gzip -1                80,343,060,250 bytes    about 30MB/sec
laptop2014Apr.dd.7z   -maximum, 2 core       64,102,244,206 bytes    26hr 48min (~4.5MB/sec ?)

new.c                 RLE block compression 123,862,960,640 bytes    90MB/sec roughly, 0:50:21
laptop2014Apr.dd.sparse  zero block removal  64,057,409,123 bytes    9hr 50min
laptop2014Apr.dd.rle.7z  true RLE removal    64,905,359,074 bytes    10hr 12min

The marvel here, isn't the result, it's how patient I was to be doing this :-)

That's because the compression was done on my old Core2Duo 3GHz.

Macrium seems easier somehow. Make a Macrium Rescue CD when it prompts you.

    Paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.