When your production server crashes at 3 AM, the difference between a minor incident and a career-ending disaster often comes down to one thing: whether you have a working backup strategy in place. Clonezilla remains the gold standard for disk imaging and cloning in Linux environments, offering enterprise-grade backup capabilities without the enterprise price tag. This guide walks you through installing and configuring Clonezilla on Ubuntu 26.04 LTS, drawing from real-world deployment scenarios across data centers, development labs, and production infrastructure.

Whether you’re backing up a single workstation or deploying standardized images across hundreds of machines via network multicast, understanding Clonezilla’s architecture and options is essential for any Linux administrator serious about disaster recovery. We’ll cover everything from creating bootable USB drives to setting up Clonezilla Server Edition for PXE-based network cloning, complete with the kind of troubleshooting insights you only learn after things have gone wrong in production.

Understanding Clonezilla: What It Is and Why You Need It

Clonezilla isn’t just another backup tool. It’s a specialized disk imaging and cloning solution that works at the block level, capturing only the used sectors of your storage devices to create highly compressed, restorable images. Unlike file-level backup tools like rsync or tar, Clonezilla operates below the filesystem layer, making it ideal for complete system recovery scenarios where you need to restore an entire disk or partition exactly as it was.

The tool comes in two primary flavors. Clonezilla Live is a bootable Linux distribution (based on Debian or Ubuntu) that you run from USB or CD to perform imaging and restoration on individual machines. Clonezilla Server Edition (SE), built on top of DRBL (Diskless Remote Boot in Linux), enables network-based cloning where you can deploy images to dozens or even hundreds of machines simultaneously via PXE boot and multicast.

For Ubuntu 26.04 LTS administrators, Clonezilla offers several advantages over alternative backup methods. It supports many filesystems including ext4, XFS, Btrfs, NTFS, and FAT32, handles both MBR and GPT partition tables, and works with modern UEFI systems. The compression algorithms available, particularly zstd in recent versions, can substantially reduce image size while preserving reliable restoration capability.

Prerequisites and System Requirements

Before diving into installation, ensure your environment meets the necessary requirements. Clonezilla itself is lightweight, but the hardware you’re backing up and the storage destination matter significantly for performance and success.

Hardware Requirements

• Source System: Ubuntu 26.04 LTS desktop or server edition
• RAM: Minimum 512 MB for Clonezilla Live, with 1 GB recommended for large disks
• USB Drive: At least 1 GB capacity for bootable Clonezilla Live media
• Storage Destination: Separate disk, USB drive, NFS share, SSH server, or Samba share with enough free space for images
• Network: Gigabit Ethernet recommended for network-based imaging through NFS, SSH, or multicast

Software Requirements

• sudo access on your Ubuntu 26.04 system
• Standard Ubuntu repositories enabled
• Optional DRBL repository for Clonezilla Server Edition

Important Considerations

The destination storage for your Clonezilla images must be separate from the source disk you’re backing up. You cannot create an image of /dev/sda and store it on /dev/sda itself. Common setups include:

• External USB hard drive mounted during imaging
• Second internal disk dedicated to backup storage
• NFS or Samba share on a separate server
• SSH/SFTP server with adequate disk space
• Amazon S3 or S3-compatible storage, which is slower but suitable for offsite copies

For Ubuntu 26.04 LTS specifically, use an Ubuntu-based Clonezilla Live variant when you need maximum hardware compatibility, especially for newer chipsets and storage controllers. Ubuntu-based releases generally track newer kernels and driver updates more closely.

Method 1: Creating Bootable Clonezilla Live USB

The most common and straightforward way to use Clonezilla on Ubuntu 26.04 is by creating a bootable USB drive with Clonezilla Live. This approach works for backing up individual machines, performing disk-to-disk migrations, and handling disaster recovery scenarios.

Step 1: Download Clonezilla Live ISO

Start by downloading the appropriate Clonezilla Live ISO. For Ubuntu 26.04 LTS systems, especially those with UEFI Secure Boot enabled, an Ubuntu-based alternative stable release is usually the best choice.

# Create a working directory
mkdir -p ~/clonezilla
cd ~/clonezilla

