zfsify
Cloud providers usually ship Ubuntu with ext4. Getting ZFS on / means building a
custom vm boot img or iso and uploading it. That’s a pain though, and not all cloud
providers support it. zfsify automates that work and lets you in-place convert any disk, / and any other /dev/disk* others too!
Create a normal Ubuntu VPS or volume on DigitalOcean, Vultr, Hetzner, AWS, GCP, Azure, or another provider, then run zfsify inside Ubuntu. It in-place converts your EXT4 filesystem into ZFS, allowing you to use snapshots, compression, checksums, booting from snapshots, and all the other benefits of ZFS.
Choose a setup
- Existing Ubuntu server or VM: convert ext4
/, including/boot, on its current disk. - Attached disk or volume: convert ext4 using its mount point, such as
/mnt/data, or block-device path, such as/dev/disk/by-id/...; retain its files and mount point. - New Ubuntu server: use the cloud-init templates to convert the boot disk or an attached volume after provisioning.
Before you start
⚠️ This is experimental software! make a full offsite backup before proceeding.
We try to keep the process bootable/recoverable 90% of the time if it gets interrupted, and we provide recovery instructions for some possible failure modes. Despite our best efforts, there are several 10~60s parts of the process where recovery/bootability is impossible if it gets interrupted (when changing the parition table). 🤞 Make offsite backups and avoid power outages during those parts!
If converting /: confirm that you can access your VM’s display, VNC, or VPS cloud recovery console UI (only if you need to interact with ZFSBootMenu / boot from a snapshot). Expect 2 reboots and downtime/no apps runnable during the bulk of the process. After the first reboot you should be able to reconnect into the ramdisk and watch the transfer process over ssh, then reconnect after the last reboot into the new copied OS running in ZFS rpool.
If converting an attached disk other than /: make an offsite backup or snapshot in your cloud. Stop applications that use it, allow volume downtime until conversion finishes.
🔢 Quickstart
# Convert your Ubuntu ext4 grub install to Ubuntu ZFS rpool + ZFSBootMenu boot partition
curl -fsSL https://pirate.github.io/zfsify/reformat.sh | sudo sh
# Or convert any other attached disk, e.g.
curl -fsSL https://pirate.github.io/zfsify/reformat.sh | sudo bash -s -- /dev/disk/by-id/abc-123
curl -fsSL https://pirate.github.io/zfsify/reformat.sh | sudo bash -s -- /dev/disk/rdisk4
curl -fsSL https://pirate.github.io/zfsify/reformat.sh | sudo bash -s -- /mnt/data
Use the arrow keys or numbers to preview each method and its disk diagram, then press Enter to choose. Review the highlighted disk and explicitly confirm conversion. The interactive flow has no automatic start or timeout; method options preselect the method for review. Convert one disk per invocation.
Optional root encryption
Choose encryption in the interactive flow, or pass --encrypt:
curl -fsSL https://pirate.github.io/zfsify/reformat.sh | sudo bash -s -- --encrypt
# Headless conversion: retrieve the passphrase from your HTTPS key server in RAM.
curl -fsSL https://pirate.github.io/zfsify/reformat.sh | sudo bash -s -- \
--yes --encrypt --encrypt-key-url=https://keys.example.net/my-server
Encryption is off by default. With --encrypt and no key URL, enter and confirm the passphrase
after the rescue reboot using the console, or reconnect over SSH and run
zfsify-unlock. Every subsequent boot needs the passphrase in ZFSBootMenu’s
preboot console, including the first boot after conversion. Normal SSH becomes
available after unlocking. --no-encrypt skips the encryption question.
Encryption works with each root conversion method, including --erase; attached
data volumes do not support this option. It encrypts the new / and /boot,
but does not securely erase old ext4 remnants or encrypt external backups.
For temporary automatic boot without a key server, choose the TUI’s plaintext
key option (save and retype its 16-character key), or supply ZFSIFY_ENCRYPT_KEY
with --yes --encrypt. --encrypt-key=KEY is also supported. This defeats disk encryption
until the key is replaced and removed; old disk copies remain a forensic risk.
Switch to a custom passphrase without rewriting data.
Key-server setup and recovery · Phone notification and remote unlock.
Minimum Requirements
- System: Ubuntu 22.04, 24.04, or 26.04 on x64 or ARM64; internet access to Ubuntu package repositories.
- Source disk: ext4 on a direct disk or partition with 512-byte logical sectors; no LVM, RAID, or encrypted sources. Attached disks: one source filesystem, with room for a second copy or a separate backup.
- Boot-drive resources: 512 MiB RAM; working space for package preparation and conversion, plus room in
/bootfor the temporary kernel and boot image. - Boot-drive setup: GPT and GRUB; BIOS or UEFI on x64, UEFI on ARM64; Secure Boot disabled. A separate ext4
/bootis supported. - SSH: for boot-drive conversion, a public key in
/root/.ssh/authorized_keys; copied to rescue and fresh installs to preserve access.
How it Works
1. 💿 Scans the disk and selects an algorithm
- **Enough room for two copies:** it selects the temporary-partition method, usually when less than 50% of the filesystem is used.
- **Less free space on `/`:** it selects slice-by-slice conversion when the data fits alongside the recovery area and filesystem overhead.
- **Insufficient working space:** it asks you to choose a separate backup destination. Attached volumes require room for two copies or a separate backup.
- **Explicit options:** it uses your requested method (`--preserve`, `--inplace`, `--backup`, or `--erase`) when applicable. It never selects erasure as an automatic fallback.
2. 🚀 Prepares the disk for conversion
- **Boot drive:** it stages a temporary RAM boot environment and reboots into it, retaining SSH access. For slice-based conversion, it also prepares persistent rescue storage so interrupted copying can resume.
- **Attached volume:** it unmounts the source filesystem before conversion; applications using that volume must be stopped first.
- **Backup and restore:** it prompts you to select and confirm a destination, then creates a complete archive and reads it back to verify it before erasing the source. An explicit `--backup=/mnt/backup` or `--backup=remote:path` selects the destination; final conversion confirmation is still required. [Backup setup](/zfsify/docs/backup.html).
3. 🔃 Converts ext4 to ZFS
- **Two-copy method:** it shrinks ext4, copies files to ZFS at the disk's end, and verifies them before replacing the original. It then moves ZFS to the front and expands it. Bootability is preserved where possible, but partition and bootloader replacement have interruption windows; disk failure can destroy both copies.
- **Slice-based method:** it copies and verifies files in slices, then reuses their ext4 space for ZFS. **The original Ubuntu installation becomes unbootable when its data starts being reclaimed.** The temporary rescue entry can resume interrupted copying or relocation.
- **Backup and restore:** it erases the source, creates ZFS, and restores the verified archive. The source remains unbootable until restoration and boot setup finish; keep the backup until the restored system works.
- **Erase (`--erase`):** for `/`, it installs fresh Ubuntu of the same release, preserves accounts, SSH access, and `/etc`, then restores as much home/application data as the displayed budget allows. **Omitted data is lost; applications may need reinstalling. For an attached volume, it erases all files.**
4. 💾 Finishes disk and boot setup
- **Files and mounts:** it preserves ownership, permissions, ACLs, and extended attributes. It removes the old ext4 entries from `/etc/fstab` and configures ZFS to mount the new datasets at their original paths.
- **Boot drive:** it rebuilds Ubuntu's initramfs with ZFS support, preserves applicable kernel boot arguments, and replaces GRUB with ZFSBootMenu. A small firmware/bootloader partition remains outside ZFS; Ubuntu packages continue to use APT.
- **Attached volume:** it mounts the new dataset at the original mount point and enables mounting at startup. You can then restart applications that use the volume.
5. 📸 Enables snapshots, recovery, and auto-grow on resize
- **Boot-drive snapshots:** it creates an initial recovery snapshot and schedules daily snapshots and snapshots before APT package changes, then reboots into Ubuntu. For recovery, you can open ZFSBootMenu in the provider's preboot console and boot a clone of a working snapshot. [Snapshot recovery](/zfsify/docs/recovery.html#open-the-preboot-console).
- **Disk growth:** it expands the ZFS partition and pool on reboot after you enlarge the disk through your provider. No guest-side resize commands are needed; both boot-disk and attached-volume growth have been tested on DigitalOcean.
If conversion stops: reconnect and run zfs-on-boot-status. Do not blindly
reboot or delete temporary partitions. Interruptions during final partition or
bootloader replacement may require a provider rescue image.
Recovery guide · Interrupted conversion
Tested environments
| Environment | Ubuntu / architecture | Configuration |
|---|---|---|
| DigitalOcean Droplets | 22.04 and 24.04, x64, BIOS | 1 vCPU; 512 MiB RAM / 10 GiB boot SSD or 1 GiB RAM / 25 GiB boot SSD; attached 1–2 GiB Volumes |
| Local VMs on Apple Silicon (QEMU/HVF) | 24.04, ARM64, UEFI | 2 vCPUs; 512 MiB RAM / 10 GiB disk or 1 GiB RAM / 25 GiB disk |
| Local VMs on Apple Silicon (QEMU/HVF) | 26.04, ARM64, UEFI | 2 vCPUs; 1 GiB RAM / 25 GiB disk |
| KVM guest hosted on a DigitalOcean Droplet | 24.04, x64, UEFI | 1 GiB RAM / 20 GiB disk |
Other providers have not been explicitly tested. Cloud-init scheduling has not been separately tested end to end.
Performance
| Environment | Observed transfer speed |
|---|---|
| Small DigitalOcean Droplet, built-in SSD | About 25~150 MB/s copying Ubuntu files |
| Local ARM64 VM, 1 GiB RAM | About 25~150MB/s copying and verifying files |
| Bare Metal NVMe, 16 GiB RAM | 200~350MB/s+ |
Allow roughly ~20 min per 20 GB @ 20 MB/s per core, plus some overhead for reboots and checks. Having a disk with many small files, doing it on a system with limited RAM, or using slow disks can increase the total time significantly.
Volume guide · Cloud-init guide · Recovery guide · Contributing