Parted Magic Clone: The Cloner That Never Writes to Your Source

Clone copies a disk, a partition, or an image of either, and it produces evidence that the copy is right. You give it a source and a destination. It makes every technical decision itself, asks for one typed yes, and ends the job with a sealed certificate: both devices’ identities, a digest of every chunk, a Merkle root over all of them, the map of anything that would not read, and the timings.

It is new in this release, it ships inside Parted Magic, and it runs from the same USB stick as everything else.

On This Page

• The one rule: the source is never written
• What it copies, and what it leaves out
• Images: raw, compressed, split
• A different-sized disk
• When sectors will not read
• Verification and certificates
• When the power fails: the journal and resume
• One engine, three faces
• Command-line reference
• Clone filesystem support
• What Clone refuses, in words
• What Clone will not do
• Fleet reporting
• Clone FAQ

The One Rule: The Source Is Never Written

Not one byte, no matter what. The source is opened read-only and stays that way for the life of the job. Every corrective action — filling in a later slice, repairing a filesystem, growing it to fill a larger disk, replaying a dirty ext journal — happens to the copy, after the copy has been read back and verified.

That rule decides the whole design. It is why an unclean ext3 volume is recovered into an overlay rather than fixed in place. It is why a shrink is computed against the read-only original and streamed out already shrunk, instead of being copied and then cut down. And it is why an interrupted job costs you a restart and never bytes: whatever happened, the disk you started from is exactly as you left it.

Clone is not a rescue tool and does not pretend to be one. Reads that keep failing mean the drive is a rescue job, and Clone says so and stops rather than degrading into a poor imitation of ddrescue. Parted Magic ships ddrescue and TestDisk for that work.

What It Copies, and What It Leaves Out

Clone reads the allocation state out of the filesystem itself — FAT12/16/32, exFAT and NTFS cluster maps, ext2/3/4 block bitmaps, XFS, and the partition table with its logical chain — and copies metadata plus allocated data only. Free space inside a filesystem is not read and not written.

Every map is proven against that filesystem’s own counters before it is trusted. A map that disagrees with the superblock by a single block is thrown away, the region is copied in full instead, and the plan says why. btrfs is recognized by name and copied whole on purpose: two maps for it were written, and both produced a volume the kernel would not mount — the second one after btrfs check had called the copy clean. A copy that will not mount is worse than a slow one.

Unpartitioned space is not copied either, beyond what has to be. The partition table, the first 64 MiB ahead of the first partition where boot loaders live, any gap up to 16 MiB, the disk’s last megabyte and any partition Clone does not recognize are all copied verbatim. Larger gaps are skipped, and both the plan and the certificate state exactly how much was skipped and where.

That is Clonezilla’s rule, and it matters more than it sounds. On our own bench disks, 198 of the 235 GiB being moved for one image was unpartitioned space. The same job now moves 37.94 GiB. When you want byte-for-byte anyway — a forensic copy, an unrecognized layout you would rather not have judged — --full-range, or the Copy every byte box in the window, copies every sector including the gaps.

The dirty ext journal, replayed into the copy

An ext3 or ext4 volume that was not cleanly unmounted — a machine that lost power, a snapshot taken while mounted — carries a journal holding committed transactions the filesystem proper has not seen. Every resizer refuses such a volume until e2fsck has replayed them, which is advice you cannot follow on a read-only source or on an image file.

Clone replays the journal itself, the way the kernel and e2fsck do — descriptor, data and commit blocks in sequence, revokes honored, escaped blocks restored — into an overlay on the read-only source. Every read of that volume, the map and the transform and the copy alike, sees the recovered filesystem, and the copy lands clean with needs-recovery cleared and the journal marked empty, so it can be grown or shrunk. The plan says it happened and how many blocks it touched, and the certificate records it. The source is still never written. A journal Clone will not trust — fast-commit, external, damaged — is left alone, the plan says why, and the volume is copied as it is.

Images: Raw, Compressed, Split

The image is raw. The device’s bytes exactly as they are, sparse where nothing was copied — what dd would write, what losetup mounts, what every tool reads, this year and in twenty. No header, no container, no version number. There is nothing to convert, ever.

Compression is on by default and changes none of that. A compressed image is a standard zstd file: frames, one per 4 MiB of the raw image, in order. Decompressed it is the raw image exactly.

zstdcat name.img.zst | dd of=/dev/sdX     # restore with the system's own tools

Nothing in that file is ours. Chunks compress on every core, and empty space costs almost nothing. On FAT32 — the boot stick, most external drives — a file cannot reach 4 GiB, so an image that could is written in numbered parts the way split -d -a 3 names them. cat name.img.zst.* | zstdcat restores the set anywhere, and any single part names the whole set as a source.

Either kind of image is a perfectly good source, as is a raw image written by any other tool.