# Download the latest Ubuntu-based Clonezilla Live ISO.
# Check https://clonezilla.org/downloads.php for the current release.
wget https://sourceforge.net/projects/clonezilla/files/clonezilla_live_alternative_stable/20260705-resolute/clonezilla-live-20260705-resolute-amd64.iso

# Download checksum file for verification
wget https://sourceforge.net/projects/clonezilla/files/clonezilla_live_alternative_stable/20260705-resolute/clonezilla-live-20260705-resolute-amd64.iso.sha256

# Verify ISO integrity
sha256sum -c clonezilla-live-20260705-resolute-amd64.iso.sha256

The verification step is critical. A corrupted ISO can lead to failed boots mid-imaging operation, which at best wastes time and at worst leaves you with neither a working system nor a backup. Always verify checksums before proceeding.

Step 2: Identify Your USB Drive

Insert your USB drive, preferably 4 GB or larger, then identify the correct device name:

# List all block devices
lsblk

# Example output:
# NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
# sda      8:0    0 476.9G  0 disk
# ├─sda1   8:1    0   512M  0 part /boot/efi
# ├─sda2   8:2    0   1.9G  0 part /boot
# └─sda3   8:3    0 474.5G  0 part /
# sdb      8:16   1  14.9G  0 disk
# └─sdb1   8:17   1  14.9G  0 part /media/user/USB

In this example, /dev/sdb is the USB drive. Double-check this. Writing to the wrong device destroys its data permanently. Verify with sudo fdisk -l /dev/sdb if uncertain.

Unmount the USB drive if it is auto-mounted:

sudo umount /dev/sdb1 2>/dev/null || true

Step 3: Write ISO to USB Drive

Use the dd command to create the bootable USB:

# Write Clonezilla ISO to USB drive.
# WARNING: This erases all data on the USB drive.
sudo dd if=clonezilla-live-20260705-resolute-amd64.iso of=/dev/sdb bs=4M status=progress oflag=sync

# Ensure all data is written
sync

echo "Bootable Clonezilla USB created successfully!"

The bs=4M block size speeds up the write process compared with default 512-byte blocks. The oflag=sync option ensures data is flushed during the operation. This usually takes a few minutes, depending on the USB device.

Alternative: Balena Etcher GUI

If you prefer a graphical interface, Balena Etcher is a convenient alternative:

# Install through Snap
sudo snap install balena-etcher

# Launch Etcher
balena-etcher

1. Click Flash from file and select the Clonezilla ISO.
2. Click Select target and select the correct USB drive.
3. Click Flash! to create the bootable USB.

Etcher verifies the write operation automatically, which adds a useful safety layer.

Alternative: Ventoy Multi-ISO USB

For administrators maintaining a rescue toolkit containing Clonezilla, Ubuntu installers, SystemRescue, and other utilities, Ventoy is extremely practical:

# Download and extract Ventoy
cd ~/Downloads
tar -xzf ventoy-*-linux.tar.gz
cd ventoy-*

# Install Ventoy to USB. This formats the drive.
sudo ./Ventoy2Disk.sh -i /dev/sdb

# Mount Ventoy partition and copy ISOs
sudo mount /dev/sdb1 /mnt
sudo cp ~/clonezilla/clonezilla-live-*.iso /mnt/
sudo cp ~/Downloads/ubuntu-*.iso /mnt/
sudo umount /mnt

With Ventoy installed, you boot into a menu and choose which ISO to launch. It saves carrying several separate USB drives.

Step 4: Boot from Clonezilla USB

Restart the target machine with the Clonezilla USB inserted. Open the boot menu using the relevant key, commonly F12, F10, F2, ESC, or DEL, then choose the USB device.

If your system has UEFI Secure Boot enabled, use the AMD64/X86-64 Clonezilla Live ISO. If it still fails to boot, temporarily disable Secure Boot in firmware settings and try again.

When Clonezilla loads, select Clonezilla live (Default settings, VGA 1024×768) for most systems. Then:

1. Select your language, such as en_US.UTF-8.
2. Choose keyboard layout. Select Don’t touch keymap for a standard US keyboard.
3. Select Start_Clonezilla to enter the main menu.

Method 2: Installing Clonezilla Server Edition on Ubuntu 26.04 LTS

