dattobd: a Linux kernel module for live block snapshots and incremental backups

LVM snapshots need a spare volume most servers do not have

The README frames the project as a response to a specific operational problem. Linux does have instant copy-on-write snapshots through LVM and device mapper, and LVM is built on device mapper, but both need an unused volume on the machine to hold the copy-on-write data, and production servers are often not provisioned with one. The second limitation is worse. Those snapshot systems only allow a read-only volume to be made read-write, so a live backup means unmounting the data volume, setting up a snapshot, mounting it, and copying the original volume elsewhere with dd or rsync. Then all of the new data in the copy-on-write volume has to be merged back into the original, which needs more downtime. The README calls that impractical and extremely hacky. Dattobd is the alternative approach: the copy-on-write data is tracked in a file on the source block device itself, so no spare volume is needed, and the module can be loaded onto a running machine without a reboot.

The COW file sits on the volume being snapshotted

Once a snapshot is taken, the driver switches into a tracking mode where it records which blocks changed, so later backups only need to copy the difference rather than the whole device. The driver works at the block layer, which means it is indifferent to the filesystem above it: the README lists support for ext 2, 3 and 4 and xfs, and states that filesystems with their own block device management, such as ZFS and BTRFS, cannot be supported, since those manage their own copy-on-write semantics and would conflict with the driver. The design goal stated in the README is to run on any Linux device, from small test virtual machines to live production servers, with minimal impact on I/O or CPU. Because everything is tracked in a file on the source device, the module is self-contained, which is what makes it usable on a server where allocating another volume is not an option.

The backup cycle alternates between snapshot and incremental mode

The README walks through a nine step workflow on a single root volume at /dev/sda1, copying to a larger volume mounted at /backups. The first step is creating the snapshot, where the COW file must already exist on the volume being snapshotted:

	dbdctl setup-snapshot /dev/sda1 /.datto 0

That produces a snapshot device at /dev/datto0 with its copy-on-write file at /.datto. You then copy the whole image off the block device:

	dd if=/dev/datto0 of=/backups/sda1-bkp bs=1M

The README is blunt about the risk here, warning that dd can badly corrupt filesystems if used incorrectly and that the of parameter should never point at a volume holding important data. Next the snapshot moves into incremental mode, where the driver tracks only the addresses of changed blocks and not the data itself, which is less system intensive:

	dbdctl transition-to-incremental 0

The system then runs normally for a while, and when you want a new backup you move the incremental back to snapshot mode, which requires the name of a fresh copy-on-write file:

	dbdctl transition-to-snapshot /.datto1 0

Using the same file name again would overwrite the list of changed blocks and force a full copy with dd next time. The update-img tool applies the recorded block list to the existing image, taking the snapshot device, the block list from the earlier file and the backup image path. The leftover file is then removed, and the cycle repeats with another copy-on-write file name each round. If you want to keep several versions of the image, the README suggests copying the images to a snapshotting filesystem such as BTRFS or ZFS and snapshotting them there.

dbdctl and /proc/datto-info are the whole control surface

There is no daemon and no service to configure. The driver is controlled through the dbdctl tool, whose own manual page lives at doc/dbdctl.8.md, and the state of the driver is readable from a single file. The README describes /proc/datto-info as a JSON-formatted file with two fields: a version number named version and an array named devices. Each entry in the devices array carries fields including the minor number of the snapshot, which is the identifier you pass to the dbdctl commands, as the examples in the workflow show with the trailing 0. That JSON shape means you can monitor the driver from the same tooling you use for anything else that exposes /proc, and the on-disk format of the .datto file itself is documented separately in doc/STRUCTURE.md. If you write automation around this driver, those two documents plus the dbdctl man page are the reference to work from.

The Makefile builds a driver, a library, an application and tools

The repository is a C project with a conventional layout: src/ for the kernel module, lib/ for the shared and static libraries, app/ for the user space application, utils/ for the command line tools, plus tests/, dist/ and doc/. The Makefile exposes targets for each piece, with driver building in src/, library-shared and library-static building in lib/, and utils building in utils/ against the shared library. The default target is all, which builds driver, library, application and utils. Flags are overridable, with CFLAGS defaulting to -Wall and the compiler flags adding -std=gnu99. Packaging is handled in the same file, with pkgprep building a tarball under pkgbuild/SOURCES and copying a spec file from dist/, and separate deb and rpm targets that call debbuild and rpmbuild with a PKGBUILDFLAGS definition. The build and install steps themselves are documented in INSTALL.md, and BUILDING-PACKAGE.md covers packaging. For a kernel module, expect to compile against the headers of the kernel you intend to run it on.

GPL-2.0 code, separate licensing notes, and a last release in April

The repository carries COPYING and COPYING.LIB alongside a dedicated LICENSING.md, which the README points to for the details on the licence of the software, and the Makefile headers the sources with SPDX-License-Identifier: GPL-2.0-only. The split between COPYING and COPYING.LIB is there because the tree contains both the kernel module and a shared library that other software may link, and different terms can attach to the two. That distinction is worth reading before you link the library into a proprietary backup agent; the LICENSING.md document is the place to check, and this is not legal advice. On the release side, the tags are v0.12.2 on 2026-04-22, v0.12.1 on 2025-05-14 and v0.12.0 on 2025-02-12, and the last push was on 2026-04-22. The project is not archived, so the code remains available, but the gap between the last two tags shows that the release cadence is irregular rather than scheduled.

Editorial conclusion

Adopt dattobd when you back up live Linux servers whose volumes cannot be unmounted and where you cannot provision a spare volume for copy-on-write data, and when you can run a kernel module on that host. Do not reach for it if your filesystems are ZFS or BTRFS, if your policy forbids custom kernel modules, or if you want an off-the-shelf backup product rather than a driver plus a set of command line steps. Verify first that the target filesystem is ext 2, 3 or 4 or xfs, read INSTALL.md for the build steps and LICENSING.md for the terms, and confirm that the COW file you create has room for the block list before you start the update-img cycle.

Frequently asked questions

Official sources

1. datto/dattobd on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases