rescuezilla: interoperable with Clonezilla in both directions, and not yet able to shrink a partition

The one unsupported operation is stated in a note of its own

The feature list runs to thirteen bullets covering imaging, cloning, virtual machine formats, RAID and LVM, a file explorer, a web browser, partition editing, factory reset and undeleting files. Immediately after it, separated by a note, comes the limitation that matters most:

Rescuezilla does NOT yet _automatically_ shrink partitions to restore to disks _smaller_ than original. This feature will be added in future version.

The emphasis in the source is on automatically, which is doing real work in that sentence. It distinguishes what the tool does from what a user can arrange around it, and it is the difference between a restore to identical or larger hardware and a restore to a smaller drive. A user cloning a 500 GB disk onto a 250 GB SSD is outside the automated path, and the README is clear enough about that to be the first thing to check before treating this as a migration tool rather than a backup tool.

The README argues against using it when a file based backup would do

There is a paragraph early in the file that reads more like advice from someone who has watched people use the wrong tool. It defines disk imaging as making a backup of a hard drive managed as files on an external drive, and disk cloning as making a direct copy without needing a third drive for temporary storage. Then it says hard drive imaging and cloning is a very specialized task that is not necessarily the best solution for every user, and that it is worth researching whether a traditional file based backup approach is more suitable for the specific problem you are trying to solve. That is an unusual thing to find in a tool's own README, and it changes how the feature list should be read: the thirteen bullets describe what the tool does when imaging is the right answer, not a case for imaging by default.

The history table interleaves version numbers from two different projects

The history table sorts one column of version numbers descending, and the numbers come from two unrelated products. Rescuezilla 1.0.6 dated 2020-06-17 is followed by Redo Rescue 2.0.0 dated 2020-06-12, five days earlier but numerically higher because it belongs to the project Rescuezilla was forked from, and then by Rescuezilla 1.0.5.1 from 2020. So a reader scanning the version column sees 1.0.6, then 2.0.0, then 1.0.5.1, which reads like a mistake until you know the fork history. The table also carries a placeholder date: the top row, Rescuezilla Rolling, is dated 2023-XX-XX, which is earlier than the 2024-09-08 of the 2.5.1 row beneath it while being listed above it as the newest entry. The row is the periodic rolling release, so an undated placeholder is understandable, but it is the first thing a reader sees.

The history table stops at 2.5.1 while three newer releases exist

The last concrete row in that table is Rescuezilla 2.5.1, released 2024-09-08, with the note that it added a command line interface. The release list tells a later story: 2.6 came on 2025-03-23, 2.6.1 on 2025-07-16 and 2.6.2 on 2026-05-16. So three releases shipped after the newest row the documentation records, and the table calls itself abridged, which is a fair label for a history that covers fifteen entries back to 2010. The cadence is worth reading off the release list rather than the table, because it is uneven: 2.6.1 to 2.6.2 is ten months, while 2.5.1 to 2.6 is about six. The last push to the default branch is dated 2026-05-16, the same day as 2.6.2, so the newest release and the newest commit are one event.

The default goal in the Makefile is plucky while all points at focal

The build system names Ubuntu releases as top level targets, one per codename, and the first two lines of the file disagree about which one runs when you type make with no arguments. The default goal is set to plucky:

.DEFAULT_GOAL := plucky

Five lines later there is a target called all, and it depends on focal:

all: focal

So a bare make builds the focal image while the goal marked as default is plucky. A reader who trusts the first line and a reader who trusts the target named all get different builds from the same command, and neither line mentions the other. The full target list also includes jammy, oracular, questing, resolute, noble and noble-arm64, plus bionic-i386, so this is a matrix of build environments rather than a single one, which makes the ambiguity worth resolving before anyone depends on a reproducible default.

A FIXME in the Makefile says it does not know what to rebuild, and names a target that is not there

The build file carries three of its own outstanding problems as comments, which is unusually candid:

# FIXME: Properly specify the build artifacts to allow the GNU make to actually be smart about what gets built and when.
# FIXME: This lack of specifying dependency graph means requires eg, `make focal` and `make lunar` has to be done as separate invocations
#        and things get recompiled when they don't need to be etc.

The substance is that no dependency graph is declared, so a second target invocation recompiles work that did not change, and the two named examples have to be separate command lines. There is no lunar target in this file. The list of phony targets runs focal, jammy, oracular, plucky, questing, resolute, noble, noble-arm64 and bionic-i386, and questing occupies the slot a reader would expect lunar to hold. A third line is a TODO to read the GNU make manual and rewrite the file, and a second FIXME points at issue 150 about the build environment's ability to compile software.

The Dockerfile re-declares its codename because Docker clears the argument after FROM

The container build that produces the host system for the live image is where the release codename lives, and the first thing it does is declare it twice:

ARG CODENAME=noble
FROM ubuntu:${CODENAME}
# Define the Ubuntu code name again because Docker clears the argument after the FROM command.
ARG CODENAME=noble

The comment on the line before FROM explains the split: the host system Ubuntu version is defined separately from the version of the generated Ubuntu image. So a single build argument controls two different Ubuntu versions, one for the builder and one for the result, and the redeclaration exists because Docker scopes build arguments to the stage that uses them. Further down, the same codename is substituted into two apt preference filenames copied from the chroot tree, with backports and proposed repositories set never to be selected automatically, and the mirror URL is chosen by architecture, with amd64 and i386 pointed at the main archive.

Two changelog files sit at the root and the documentation links one of them

The top level of the repository holds both CHANGELOG and CHANGELOG.md. The history section of the README sends readers to CHANGELOG.md, so the file without the extension is the one nothing in the visible documentation points at, and whether the two are the same content, one generated from the other, or two files kept by hand is not something the tree answers. Alongside them sit a pinned .python-version, a .gitmodules file for submodules, a Dockerfile, a Makefile and a docs directory, with the ISO build instructions under docs/build_instructions. The default branch is master rather than main, and two CI workflows are badged at the top of the README, one building the ISO and one running an integration test suite. Translations are handled through Hosted Weblate.

Editorial conclusion

Use Rescuezilla when you need a whole disk image you can restore onto identical hardware, and when interoperability with Clonezilla matters to you or to whoever inherits the machine. Check three things first. It cannot automatically shrink a partition to fit a smaller target disk, so a restore to different hardware needs that step done another way. The project's own advice is to consider a file based backup instead if that is all you need. And the release history in the README stops at 2.5.1, so use the release list rather than that table to decide which version you are getting.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. rescuezilla/rescuezilla on GitHub