Can you snapshot a mounted Linux filesystem without freezing it?

Yes. The ShadowCradle Linux snapshot driver intercepts writes at the block layer and copies the original block aside before it is overwritten, so no filesystem freeze is required. Writes are held only for the duration of copying one 64 KB region, and only the first time that region is written after the snapshot is taken.

Do I need LVM, Btrfs or ZFS to snapshot a Linux server?

Not with this driver. Btrfs, ZFS and LVM all provide native snapshots and should be used where they are already in place, but they require that decision to have been made when the system was installed. The ShadowCradle driver works on plain ext4 or XFS on a bare partition, with no change to the existing disk layout.

What happens if the copy-on-write store runs out of space during a Linux backup?

The snapshot is marked invalid and the write is dispatched to the disk anyway. A failing backup never stalls or damages the running server. The invalid snapshot refuses all subsequent reads rather than serving a partially correct image, so a backup is never silently incomplete.

Which Linux kernel versions are supported?

Kernel 5.12 through 7.2, verified by booting each one and running the full correctness suite. The driver detects kernel interfaces by compiling probes against the target kernel rather than checking version numbers, which is what allows enterprise distributions with backported changes to work correctly.

How does ShadowCradle detect corruption in a Linux snapshot?

Every block copied aside carries a checksum taken at the moment it was preserved, and that checksum is verified every time the block is read back. If the copy-on-write store returns different bytes than were written to it, the snapshot is failed rather than served, so a corrupted backup is never reported as a successful one.

Linux Block Snapshots

Point-in-time snapshots of a live, mounted disk

Windows has had shadow copy since 2003. On Linux, a consistent block-level snapshot has always meant putting the data on the right filesystem or the right volume manager first. Plain ext4 or XFS on a bare partition, which is most of the servers in the world, has had no answer that does not freeze the filesystem or move the mount.

This is our answer: a small kernel module that intercepts writes at the block layer, copies the original block aside before it is overwritten, and exposes the frozen image as a read-only device. No freeze. No remount. No change to how the disk is laid out.

Why this needs a kernel module

We wanted to avoid shipping a driver. Copy-on-write without a freeze means sitting in the write path and holding a write back while the original block is copied, and nothing outside the kernel can do that. Here is what every alternative actually costs.

Btrfs / ZFS snapshots

Use these when you have them

Native, mature and driverless. They only exist if the data is already on one of those filesystems, which on most servers it is not.

LVM snapshots

Use these when you have them

Also driverless. Requires the volume to have been placed under LVM with free extents in the group, which is a decision made at install time and cannot be taken back.

Filesystem freeze and copy

Stalls every write

FIFREEZE blocks writes for the whole copy. On a busy database that is an outage, and the length of it is not something you can bound in advance.

Inserting dm-snapshot

Breaks the mount

Slipping a device-mapper layer under a live filesystem changes the device the mount points at. Open file handles do not follow.

eBPF

Cannot hold a write

Block-layer eBPF is observational. It can report that a write happened; it cannot pause it while the old block is copied aside. There is no program type that grants write interception at the bio layer.

Where a native snapshot exists, use it. The agent tiers automatically: Btrfs and ZFS first, LVM next, and this driver only for the layouts nothing else covers.

How it works

Attach

The driver takes over the disk’s write entry point. Nothing above the block layer sees a change: same device node, same mount, same open handles. From here it records which blocks change, at a few bytes of memory per gigabyte.

Snapshot

Allocating a snapshot is a flag and an empty file. It does not copy anything, so opening one on a 16 TB disk takes the same time as on a 16 GB one, and an idle disk costs nothing at all.

Copy on first write

The first write to any 64 KB region is held, the original content is copied into the store, and the write is then released. Every later write to that same region proceeds at full speed.

Read the frozen image

A read-only device serves the point-in-time image: preserved regions from the store, untouched regions straight from the live disk. Mount it, or stream it to the appliance.

Release

The store is discarded and the disk is left exactly as it was found. Change tracking continues, so the next backup only moves what actually changed.

What happens to a write

Only the first write to a region pays anything, and a failing store never blocks the disk.

Where a snapshot read comes from

The snapshot is not a copy of the disk. It is a view assembled per region from two places.

What it will not do to your server

Code that sits in the write path of a production disk has to be judged on its failure modes, not its happy path. These are the rules the driver is built around.

The device is never the thing that suffers

If the copy-on-write store fills, errors, or is found corrupt, the snapshot is marked invalid and the write is dispatched anyway. A failed backup never becomes a stalled or damaged server.

Invisible to the running system

No freeze, no unmount, no change to the disk layout, no new device node in the data path. Same major:minor, same mount, same open file handles.

Fail closed, never half right

A snapshot that hit any error refuses every subsequent read rather than serving a partially correct image. A consumer cannot tell a partly wrong backup from a right one, so it is never offered.

Checksummed end to end

Every preserved block carries a checksum taken at the moment it was copied, verified every time it is read back. A store that returns the wrong bytes fails the backup instead of silently poisoning it.

How we know it works

A backup product that loses data quietly is worse than no backup product. The test suite is built to catch the quiet failures specifically, and the numbers below are what it currently proves.

151

Correctness assertions

across five automated suites

Kernel versions booted

5.12 through 7.2-rc

Device classes covered

virtio, loop, dm, md RAID1, zram, nbd

What the suite actually asserts

Every byte of the disk is overwritten after the snapshot, then every block is read back and compared. Full coverage, not sampled.

Power is cut mid-copy and mid-teardown, repeatedly, with ext4 and XFS mounted on the live disk.

Every error path is driven by injected failures, to prove a failing store costs the backup and not the server.

A run under kernel address sanitiser, undefined-behaviour sanitiser and lock validation.

A byte-for-byte comparison against dattobd, the closest existing driver, on the same disk.

What it has not proven yet

ARM64 compiles and passes its checks but has never been booted.

Parity RAID and thin-provisioned volumes are untested underneath it.

We publish this list because a gap nobody wrote down is a gap nobody closes.

Kernel coverage that tests itself

The block layer changes between kernel releases, and a driver that hooks into it breaks quietly when it does. Rather than checking version numbers, the build compiles a set of probes against the target kernel and asks it directly which interfaces it has, which is the only method that survives enterprise distributions whose version numbers do not describe their contents.

The test matrix is not a list somebody maintains. It queries the upstream archive for every kernel series that currently exists, downloads each one, and builds and boots against it. When a new kernel or release candidate appears, it is tested without anybody editing a file, because a stale list stays green while the kernel your servers actually run is missing from it.

The pipeline, end to end

Fully automated. No human picks the kernels, runs the suites, or decides whether it shipped.

Booted and passing

5.12, 5.15, 5.16, 5.17, 6.0, 6.1, 6.6, 6.8, 6.12, 7.1 and the current 7.2 release candidate. Debian, Ubuntu and RHEL-family kernels compile from the same source with no per-distribution patches.

Backup Agent

The cross-platform agent this driver plugs into.

Learn more

Storage Infrastructure

Where the blocks land once they leave the server.

Learn more

Database Backup

Application-consistent snapshots on top of block-consistent ones.

Learn more

Testing & Release Automation

How every commit is booted on eleven kernels before it ships.

Learn more