For enterprise environments, computer labs, or data centers where you need to deploy images to multiple machines simultaneously, Clonezilla Server Edition running on DRBL provides network-based cloning through PXE boot and multicast. It takes more preparation, but the time saved at scale is substantial.

Understanding Clonezilla SE Architecture

Clonezilla SE uses a client-server architecture. The DRBL server provides DHCP addresses to PXE clients, delivers boot files through TFTP, shares the Clonezilla environment and image repository through NFS, and sends images by unicast or multicast.

With a proper gigabit network, multicast deployment can send one image to dozens of clients in roughly the time required to image a single machine. This is why Clonezilla SE remains popular in labs, schools, provisioning rooms, and large workstation rollouts.

Step 1: Install DRBL and Clonezilla Packages

On the Ubuntu 26.04 LTS server that will act as the Clonezilla SE server, install the required packages:

# Update package lists
sudo apt update

# Install DRBL and Clonezilla
sudo apt install drbl clonezilla -y

The DRBL package supplies the core components required for the service, including DHCP, TFTP, NFS, and Clonezilla Server Edition integration.

Adding the DRBL Repository

If drbl is not available in enabled Ubuntu repositories, use the official DRBL documentation and repository guidance for your release. Avoid relying on obsolete apt-key workflows on modern Ubuntu systems. When adding any third-party repository, install its signing key into a dedicated keyring and verify the repository source before installing packages.

Step 2: Configure the DRBL Server

Run the DRBL server configuration utility:

sudo /opt/drbl/sbin/drblsrv -i

The interactive setup asks you to select the client-facing network interface, choose a kernel option, configure the DHCP IP range, and establish NFS exports. A typical isolated cloning subnet might use 192.168.100.2 through 192.168.100.254 for clients.

Step 3: Configure DRBL Clients

After the server configuration completes, configure client-side settings:

sudo /opt/drbl/sbin/drblpush -i

This configures the DHCP range, client naming conventions, and operating mode. In most image-deployment environments, choose Clonezilla box mode. Full DRBL mode is useful when you need persistent diskless clients, but it adds complexity that simple cloning workflows do not need.

Step 4: Configure a Dedicated Cloning Network

For predictable throughput and to avoid disrupting production workloads, use a dedicated NIC and VLAN for imaging traffic. A Netplan example follows:

# /etc/netplan/01-drbl-config.yaml
network:
  version: 2
  ethernets:
    eth0: # External or management network
      dhcp4: true
    eth1: # Client cloning network
      addresses:
        - 192.168.100.1/24
      dhcp4: false

Apply the configuration:

sudo netplan apply

Separating the cloning network prevents DHCP conflicts, limits broadcast and multicast noise, and protects ordinary production traffic from high-volume imaging sessions.

Step 5: Start and Verify Services

# Enable and start services
sudo systemctl enable dhcpd tftpd-hpa nfs-kernel-server
sudo systemctl start dhcpd tftpd-hpa nfs-kernel-server

# Verify DRBL services
sudo /opt/drbl/sbin/drbl-all-service status

All required services should report as active. If one fails, inspect system logs with journalctl -u SERVICE_NAME and review files under /var/log/.

Step 6: Prepare the Image Repository

Clonezilla SE uses /home/partimag/ as the conventional default image location. Ensure that it has sufficient capacity:

# Create image directory
sudo mkdir -p /home/partimag
sudo chmod 755 /home/partimag

# Example: mount a dedicated backup disk
sudo mount /dev/sdb1 /home/partimag

# Add a persistent mount entry after confirming the filesystem and UUID
sudo blkid /dev/sdb1

Use UUIDs in /etc/fstab rather than device names such as /dev/sdb1, because device naming can change after hardware changes or reboots:

# Example fstab entry. Replace UUID and filesystem type.
UUID=YOUR-UUID-HERE /home/partimag ext4 defaults,nofail 0 2

Step 7: Start a Multicast Clone Session

Use the DRBL control interface to begin an interactive Clonezilla session:

sudo /opt/drbl/sbin/dcs

1. Select clonezilla-start.
2. Select startdisk for full-disk operations, or startparts for partitions.
3. Select multicast.
4. Choose the source image and target disk.
5. Set the number of clients to wait for, or set a timeout before starting.