Reading an image without unpacking it

The frame table — which chunk lives where in the compressed stream — is what lets Clone read any part of an image without decompressing what precedes it, resume an interrupted one, verify it chunk by chunk and repair it. That table lives in the certificate beside the image, and it also rides inside the image itself, in a frame zstdcat ignores, written as soon as the copy completes.

That second copy matters when the certificate has been lost. Before it existed, listing the contents of a 235 GiB image meant a full decompression: 22 minutes, and the free space to hold the result, to produce a directory listing. Images written by other tools, and older ones with no trailer, still read the old way — one pass over the file, slower and just as exact.

A Different-Sized Disk

FAT, exFAT, NTFS and ext filesystems are shrunk or grown in flight. The whole transformation is computed against the read-only source, and the already-resized filesystem is streamed to the destination. There is no copy-then-resize second pass, and no moment where the copy is briefly wrong.

Onto a smaller disk

The table is regenerated for the new size. The partitions carrying a shrinkable filesystem give up the difference in proportion to their free space — a nearly empty one gives most, a nearly full one little, and none is squeezed to the bone. Everything after a shrunk partition moves inward with its contents and its identity unchanged, and its boot sector’s idea of where it lives is updated.

On a GPT disk that is always allowed. On an MBR disk a moved NTFS volume must not carry a Windows system — a root-level Windows directory, bootmgr, or a Boot directory — because Windows’ boot records there reference partitions by offset, so a moved system volume would not boot. The plan refuses that in words. Data volumes of any family move freely, and logical partitions inside an extended container are never moved.

On ext2/3/4 the shrink is complete rather than approximate: whole block groups are removed, used inodes in removed groups move to surviving slots with every directory entry re-pointed, data extents relocate whole into contiguous windows below the cut, xattr blocks move with their checksums re-derived, and every ext4 metadata checksum is recomputed. When fragmented free space leaves no window big enough for an extent, the plan refuses in words with the sizes rather than splitting it — e4defrag or a larger target gets past that.

Onto a bigger disk

The everyday journey in the other direction — a small old drive onto a big new one — grows in flight the same way, so the copy never lands with a dead tail you have to fix with a second tool, and the certificate covers the final bytes.

The GPT is regenerated for the new size: backup header and entries at the true end, last-usable LBA moved out, both CRCs recomputed, the protective MBR widened. The biggest partition with a filesystem Clone can grow is the one that grows. On a GPT disk the partitions after it — the recovery partition that follows a Windows C:, a data partition after a Linux root — move toward the end of the disk by the same 1 MiB-aligned distance, keeping their sizes, their contents and their GUIDs, because Windows and the EFI firmware find them by GUID. Their boot sectors’ own start fields are updated with them.

On an MBR disk partitions are never moved, for the same offset-referencing reason, so only a last primary partition grows and the plan says so. When nothing can grow, the layout is kept, the stale backup header is zeroed, and the plan says what stays unallocated and why. Growing is on by default, because a technician restoring one image onto a room full of machines should not have to grow each one’s partition afterwards; --no-grow, or unticking Grow to fill a bigger destination in the window, leaves the space alone.

When Sectors Will Not Read

Healthy drives still throw the odd bad sector. A failing chunk is retried, then read sector by sector so everything readable is salvaged. Only truly unreadable sectors are skipped, zero-filled on the destination, and recorded in the certificate’s skip map. Past a threshold of error events or unreadable bytes the job stops and says so, because that drive is a rescue job. The source is untouched either way.

The damage report

Every zero-filled range is mapped, on the destination’s own structures, to the file, directory or metadata it landed in: FAT and exFAT through the directory tree with long names, NTFS through the MFT with paths built from $FILE_NAME parents (alternate streams and directory indexes named as such), ext through inodes with paths from a directory walk. A structure too damaged to walk is reported as exactly that. The findings go into the certificate and onto the screen, and clone damage CERT.json recomputes them later.

You are told what you lost, not just how many bytes.

Repairs from redundancy

Filesystems keep twins of what they cannot live without: a second FAT and, on FAT32, a backup boot sector; exFAT’s backup boot region; NTFS’s backup boot sector and $MFTMirr; ext’s backup superblocks and descriptor tables; a GPT’s backup header and entries.

When a zero-filled range lands on a primary and its twin is intact, the twin’s bytes restore it. A twin that is stale by design is not copied but rebuilt from the copy’s surviving truth — FAT32’s FSInfo from the FAT, ext’s superblock with its free counts summed from the descriptors, the GPT header with its LBAs swapped and CRC recomputed. Repairs happen after the copy and before verification, so the certificate’s digests describe the repaired bytes and verify --deep still holds. Each one is recorded with where its bytes came from. A range with no intact twin stays zero-filled and the damage report names it. Nothing is guessed, and all of this happens on the copy.

Verification and Certificates

