Moving Windows to a Smaller SSD with Rescuezilla: From 1 TB to 512 GB
Rescuezilla restores an image only to a disk that extends at least to the end of the final partition. Using a 1 TB NVMe as an example, this guide shows how to shrink C: with GParted, move the recovery partition, remove the dirty flag, and restore the new image to a 512 GB SSD.
Rescuezilla is a free live system for backing up and restoring entire drives, compatible with Clonezilla’s image format (tool overview and basic process: Rescuezilla: Migrate Windows to a New SSD). As long as the target disk is the same size or larger, a backup and restore are sufficient. If it is smaller, the restore fails even though the used data would fit. This article documents moving a Windows 11 system from a 1 TB NVMe (C: with 930 GB, of which around 350 GB is used) to a 512 GB NVMe, including the error messages that occur along the way.
Why the restore to the smaller disk fails
Rescuezilla backs up each partition individually with Partclone and also saves the partition table. During restoration, it writes this table unchanged to the target disk. Rescuezilla cannot shrink a partition. Before starting, it therefore checks whether the final partition fits entirely on the target disk and otherwise stops with this message:
The source partition table's final partition (/dev/nvme0n1p4:
1000203091968 bytes) must refer to a region completely within
the destination disk (512110190592 bytes).
A typical Windows installation has four partitions: the EFI system partition (200 MB), the Microsoft reserved partition (16 MB), C:, and the recovery partition with Windows RE (904 MiB here). Windows places the recovery partition at the end of the disk. Therefore, shrinking C: is not enough: the recovery partition must also be moved forward, directly behind C:.
The process described by the Rescuezilla wiki for this case is: shrink the source disk with GParted, create a new image, and restore that image. An image created earlier from the unchanged disk remains as a backup until the new system is running.
Step 1: Calculate the target size
An SSD sold as 512 GB has 512’110’190’592 bytes, which is 476.9 GiB (Rescuezilla displays this value as well). EFI, MSR, and the recovery partition take up a good 1.1 GiB in total. That leaves just under 475 GiB for C:. With some reserve, 470 GiB = 481’280 MiB is a sensible target value. The approximately 6 GB left free at the end of the new SSD are insignificant.
The used data must be below this value. This command in an elevated PowerShell shows how far Windows could shrink a volume:
$s = Get-PartitionSupportedSize -DriveLetter C
"{0:N1} GB" -f ($s.SizeMin / 1GB)
If SizeMin is significantly above the amount of used data, unmovable files (page file, restore points, MFT) are preventing shrinking with Windows built-in tools. GParted moves this data when shrinking, so that limit does not apply there.
Step 2: Disable BitLocker and hibernation
GParted can neither read nor shrink a BitLocker-encrypted volume, and Partclone cannot back it up as NTFS. Check the status in an elevated PowerShell:
manage-bde -status C:
If it does not say Fully Decrypted, disable BitLocker and wait for decryption to finish:
manage-bde -off C:
Decryption runs in the background and may take an hour or longer depending on the amount of data. On devices managed through Intune, a policy may re-enable BitLocker after a short time. Therefore, check the status again immediately before starting GParted.
Hibernation must also be disabled. With Fast Startup enabled, Windows does not fully shut down but saves the kernel state in hiberfil.sys. NTFS is then considered still in use, and GParted refuses any changes. One command disables both hibernation and Fast Startup and deletes hiberfil.sys:
powercfg /h off
Step 3: Boot Rescuezilla
Windows can direct the next startup straight to the startup menu with advanced options. There, select “Use a device” and the USB drive with Rescuezilla:
shutdown /r /o /t 0
Alternatively, the firmware boot menu opens during power-on; on ASRock boards, use F11. If “Use a device” is missing, shutdown /r /fw /t 0 takes you directly to UEFI Setup, where you can select the boot drive for the next startup.
Step 4: Shrink C: and move the recovery partition
On the Rescuezilla desktop, start Partition Editor (GParted), not Rescuezilla itself.
-
Select the source disk in the upper-right corner. Pay attention to its size (931.51 GiB here) so you do not accidentally edit the external backup disk or a second internal disk.
-
Right-click the NTFS partition with C: → Resize/Move. Enter the target value in the New size (MiB) field, here
481280, and confirm with the Tab key. Leave Free space preceding unchanged. Apply with Resize/Move. -
Below C:, there is now a line
unallocated, followed by the recovery partition (NTFS, around 900 MiB, flagshidden, diag). Right-click the recovery partition → Resize/Move. -
Delete the value in Free space preceding (MiB), enter
0, and confirm with Tab. New size stays the same; Free space following changes to the entire free area. If1appears after pressing Tab instead of0, that is alignment to whole MiB and is fine. Apply with Resize/Move. -
Confirm the warning that moving may prevent booting with OK. It applies to partitions with bootloaders; Windows boots from the EFI system partition, which remains unchanged.
-
The order is now: EFI, MSR, C:, recovery partition,
unallocated. At this point, changes are only queued. Only clicking the green check mark (Apply All Operations) performs them.
Windows RE finds its partition again after it is moved because it retains its partition number. reagentc /info still shows Enabled afterward, with the path harddisk0\partition4\Recovery\WindowsRE.
The Rescuezilla guide shrinks only the last partition. That is sufficient if C: is the last partition. In a standard Windows 10 or 11 installation, the recovery partition is behind it, making the move mandatory.
Step 5: Remove the dirty flag
The next backup fails at C: after shrinking with this message:
ntfsclone-ng.c: NTFS Volume '/dev/nvme0n1p3' is scheduled for a check
or it was shutdown uncleanly. Please boot Windows or fix it by fsck.
The cause is intentional: ntfsresize, which GParted uses for NTFS, marks the file system for checking before every size change and leaves that mark in place. According to the man page, Windows should run chkdsk at the next startup. In the case described, however, the flag remained set after a normal Windows startup, and Get-Volume C reported Full Repair Needed. Check the status in an elevated PowerShell:
fsutil dirty query C:
If the command reports Volume - C: is Dirty, have the check run at the next startup:
chkdsk C: /f
Answer the question asking whether the check should be performed at the next restart with Y and restart Windows normally. Afterward, fsutil dirty query C: must show the message is NOT Dirty, and Get-Volume C must again report Healthy. Only then start Rescuezilla again.
Step 6: Create and check the new image
Now use Rescuezilla to create a new image of the shrunken disk. The image size remains virtually the same as the first backup (around 214 GB here), because Partclone backs up only used blocks. Rescuezilla places each backup in its own timestamped folder, such as 2026-09-29-1343-img-rescuezilla.
All images then appear side by side in the image selection list. The Partitions column shows their sizes: the image from before shrinking contains ntfs 930.4GB, while the new one contains ntfs 470GB. A failed backup attempt appears with a yellow warning triangle; it contains the old partition table and triggers exactly the error message from the first section during restoration. Delete such folders so they are not selected accidentally.
You can also determine in advance whether an image fits the target disk by looking at the <disk>-pt.parted file in the image folder. It contains the backed-up partition table in 512-byte sectors:
Number Start End Size File system Name
1 2048s 411647s 409600s fat32 EFI system partition
2 411648s 444415s 32768s Microsoft reserved partition
3 444416s 986105855s 985661440s ntfs Basic data partition
4 986105856s 987957247s 1851392s ntfs
The end of the final partition (987’957’247 + 1 sectors × 512 bytes = 505.8 GB) is below the target disk’s 512.1 GB. The image fits.
Step 7: Restore to the new SSD
-
In Rescuezilla, select Restore, the drive containing the images, and then the new image (without a warning triangle and with the shrunken C: partition).
-
Select the new SSD as the target. Check the model and size twice: restoration completely overwrites the target disk.
-
Keep all partitions selected, as well as Overwrite partition table, and start the restore.
-
Then boot from the new SSD. The easiest option is to disconnect the old disk first; otherwise, select the new SSD in the firmware boot menu.
Follow-up tasks
On the new drive, re-enable what was disabled for the migration. powercfg /h on enables hibernation again. Enable BitLocker through Settings → Privacy & security → Device encryption or with manage-bde -on C:; then verify with manage-bde -protectors -get C: that the recovery key has been backed up. If Secure Boot was disabled in UEFI to boot Rescuezilla, enable it again; while it is disabled, BitLocker logs event 810 at every startup.
You can delete the image of the unchanged 1 TB disk once Windows boots cleanly from the new SSD and all data is complete.
Comments
Comments are loaded from GitHub / Giscus.