For scripted or repeatable deployments, command-line parameters can be used. Validate every command against a test environment before applying it at scale:

sudo /opt/drbl/sbin/drbl-ocs -b -g auto -e1 auto -e2 -r -j2 \
  -x -h 192.168.100.0/24 -p reboot \
  --clients-to-wait 10 \
  --max-time-to-wait 300 \
  multicast_restore_restoreparts \
  golden-image sda1 sda2

• -b: Batch mode with no confirmation prompts
• -g auto: Reinstall GRUB automatically
• -e1 auto: Auto-adjust partition geometry
• -e2: Use EDD CHS values for the partition table
• -r: Resize filesystem after restore
• -j2: Clone hidden data between MBR and first partition
• -x: Use multicast
• -h: Define participating hosts or subnet
• -p reboot: Reboot clients after completion

Client-Side PXE Boot Configuration

1. Enter BIOS or UEFI setup on each client.
2. Enable PXE or network boot.
3. Place network boot before local storage in the boot order.
4. Disable Secure Boot temporarily if your PXE environment requires it.
5. Save configuration and restart.

Clients obtain an address through DHCP, retrieve boot files through TFTP, load the Clonezilla environment, join the configured session, receive the image, and reboot when finished.

Method 3: Installing Clonezilla Directly on Ubuntu 26.04

Advanced users can install Clonezilla packages directly on Ubuntu instead of booting external media. This approach is most useful for automation involving secondary disks or removable storage. It is not suitable for imaging your active root filesystem.

Install the Package

# Update package lists
sudo apt update

# Install Clonezilla
sudo apt install clonezilla -y

Launch Clonezilla

# Launch Clonezilla's text interface
sudo clonezilla

You cannot create a consistent block-level image of the currently running root disk because its filesystems remain mounted and active. For full-system backups and disaster recovery, booting Clonezilla Live remains the recommended method. Use an installed Clonezilla package mainly for external disks, non-root partitions, or controlled automation.

Creating Disk Images with Clonezilla

Once Clonezilla is running from USB, PXE, or a controlled installed environment, the workflow is consistent. The important decision is whether you want a full-disk image, a partition-only image, or a direct disk-to-disk copy.

Step-by-Step: Create a Full Disk Image

1. Select device-image, which works with disks or partitions using image files.
2. Select an image repository location: local_dev, ssh_server, samba_server, nfs_server, webdav_server, or s3_server.
3. Mount the destination drive or connect to the network repository.
4. Select Beginner mode for safe defaults, or Expert mode for full control.
5. Select savedisk to save a complete local disk as an image.
6. Enter a descriptive image name, such as ubuntu-26-04-workstation-2026-09-23.
7. Select the source disk, for example sda.
8. Select a compression method appropriate to your CPU, storage, and time requirements.
9. Select an action after completion: reboot, poweroff, or stay in Clonezilla.

Compression Options

• -z1p: Parallel gzip, a practical compatibility option
• -z3: lzop, very fast with moderate compression
• -z5p: Parallel xz, high compression but CPU intensive
• -z8: lz4, extremely fast but with lower compression
• -z9: zstd, a strong modern balance of speed and compression
• -z9p: Parallel zstd, ideal for multi-core systems

Useful Expert Mode Options

• -q2: Use Partclone for supported filesystems and fall back when necessary
• -c: Prompt for confirmation before cloning
• -j2: Preserve hidden data between MBR and first partition
• -nogui: Use a plain text interface instead of dialog menus
• -rm-win-swap-hib: Remove Windows swap and hibernation data before imaging
• -ntfs-ok: Skip NTFS filesystem checks when they are known to stall
• -rescue: Continue if bad sectors are encountered
• -fsck-src-part: Check and repair source filesystem before imaging
• -gm: Generate MD5 checksums
• -gs: Generate SHA1 checksums
• -enc: Encrypt the image through supported encryption tooling

Example of an advanced image command:

sudo ocs-sr -q2 -c -j2 -z9p -i 4096 -gm -gs -p reboot savedisk \
ubuntu-server-backup-2026-09-23 sda

This creates a checksummed full-disk image using parallel zstd compression and 4 GB chunks, useful where the destination storage uses FAT32-compatible limits.

Image File Structure

Clonezilla saves an image as a directory containing metadata, partition tables, boot records, and compressed partition images:

image-directory/
├── blkdev.list
├── blkid.list
├── clonezilla-img
├── dev-fs.list
├── disk
├── Info-dmi.txt
├── Info-img-id.txt
├── Info-lshw.txt
├── Info-lspci.txt
├── Info-saved-by-cmd.txt
├── parts
├── sda-mbr
├── sda-pt.sf
├── sda1.ext4-ptcl-img.zst.aa
├── sda2.ext4-ptcl-img.zst.aa
└── Clonezilla-checksum.*.txt

The metadata is not decorative. It stores the disk layout, partition identifiers, boot configuration, and other information necessary for a reliable restoration.

Restoring Disk Images

Restoration is where image quality and preparation are tested. Whether you are recovering from disk failure, migrating a system, or deploying a golden image, slow down at the target-disk selection screen. Choosing the wrong target is one of the most expensive mistakes in a recovery workflow.

Full Disk Restore Procedure

1. Boot Clonezilla from USB or PXE.
2. Select device-image.
3. Mount the image repository using the appropriate storage method.
4. Navigate to the saved image directory.
5. Select restoredisk.
6. Select the image to restore.
7. Select the correct target disk.
8. Review the summary and confirm.
9. Wait for completion, then reboot or power off.

Example command:

sudo ocs-sr -g auto -e1 auto -e2 -r -j2 -c -p reboot restoredisk \
ubuntu-server-backup-2026-09-23 sda

• -g auto: Reinstall GRUB automatically
• -e1 auto: Adjust partition geometry
• -e2: Restore the saved partition-table layout
• -r: Resize compatible filesystems after restoration
• -j2: Preserve hidden MBR-to-first-partition data
• -c: Validate before restoring
• -p reboot: Reboot when finished

Restoring to Different Hardware

A restored system may need bootloader or initramfs repairs after moving to different hardware. This is especially common when changing firmware mode, storage controllers, or virtualized platforms.

Reinstall GRUB

# Mount the restored root filesystem
sudo mount /dev/sda2 /mnt

# For UEFI systems, mount the EFI System Partition
sudo mount /dev/sda1 /mnt/boot/efi

# Bind required virtual filesystems
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys

# Enter restored system
sudo chroot /mnt

# UEFI installation
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

# For legacy BIOS systems instead:
# grub-install /dev/sda
# update-grub

exit
sudo umount -R /mnt

Regenerate Initramfs

If the restored system cannot find the new storage controller or root filesystem, rebuild initramfs while chrooted into the restored operating system:

update-initramfs -u -k all

Restoring to a Smaller Disk

Restoration to a smaller disk is possible only when the used data and filesystem layout can fit. Use expert options such as -k1 to create a proportional partition table and -r to resize supported filesystems.

sudo ocs-sr -g auto -e1 auto -e2 -r -j2 -k1 -p reboot restoredisk \
ubuntu-backup sda

Do not rely on this blindly. Confirm the used data size, inspect the partition table, and test the procedure on non-production hardware when possible.

Partition-Level Operations

Full-disk images are excellent for complete recovery, but partition-level images can be more efficient when only selected filesystems need protection. Typical examples include backing up a root partition before a risky upgrade or restoring only a damaged system partition while leaving a separate /home volume untouched.

Save Specific Partitions

1. Select device-image.
2. Choose and mount the image repository.
3. Select saveparts.
4. Name the image, for example ubuntu-root-partition-backup-2026-09-23.
5. Select the required partitions with the spacebar.
6. Choose compression and verification options.

# Save only the root partition with parallel zstd compression
sudo ocs-sr -q2 -c -z9p -i 4096 -gm -p choose saveparts \
root-partition-backup sda2

# Save multiple partitions in one image
sudo ocs-sr -q2 -c -z9p -i 4096 -gm -p choose saveparts \
system-partitions-backup sda1 sda2

Restore Specific Partitions

sudo ocs-sr -g auto -e1 auto -e2 -r -j2 -c -p reboot restoreparts \
root-partition-backup sda2

This restores only the selected partition and leaves unrelated partitions untouched. Verify source-to-target mapping carefully, particularly if disk names or partition numbering changed after a hardware migration.

Disk-to-Disk Cloning Without an Image