Verification is not optional. After the copy, the destination is read back — with O_DIRECT where the device allows, so the medium answers rather than the cache — and compared chunk by chunk against the digests taken during the copy. No certificate is issued for a copy that does not verify.

The certificate carries both devices’ identities, the per-chunk digests, a Merkle root over all of them, the skip map, the repairs, what was skipped as unpartitioned space, and the timings. Its identity is the hash of its own contents, so a certificate cannot be edited without becoming a different certificate.

clone verify cert.json            # prove the certificate is intact
clone verify cert.json --deep     # read the copy back and compare it

One honest warning for later re-checks: mounting a filesystem can write to it even when mounted read-only. Linux ext4, for one, may replay its journal and process orphaned inodes on a read-only mount, and any such write makes verify --deep report, correctly, that the copy changed after certification. Run verify --deep before the first mount when the certificate matters.

A chunk that nothing lands in is neither built, hashed nor compressed, and the read-back takes the known digest for it rather than reading it again. On the bench that took one image job’s copy from 1,972 seconds to 965, and its verification pass from 943 seconds to 15.

When the Power Fails: The Journal and Resume

Every job keeps a journal — a chunk bitmap, the digests, the skip record — so an interrupted clone resumes where it stopped, after a power cut too, provided the journal outlives it.

Parted Magic runs from RAM, so journals go where VisParted puts its own and by the same rules: a place that can be shown to survive a reboot — a real block device carrying an on-disk filesystem, with a loop device followed to its backing file — writable, not on a disk this job touches, with room. Removable media first, because on a rescue system that is the boot stick. Nothing is guessed from a distribution name.

The boot stick is usually FAT32, which has no journal of its own, so Clone’s journal is written to survive a power cut there. Every file is created and sized once before the first chunk moves. The bitmap and the digests are only ever overwritten in place, so no directory entry and no FAT chain changes while the job runs and nothing is renamed over anything. The event log is append-only and fsynced per record, with a torn last line read as never written. And a chunk is trusted on resume only when its bit is set and its digest is present, with the digest made durable first — so any order of loss leaves a chunk to be redone, never one wrongly believed.

The window’s Journal… button, or J on the terminal face, shows where journals live now and what qualifies, mounts an unmounted partition you pick, and then looks there for interrupted copies and offers to finish them. Both faces do that same look at startup, so someone who lost power and rebooted is asked rather than left to find a command line. When nothing on the machine qualifies, the journal goes to RAM and the plan says so as a stated risk rather than a refusal — this journal is never load-bearing, because the source is untouched, so a lost one costs a restart and never bytes.

A job that is still running is never offered for resume.

One Engine, Three Faces

A GTK window that reads as VisParted’s sibling, a full-screen terminal face for a machine with no graphics, and a command line. All three are the same conversation: pick the source, pick the destination, read the plan in the engine’s words, type one yes, watch, read the certificate line.

No face decides anything technical. The refusals are the engine’s sentences, the progress lines are the engine’s progress lines, and none of the three has private wording for what happened. Run clone with no arguments and you get the window on a desktop and the terminal face on a terminal.

Clone Command-Line Reference

clone                                  # window on a desktop, terminal face on a terminal
clone gui | tui [--resume DIR]         # one or the other, on request

clone probe TARGET                     # identity, size, sector size, table
clone plan SOURCE DEST [--out plan.json]   # print the plan, write nothing
clone clone SOURCE DEST                # plan, one typed yes, copy, verify, certify
clone apply PLAN.json [--commit]       # run a saved plan
clone resume [--journal DIR]           # finish an interrupted job

clone verify CERT.json [--deep]        # prove the certificate, or re-read the copy
clone damage CERT.json [--dest DEVICE] # name what the zero-filled ranges landed in

clone report probe                     # check the PM report server
clone report send CERT...              # send certificates
clone report sync [DIR]                # send every certificate not yet countersigned

clone manual                           # the built-in manual

The destination may be a block device or an image file path; an image is created sparse and mounts with losetup like any raw image. apply without --commit stops after the proof and the precondition checks, having written nothing. resume with no --journal lists the interrupted jobs it can find, wherever journals live on this machine.

Useful modifiers: --full-range copies every byte including the gaps; --no-grow leaves the extra space on a bigger destination alone; --journals BASE sets where journals go for one run and --journal DIR names one job’s own directory; --server and --token address a report server, and --no-report keeps a job local.

Clone Filesystem Support

“Used-block map” means only the blocks in use are read and written. Everything else is copied correctly either way — a filesystem with no map is copied over its full range, which is slower, not less exact.

Filesystem	Used-block map	Shrink in flight	Grow in flight	Damage report
FAT12 / FAT16 / FAT32	✓	✓	✓	✓
exFAT	✓	✓	✓	✓
NTFS	✓	✓	✓	✓
ext2 / ext3 / ext4	✓	✓	✓	✓
XFS	✓	—	—	—
btrfs	full range, on purpose	—	—	—
linux-swap	—	—	—	—
anything unrecognized	full range	—	—	—

