zark 2.1: bare-metal backup and recovery for Ubuntu on encrypted ZFS, and how a broken laptop and a bad night in September made it.

In February 2026 a few keys on my laptop stopped working. They did not work in the BIOS either, so it was hardware. Dell sent a technician, who replaced the palmrest and keyboard at my desk on 17 February. After that visit the motherboard was dead.

On this laptop that is worse than it sounds: the storage is soldered to the motherboard. There is no SSD to pull out and read somewhere else. When the board goes, the disk goes with it.

What I had left was what I had always kept: a separate encrypted disk with two independent partitions, kept in sync with unison. My data was safe. A working system was gone, and nothing on that disk would bring one back quickly.

A computer the size of a ruler

My laptop is a Dell XPS 13 9315. Open it and most of the base is empty: the whole computer, storage included, sits on one small board, much smaller than the laptop around it. The only part that lives elsewhere is the right USB-C port, on a little I/O board of its own. The laptop has two ports, so losing one matters.

In early March a new motherboard arrived. Its right USB-C port did not work. On 18 March a technician replaced the I/O board, its cables and the mechanical kit; the port still failed. On 20 March the same technician replaced the motherboard again; the port still failed. On 25 March the laptop was booked into Dell’s repair depot, collected on the 27th, and it came back on 13 April. It has worked ever since. Every repair except that one happened at my desk.

Each new board was also a new, empty disk.

Building on hardware with an expiry date

I knew every restore would be tedious, and that there would be another one. So I prepared a bootable external disk with Ubuntu 26.04 and everything I needed to keep working, and worked from it. My old laptop, an XPS 13 9333, stood in as the spare machine. On the new board I installed Ubuntu with ZFS, just to try it, and I liked it. With another board change on its way, the question was obvious: how do you get a system like this back, fast?

I weighed the options. Clonezilla was the most reasonable one, but it takes a full image every time, and the backup is the thing you do most often. sanoid was already taking incremental snapshots on the laptop. Why not send those to an external disk and recover from it when needed? And because it is ZFS, any of the dates kept on the disk could be recovered, not only the last one.

The first version was already a Python script that sent syncoid’s snapshots to an external disk. Getting that started was the most tedious part. My first idea was to give the external disk its own encryption. Then I saw that a raw zfs send carries the encrypted blocks as they are: the drive holds ciphertext and never needs the keys. Simpler, and more efficient.

All through March I ran it again and again on the boards I knew were about to be replaced. Hardware with an expiry date makes a very honest test bench.

Why “zark”

At first it was called bzfs, for “backup ZFS”, until I found that the name was taken. I wanted something less conventional that still said what the tool does. zark is the Zettabyte Ark: when the flood comes, the ark already has everything aboard.

Version 1

On 30 April 2026 I published it as zark 1.0.4, and the PPA followed in May. From then on it backed up my own laptop, and I tested recoveries on other machines too, my XPS 13 9333 and a MINISFORUM mini PC among them, across several Ubuntu releases.

The moment I remember from that whole effort is the first full recovery that booted without problems: a backup drive, a live USB, a blank disk, and at the end a machine that started as if nothing had happened. Everything before that had been about getting there.

By June zark was at 1.0.12, and every backup ended with a reassuring message. One night in September I found out that the message was not always true.

The night it said “completed”

In September 2026 my laptop’s pool was almost full. To free space, I ran a zfs destroy by hand on my home dataset, with a % range: every snapshot between two names, in one command. It was aimed at old leftovers, and it also took the monthly snapshots in between. One of my backup drives, blue, the one I use every few weeks, needed those monthlies: they were what it still shared with the laptop for /home.

Nothing complained. Thirteen days later sanoid pruned, on schedule, the last snapshot blue and the laptop had in common. From that day on, /home could not be sent incrementally to blue.

On 25 September I ran my backups. On blue, syncoid refused /home, and zark 1.0.12 printed a warning, then BACKUP COMPLETED, and recorded the date as the drive’s last backup. It did the same the next morning. Every dataset on blue was current except /home, which was a month old. A recovery from that drive would have put a current system and a month-old /home together, and said nothing.

The same evening black, the drive that travels with me, went DEGRADED: checksum errors sixteen minutes into a routine incremental backup, with nothing in the kernel log. I purged and re-prepared it that night, which also erased the evidence of what had gone wrong. The new black scrubbed clean.

By 27 September both drives had been redone from scratch, backed up and verified. Nothing was lost. But the tool had told me something that was not true, and a backup tool exists to be believed.

That day I decided there would be no more 1.x releases. A tool meant to give guarantees deserved the effort it takes to give them, so zark would be rebuilt until it could.

What 2.0 and 2.1 changed

zark 2.0.0 came out on 23 October 2026. The main changes:

• Its own replication instead of syncoid. Each run takes one backup point of every dataset and sends from the newest snapshot the drive holds. When the laptop has already pruned that snapshot, a ZFS bookmark kept for that drive still marks where the drive stands. A drive can stay unplugged for months, and sanoid’s pruning no longer cuts it loose.
• Nothing on a drive is destroyed without a question, asked before the transfer starts.
• An honest verdict. BACKUP COMPLETED only when every expected dataset reached the new point. Otherwise it is BACKUP INCOMPLETE, the exit code is 1, the drive’s last backup date is not recorded, and a table shows what happened to each dataset.
• Read back before unplugging. Every backup is checked on the drive before zark says it is safe to disconnect it.
• zark prune reclaims space in the source or on a drive, under zark’s own rules, so nobody has to reach for a % range again.
• zark selftest checks that the machine’s ZFS, kernel and tools behave the way zark relies on. Each release publishes the results from my test machine, and you can share yours.

2.1 is about seeing what zark does. It writes its state to two status files that any program can read without root. zark monitor follows a running backup from another terminal, as any user, and a GNOME Shell extension shows the same in the top bar: the last backup to each drive, the progress of a running one, how full the pools are. It sends a notification when a backup is overdue or a backup drive is plugged in, and it never starts or changes anything.

While building 2.0 I ran dozens, maybe hundreds, of backups and recoveries, and not one failed. What surprised me most was how well it handles errors. A daily backup of my laptop takes about two minutes. On the test laptop, a full recovery from a live USB reached RECOVERY COMPLETE in 3m10s and in 3m25s; on a machine with more data, add the time it takes to copy it.

My own rule

zark’s README says to always keep at least one independent backup outside zark’s control, and I follow that myself. My rule is backups on different disks, in different formats.

zark runs at two speeds. black travels with me and gets a backup every few days. blue stays at home and gets one every few weeks. On a blue day I often run unison as well, to the old encrypted disk: a third copy, independent of zark and of everything else.

zark brings the system back. An independent copy still matters.

Try it

If you would rather see it than read about it, this video explains in under five minutes what zark does and how it works:

zark is for Ubuntu 24.04 LTS and 26.04 LTS, installed with the installer’s encrypted ZFS layout, with Secure Boot on.

sudo add-apt-repository ppa:juanmitaboada/zark
sudo apt update
sudo apt install zark

For a recovery there is no installed system, so zark also ships as a portable tarball on every release; it runs from an Ubuntu 26.04 live USB. On 26.04 the GNOME extension comes from the same PPA:

sudo apt install gnome-shell-extension-zark

zark partitions disks and destroys pools when you ask it to, so read what zark touches first.

You can help without writing code: share your zark selftest results (#2), or tell me which USB-SATA bridge your backup drive uses and how it behaves (#3).

The code, the documentation and every change are on GitHub; questions go to Discussions.