For direct migrations, such as moving from an older SATA SSD to a larger NVMe disk, Clonezilla can copy a disk directly to another disk. This avoids the extra time and storage required for an intermediate image but also means you have no new recovery image when the operation finishes.

Direct Clone Process

1. Boot from Clonezilla Live.
2. Select device-device.
3. Select disk_to_local_disk.
4. Select the source disk.
5. Select the destination disk. All existing data on it will be erased.
6. Use -k1 for proportional partition sizing if the destination is larger.
7. Use -r to resize supported filesystems.
8. Review and confirm the operation.

sudo ocs-onthefly -g auto -e1 auto -e2 -r -j2 -sfsck -scs -batch -f sda -d sdb

Direct cloning can be significantly faster because there is no image compression or decompression step. However, it is not a substitute for a backup. Create or verify an independent backup before cloning a production disk.

Network Storage Integration

Centralized storage makes Clonezilla images easier to manage, verify, and protect. NFS is usually the simplest choice in Linux-only environments; Samba is practical when Windows systems are involved; SSH/SFTP offers strong security for remote storage.

NFS Image Repository

On the NFS server:

# Install NFS server
sudo apt update
sudo apt install nfs-kernel-server -y

# Create repository
sudo mkdir -p /srv/clonezilla-images
sudo chown nobody:nogroup /srv/clonezilla-images
sudo chmod 770 /srv/clonezilla-images

# Configure export for the dedicated cloning subnet
sudo tee -a /etc/exports << 'EOF'
/srv/clonezilla-images 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)
EOF

# Apply configuration
sudo exportfs -ra
sudo exportfs -v
sudo systemctl restart nfs-kernel-server
sudo systemctl enable nfs-kernel-server

# Permit NFS from the trusted subnet when UFW is active
sudo ufw allow from 192.168.1.0/24 to any port nfs

Avoid no_root_squash unless you have a deliberate and controlled reason to use it. Root squashing is safer for ordinary image repositories because it prevents remote root users from being treated as root on the NFS server.

In Clonezilla, choose nfs_server, configure networking, enter the server IP address, and supply the exported path such as /srv/clonezilla-images.

Samba/SMB Image Repository

# Install Samba
sudo apt update
sudo apt install samba -y

# Create repository
sudo mkdir -p /srv/clonezilla-images
sudo chown root:root /srv/clonezilla-images
sudo chmod 2770 /srv/clonezilla-images

# Create dedicated service account
sudo useradd --system --create-home --shell /usr/sbin/nologin clonezilla
sudo smbpasswd -a clonezilla

# Add Samba share
sudo tee -a /etc/samba/smb.conf << 'EOF'

[clonezilla]
   comment = Clonezilla Image Repository
   path = /srv/clonezilla-images
   browsable = yes
   writable = yes
   guest ok = no
   valid users = clonezilla
   create mask = 0660
   directory mask = 2770
EOF

# Validate and restart
sudo testparm
sudo systemctl restart smbd
sudo systemctl enable smbd

# Test local discovery
smbclient -L localhost -U clonezilla

In Clonezilla, choose samba_server, enter the server IP, workgroup or domain, account name, password, and share name.

SSH/SFTP Image Repository

# Install OpenSSH server if needed
sudo apt install openssh-server -y

# Create dedicated backup user
sudo useradd -m -s /bin/bash clonezilla-backup
sudo passwd clonezilla-backup

# Create and assign the repository
sudo mkdir -p /srv/clonezilla-images
sudo chown clonezilla-backup:clonezilla-backup /srv/clonezilla-images

Use SSH keys rather than passwords whenever possible. For a hardened deployment, restrict the backup account to the required storage path and disable interactive shell access only after confirming that Clonezilla can authenticate and write images successfully.

S3-Compatible Object Storage

Clonezilla can use S3 and compatible storage for offsite copies. This is useful for disaster recovery but often slower than local NFS or SSH because performance depends on WAN bandwidth, latency, and object-storage API limits. Use local or on-premises storage for fast restores, then replicate validated images to offsite storage.

Compression and Performance Tuning

Compression choice affects image size, CPU demand, network throughput, and restoration time. There is no universal best setting. Pick the algorithm based on the bottleneck in your environment.

Practical Recommendations