Partition tables read and written natively: GPT, and MBR with its full extended-partition chain.

What Clone Refuses, in Words

Refusal	Why
A mounted source or destination	A mounted source is a moving target.
An active swap partition	The kernel is writing to it.
Held by device-mapper — an open LUKS container, an LVM physical volume with its volumes active, a RAID member	In use just as surely, though the mount table names only the mapping.
Cloning a device onto itself, onto its own disk, or onto one of its own partitions	There is no version of this that ends well.
Mixed kinds — a disk onto a partition, or the reverse	They are not the same object.
A destination smaller than the source when no in-flight shrink exists for what it carries	The refusal states how much is actually in use.
A dirty or structurally damaged volume offered for shrinking	Cross-links, chains into free space, lost clusters, unclean flags and checksum mismatches are each refused in words. A structure that does not parse is a refusal too, never a traceback.
A shrink that would push a FAT volume below its type’s minimum cluster count	That would silently change the filesystem type.
A source past the read-error threshold	That drive is a rescue job.
A resume whose source has changed, or whose source or destination is mounted	The job it would finish is no longer the job that stopped.

A whole disk counts as in use when any of its partitions is. A partition counts only for itself, so a mounted sibling does not stop the clone of the partition next to it.

Mixing 512-byte and 4Kn drives

Enterprise drives pulled from arrays are often 4Kn — 4096-byte logical sectors — while the drive beside them is 512. Reproducing a partition table across that boundary is a geometry rewrite this version does not attempt, so a whole-disk copy between the two is refused.

A partition copy is a different question, and the answer depends on the filesystem. ext2/3/4 and btrfs do not record the sector size anywhere, so those partitions copy across the boundary with a note in the plan saying so. NTFS, FAT, exFAT and XFS do record it, and they are refused by name rather than copied into something that would not mount.

What Clone Will Not Do

• It is not a rescue tool. A drive past the read-error threshold is refused, by design.
• XFS and btrfs are copied but not resized in flight. btrfs is copied over its full range on purpose.
• Boot repointing is deliberately not built: Clone never moves partitions on an MBR disk, so nothing needs repointing.
• Mass deployment, image encryption and built-in network targets are not built. Mount the share and pick the folder.
• Mac filesystems are not mapped. They copy over their full range like anything else unrecognized.
• ext volumes using ea_inode, inline_data, meta_bg, bigalloc, MMP or sparse_super2 are refused for resizing, by name.

Fleet Reporting

The certificate is the product; the PM Report Server is how it travels. When a server is known — from --server, the PARTED_MAGIC_CLONE_SERVER variable, or the pmreport= boot parameter your fleet already sets for erase reporting — the plan states it, and a certified job sends its certificate as soon as it is written.

The server recomputes the content-addressed report id before accepting, stores the bytes verbatim, and countersigns them. The countersignature is kept beside the certificate as proof of receipt. A certificate altered after sealing is refused before it reaches the wire.

A report that does not go through never changes the job’s outcome. The copy is verified and the certificate written before any network is touched, the reason is said in words, and clone report send or clone report sync delivers it later. Authentication is a token from --token, the environment, or the same pmreport_token= boot parameter the erase clients read; a token is never written into a plan or a journal. --no-report keeps a job entirely local.

Clone FAQ

Can it ever write to my source disk?

No. The source is opened read-only and every corrective action happens to the copy. That includes replaying a dirty ext journal, which is done into an overlay rather than onto the disk.

What if the power goes out mid-copy?

Boot again and Clone looks for interrupted work on its own and offers to finish it. It continues from the last chunk whose digest was made durable, not from the beginning. If the journal itself was lost, you restart the copy — the source is untouched, so nothing is at risk but time.

Do I need Clone to restore one of its images?

No, and that is the point of the format. A compressed image is an ordinary zstd file and zstdcat image.img.zst | dd of=/dev/sdX restores it on any machine with the system’s own tools. Clone gives you verification, resume and a certificate on top of that; it never becomes a requirement for reading your own data.

Can I clone a bigger disk onto a smaller one?

Yes, when the data fits and the filesystems are ones Clone can shrink. It regenerates the table, shrinks in proportion to free space, and moves the later partitions inward. If the data does not fit, the refusal tells you how much is actually in use.

Does it need the internet or an account?

No. Clone runs entirely offline. Fleet reporting is optional, and when you enable it the evidence goes to a report server you run on your own network.

Get Parted Magic Clone

Clone ships inside Parted Magic, alongside VisParted and Secure Erase. One license covers unlimited drives and unlimited machines — no per-seat fees, no per-drive fees.