Post by Newyana2I have copies of my disk images on data partitions. But
I also back them up elsewhere. People have different methods.
The final test: If you lose your computer somehow, do you
still have backup? Do you have an ISO that can go onto
a repaired or replaced computer? If not then it's just a home
made RAID array.
That's an important distinction. When disk image backup
became popular, a lot of people were buying Acronis for $100
because it was no-brain backup. But it wasn't true disk image
backup. For that people need to understand at least a little of
OSs, partitions and now EFI.
An old timer like yourself, might well think of a disk image as this.
A dd.exe dump. Just a bunch of sectors. Yes, this is definitely a "snapshot in time".
This could be managed as a "cloning circus". Say, two 1TB drives, one an
exact copy of another, or, a 2TB drive with a compressed copy of big.img file
as a "collection of Full disk images". Which could be decompressed and "cloned"
to the second 1TB disk on demand (say gzip piped to dd.exe for re-constitution).
This is what we did, before we had backup software.
+--------------------------------------------------------------------------------------+
| Big Bag of Bytes |
+--------------------------------------------------------------------------------------+
Some of the old timers used to back up individual partitions with dd.exe . This
requires some knowledge of the "brittleness" of the approach. dd.exe has no
"resize" capability.
*******
Most backup softwares have a basic understanding of the component parts of the disk.
For example, the Disk Management tool that comes with windows, is not complete enough
for real disk work. That's a bit dangerous, in a discussion environment like the
one we're in right now. I have to explain to people, on occasion, why the partition
numbering is fucked up in the Windows view.
[Picture] How Windows views the drawing which follows
Loading Image...
This is the level that Macrium understands it. Missing from the diagram (to avoid confusion),
are the two GPT 64KB partition tables. The secondary GPT table is up the end, no more than
one cylinder from the end of the disk drive. When you move a GPT disk between different
sized hardware, the secondary GPT serves as a "trap for the unwary". If you just dd.exe a
1TB disk to a 2TB disk, the secondary partition table is in the wrong location.
Notice how Macrium knows there is an MSR (a partition with no file system), and Macrium
makes a copy of (2) using dd.exe . Linux Gparted, refuses to touch (2), and (2) is
pure misery in terms of an item placed on disk drives (certain GParted manipulations
aren't going to work on the left side of the disk). It's nothing short of "stupid".
the person who thought of this should be fired. "Make a file system, or please be fucking off"
-- that's the rule. The GPT partition tables are bad enough as a feature, but at least
their purpose and layer in the diagram is understandable.
1 2 3 4 5 6 7
+---+-------+---------+--------+--------------+---------+----------+-------+-----------+ The two 64KB GPT
|MBR| bttrk |ESP 100MB|MSR 16MB| C: 118.7 GiB |Rec 649MB| H: 129GB |Rec 1GB| S: shared | partition tables
+---+-------+---------+--------+--------------+---------+----------+-------+-----------+ are not shown here.
|1 megabyte | Grrr^^^^
I can see some of this, in a disktype.exe dump. This records the view in both MSDOS legacy
terms, as well as GPT terms. Like a Macintosh hard drive, a Windows GPT drive has a
"get off my lawn" warning in the form of 0xEE. The 0xEE partition tells a legacy OS
that "there is no room to be adding partitions, now go away". This prevents a legacy
OS from ruining a GPT disk.
--- /dev/sda
Block device, size 3.639 TiB (4000787030016 bytes)
DOS/MBR partition map
Partition 1: 2.000 TiB (2199023255040 bytes, 4294967295 sectors from 1)
Type 0xEE (EFI GPT protective)
GPT partition map, 128 entries <=== 64KB storage used
Disk size 3.639 TiB (4000787030016 bytes, 7814037168 sectors)
Disk GUID CD4D6752-BAC8-B446-90A7-662721F0DD2D
Partition 1: 100 MiB (104857600 bytes, 204800 sectors from 2048)
Type EFI System (FAT) (GUID 28732AC1-1FF8-D211-BA4B-00A0C93EC93B)
Partition Name "EFI system partition"
Partition GUID BE145A8D-FC87-9B45-AFB1-8959CB4D727A
FAT32 file system (hints score 4 of 5)
Volume size 96 MiB (100663296 bytes, 98304 clusters of 1 KiB)
Partition 2: 16 MiB (16777216 bytes, 32768 sectors from 206848)
Type MS Reserved (GUID 16E3C9E3-5C0B-B84D-817D-F92DF00215AE)
Partition Name "Microsoft reserved partition"
Partition GUID B000A1BB-661C-7541-AF97-88BB60627F66
Partition 3: 118.7 GiB (127481675776 bytes, 248987648 sectors from 239616)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "Basic data partition"
Partition GUID 6A16D60B-3608-4140-891C-792DF2C72ABD
NTFS file system
Volume size 118.7 GiB (127481675264 bytes, 248987647 sectors)
Partition 4: 649 MiB (680525824 bytes, 1329152 sectors from 249227264)
Type Unknown (GUID A4BB94DE-D106-404D-A16A-BFD50179D6AC)
Partition Name ""
Partition GUID B15ABCC3-F0C5-AE4D-838C-751EF868E237
NTFS file system
Volume size 649.0 MiB (680521728 bytes, 1329144 sectors)
Partition 5: 129.0 GiB (138510690816 bytes, 270528693 sectors from 250556416)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "Basic data partition"
Partition GUID BC694DBD-BB6F-124F-B804-F32C6B9E828C
NTFS file system
Volume size 129.0 GiB (138510690304 bytes, 270528692 sectors)
Partition 6: 1.001 GiB (1074790400 bytes, 2099200 sectors from 521086976)
Type Unknown (GUID A4BB94DE-D106-404D-A16A-BFD50179D6AC)
Partition Name ""
Partition GUID CF6B38AF-C016-3F48-A84B-B310CC27C8E8
NTFS file system
Volume size 1.001 GiB (1074786304 bytes, 2099192 sectors)
Partition 7: 682.0 GiB (732331769856 bytes, 1430335488 sectors from 523186176)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "Basic data partition"
Partition GUID DA97834F-DF61-974A-B913-9BD526C13C9A
NTFS file system
Volume size 682.0 GiB (732331769344 bytes, 1430335487 sectors)
Partition 8: unused
When Macrium does a restore, not only does it modify the Partition GUID (aka VolumeID),
it also edits the BCD file (has to find it first!), so that the
disk boots as it did previously. This makes the restored disk,
completely independent of any other disk in the computer (or
at least that's the design intent... YMMV).
Macrium can restore one partition at a time. During restoration,
it can change the size of a partition. I refer to this activity
(what amounts to Partition Management) as a "Drag and Drop Restore",
as it allows you to change the order of the partitions, their size,
their offset, or whatever. Or can re-lay-out the disk drive, during
restoration. I can and have used this, as time consuming as it is.
It's because some Partition Managers are particularly slow at
"doing it their way". For example, Paragon switches to using dd.exe
on some occasions, as part of partition movement. This makes me
more than a little crazy, watching this. Doing dd.exe and moving the
disk heads back and forth a million times, is not so clever.
So while in a light-handed way, this is "disk imaging" (the logical
content of the disk is captured, the boot track is stored), in other
ways it's a partition backup tool. The partitions can also be
mounted for casual examination, or pulling one file out of a 2TB MRIMG.
And, because Macrium has a tick box to "remove restrictions", when
you mount a partition, you can "see everywhere" and go places that
normally would require permissions work to get to. That's how I can
see into places that Everything.exe cannot see!
A number of other commercial products, are like this too. Acronis,
or AOMEI or Easeus, they should all be able to do stuff like this.
I just haven't had the time or inclination to test them.
Paul