• Daily and weekly backups: Use zstd for a reliable balance of speed and image size.
• Multi-core servers: Use parallel zstd where supported to reduce CPU bottlenecks.
• Mass multicast deployments: Favor faster compression when CPU decompression becomes the limiting factor.
• Archival images: Use xz only when reduced storage use matters more than backup and restore time.
• FAT32 destinations: Split output files with -i 4096 to remain below the 4 GB file-size limit.

Split Large Images

sudo ocs-sr -q2 -c -j2 -z9 -i 4096 -batch -p true savedisk IMAGE_NAME DISK

The -i 4096 option splits image output into 4 GB chunks. This is useful for FAT32-formatted external media and can also simplify moving an image across systems with file-size limits.

Encrypt Sensitive Images

sudo ocs-sr -q2 -c -j2 -z9 -i 4096 -enc -batch -p true savedisk \
rocky10-encrypted vda

Encryption protects confidential data contained in disk images. Store the passphrase in an approved password manager or secrets-management system. Losing the passphrase means losing access to the image.

Verify Image Integrity

Generate checksums during image creation:

sudo ocs-sr -q2 -c -j2 -z9 -i 4096 -gm -gs -batch -p true savedisk IMAGE_NAME DISK

Verify an existing image before relying on it:

sudo ocs-sr -cm -batch chkimg IMAGE_NAME

This validation reads and checks the image content. Run integrity tests regularly, especially before maintenance windows, major upgrades, or planned migrations.

Troubleshooting Common Clonezilla Issues

Clonezilla Will Not Boot on UEFI

Symptoms: The system hangs at the boot menu or shows an invalid-signature message.

• Use the 64-bit AMD64/X86-64 Clonezilla ISO.
• Recreate the USB using dd, Etcher, or another verified imaging tool. Do not simply copy the ISO file to a USB filesystem.
• Temporarily disable Secure Boot if firmware rejects the boot chain.
• Try Clonezilla’s failsafe boot mode for broader hardware compatibility.

Cannot Unmount Disk During Image Creation

Symptoms: Clonezilla reports that a partition cannot be unmounted or that authentication is required.

Cause: You are attempting to image the disk currently used by the running operating system.

Solution: Boot from Clonezilla Live USB or PXE. That isolates the installed system disk so its partitions can remain unmounted during the imaging operation.

Restored System Does Not Boot

Symptoms: The restore appears successful, but the machine drops into firmware, GRUB rescue, or initramfs.

• Reinstall GRUB using an Ubuntu live environment and chroot procedure.
• Regenerate initramfs with update-initramfs -u -k all if the new system uses different storage hardware.
• Confirm that firmware boot mode matches the original install: UEFI-to-UEFI or BIOS-to-BIOS whenever possible.
• Use Clonezilla’s automatic GRUB reinstall option during restoration where appropriate.

Multicast Session Does Not Start

Symptoms: The server waits indefinitely for clients, or clients PXE boot but never join the session.

• Verify that DRBL DHCP settings match the isolated client subnet.
• Check that TFTP, NFS, and DHCP services are active.
• Allow required UDP multicast traffic through the firewall.
• Enable IGMP snooping on managed switches when using multicast at scale.
• Confirm that PXE boot is enabled and client NICs are connected to the intended VLAN.

# Check DRBL-related services
sudo /opt/drbl/sbin/drbl-all-service status

# Check individual systemd services
sudo systemctl status tftpd-hpa nfs-kernel-server

Image Is Larger Than Expected

• The source disk may be genuinely full. Remove unnecessary data before imaging.
• The filesystem may be unsupported by Partclone, forcing a sector-by-sector fallback.
• The chosen compressor may prioritize speed over compression ratio.
• Windows hibernation and page files can consume considerable space; use appropriate Windows cleanup options before imaging where safe.

Slow Network Transfer Speed

First, verify physical link speed:

ethtool eth0 | grep Speed

• Use wired Ethernet, not Wi-Fi.
• Confirm that all links negotiate at 1 GbE or higher where expected.
• Schedule large image transfers outside periods of heavy traffic.
• Use a dedicated VLAN or physical network for Clonezilla SE deployments.
• Use faster compression when CPU load, rather than storage capacity, is the bottleneck.