dar-backup

Personal digital preservation for Linux — with integrity you can prove, repair, and restore years from now

_{🎯 Stats powered by ClonePulse}

dar-backup is a personal digital preservation system for Linux built around one question:

Will I still be able to recover this data years from now?

It is intended for people preserving irreplaceable personal data — photographs, home video, documents, research, creative work, and other material whose value may increase with time.

The goal is not merely to create backup copies. The goal is to keep those copies understandable, verifiable, repairable, portable, and recoverable over long periods of time, even if the original machine, operating system, package versions, or administrator are no longer available.

dar-backup automates FULL / DIFF / INCR as independent archive types built on two exceptional open-source tools:

• dar (Disk ARchiver) — a powerful, actively maintained archiver by Denis Corbin that handles differential and incremental archives, built-in verification, catalogue databases, and precise file selection. dar is the engine that makes long-term archival practical. It deserves to be far better known than it is.
• par2cmdline — Parchive's redundancy format can detect and repair corruption in any archive, as long as the .par2 files travel with the DAR archives. A quiet but remarkable piece of technology.

dar-backup wires these tools together with automated verification, restore testing, catalog management, and an optional preserved restore environment. The result is a backup workflow designed not only to survive hardware failure, but also time.

Start here

If you are new to the project, the easiest way to get oriented is:

• Quick guide — install the package, run the built-in demo, and see a backup/restore flow in minutes
• Getting started — set up a real installation and configure your first backup definition
• Configuration reference — learn how the config file and backup definitions work

Is this for you?

• You preserve irreplaceable data — photos, documents, home-made video, research, creative work — and want to remain able to restore it years from now

• You run backups as a normal user — root is not required, and FUSE-mounted filesystems (Nextcloud, rclone, sshfs) work correctly

• You want bitrot repair to travel with your archives — onto USB disks, offsite copies, and cloud storage — without depending on the original system

• You want unattended, scheduled backups with Discord notifications on success or failure

• You want a transparent, no-lock-in system built on proven Unix components and standard archive/recovery tools

Not if you want:

• You need a GUI or Windows support

• You need multiple backups per day — dar-backup is designed around one backup run per day per definition (one FULL, one DIFF, one INCR)

Quick start (TL;DR)

# prep
sudo apt -y install dar par2 python3 python3-venv
INSTALL_DIR=/tmp/dar-backup; mkdir "$INSTALL_DIR" && cd "$INSTALL_DIR"
python3 -m venv venv    # create a virtual environment
. venv/bin/activate     # activate the virtual environment
# install and run dar-backup
pip install dar-backup
demo --install && manager --create-db
dar-backup --full-backup

dar-backup runs FULL, DIFF, and INCR backup cycles across as many backup definitions as you need (e.g. photos, documents, homevideos). After each archive it:

1. Verifies the archive with dar -t
2. Restore-tests a random sample of files and compares them byte-for-byte against the source
3. Creates PAR2 redundancy files so the archive can be repaired if bitrot occurs later
4. Notifies your Discord channel on completion or failure

Schedules are managed by systemd timers (generated for you). Catalogs of every archive are maintained by dar_manager, enabling single-file Point-in-Time Recovery without a database server.

Version 1.1.11 · reached 1.0.0 on October 9, 2025 · Changelog

A personal digital preservation system

dar-backup uses personal digital preservation in a practical, deliberately limited sense: preserving personal files and the means to recover them over long periods of time.

It is not an institutional digital-archive platform, records-management system, or preservation repository. It is a Linux backup and recovery system whose design choices are guided by long-term recoverability.

Most backup tools are designed primarily to survive hardware failure. dar-backup is also designed to survive time.

That is a different problem.

Hardware failures are acute — they happen on a known day, with the original system still understood, the software environment still intact, and recovery procedures still fresh. Time introduces a different class of failure:

• Format drift — tools and expectations shift over years
• Software obsolescence — the restore environment may no longer exist
• Silent corruption — bitrot accumulates unnoticed on disks and media
• Forgotten procedures — institutional knowledge degrades or disappears
• Loss of context — future operators, family members, or administrators may need to recover data without the original author present

For personal archives — family photographs, home video, research, creative work — these are the real failure modes. The data often grows more valuable with age, not less. And it is irreplaceable.

dar-backup is built around a single question: will this archive be recoverable years from now, under conditions I cannot fully predict today?

Recovery confidence over storage efficiency

Philosophy:

"Every backup is validated not when it is created, but when it is successfully restored".

This principle drives the design choices behind dar-backup.

dar-backup intentionally prioritizes recoverability over deduplication ratios or storage efficiency.

Storage costs are typically lower than the cost of data loss or recovery failure. For personal archives, that cost may be financial, practical, historical, or simply the loss of something irreplaceable.

This priority is reflected throughout the design:

• Independent archives — each backup is a discrete, self-contained artifact, not a node in a shared repository. Archives can be copied, moved, and verified individually.
• Verification after every backup — dar -t runs automatically. A backup that has never been tested is an assumption, not a guarantee.
• Restore testing after every backup — a random sample of files is extracted and compared byte-for-byte against the source. Each restore test increases confidence in recoverability through repeated, physical verification of data integrity.
• PAR2 redundancy travels with the archive — integrity protection and repair capability are embedded in the archive set itself, not dependent on the original system.
• No dependency on the original machine — recovery can be performed independently of the original host; a suitable dar binary is enough for direct archive restoration.
• Preserved restore environment — the optional Docker image can be archived alongside the backups as a known-working toolchain containing dar-backup, dar, PAR2, and runtime dependencies.
• Documentation as part of the system — long-term preservation requires preserving the knowledge needed to understand and use the archives, not just the archive files themselves.

Why independent archives matter

Many modern backup systems maintain a single evolving repository — a shared pool of data that stores all snapshots efficiently. This works well for scenarios where the system is intact and trusted.

Over long time horizons, the repository model carries risk. If the repository is damaged, all snapshots may be affected. Restore depends on the health of the entire system. The repository format may evolve. Tooling may change or disappear.

dar-backup uses independent, self-contained archive files instead:

• Each archive can be copied to independent media (USB, cloud, offsite)
• Each archive can be verified in isolation, anywhere
• Each archive can be repaired with its accompanying PAR2 files, without the original system
• Point-in-Time Recovery operates through dar_manager catalogs — no database server required

The result is that recovery confidence does not degrade with distance — distance being time, location, or technical context.

Preservation model

dar-backup treats a recoverable archive as more than a collection of backup files.

A strong long-term recovery set contains several independent layers:

DAR archive slices
        +
PAR2 recovery data
        +
dar_manager catalogs
        +
restore procedures and documentation
        +
a preserved restore environment
        =
a portable personal preservation set

Each layer addresses a different failure mode:

• DAR archives preserve the file data and metadata in independent archive sets.
• PAR2 provides repair capability if archive slices suffer localized corruption.
• Catalogs preserve historical knowledge about which archive contains which version of a file.
• Restore testing provides evidence at backup time that recovery actually works.
• Documentation preserves operational knowledge for a future operator.
• The optional Docker restore image preserves a known-working software environment alongside the data.

The aim is to reduce the number of assumptions a future restore depends on.

This approach does not claim to replace mature repository-based backup systems such as Borg or restic. Those tools make different design trade-offs and are excellent choices for many backup workloads. dar-backup deliberately emphasizes independent archives, portability, repairability, and long-term recovery confidence.

Features

• FULL / DIFF / INCR backup cycles — per backup definition, independently scheduled
• Automatic archive verification — dar -t after every backup run
• Automatic restore test — random files extracted and compared to source after each backup; configurable excludes for cache dirs, temp files, locks
• PAR2 redundancy — configurable coverage per backup type (FULL/DIFF/INCR); optionally stored in a separate directory (different device or offsite mount)
• Preservable restore environment (time capsule) — optional dar-backup-image packages dar-backup, dar, PAR2, and their runtime dependencies into a known-working environment that can be archived alongside the backups for future recovery
• Point-in-Time Recovery — dar_manager catalogs let you locate and restore any file to any date across your full archive history
• Metrics and dashboard - optional detailed metrics and dashboard
• Can run as a normal user — no root needed; works correctly on FUSE-mounted filesystems. Root is also a first class user.
• systemd integration — timer units generated for you with sensible default schedules
• Discord notifications — webhook alerts on backup success or failure, from all CLI tools
• Shell autocompletion — bash and zsh, context-aware (archive names filtered by definition)
• Clean logging — three log files (main, command output, trace/debug), all rotating and size-capped; clean-log strips verbose dar output when not needed
• No lock-in — standard dar archives, standard PAR2 files; restore with just the dar binary, no dar-backup installation required on the restore machine
• 1000+ tests — unit and integration tests covering PAR2 bitrot repair, full/diff/incr restore chains, PITR verification, and edge cases; CI on every push to Github and when done locally

The author has used dar-backup ~6 years and has been saved by it multiple times.

dar-backup stands on the shoulders of two projects that do the real work. Sincere thanks to Denis Corbin for dar, and to the Parchive team for par2. If you find dar-backup useful, consider giving those projects a star too.

Documentation map

For a first-time visitor, the best next steps are:

• Quick guide — the fastest path to a working demo
• Getting started — a real-world setup guide
• Configuration reference — the main reference for backup definitions and config options
• Restoring — how to recover data when you need it
• Troubleshooting — common issues and fixes

Dashboard

Every backup run writes structured metrics to a SQLite database. The built-in dar-backup-dashboard command fires up datasette and opens the dashboard in your browser:

→ Dashboard & metrics documentation

High-level architecture

Built for long-term recovery

Long-term recovery benefits from multiple independent layers of verification and repair. dar-backup separates those responsibilities rather than relying on a single mechanism:

1. Deterministic Slicing: Backups are divided into manageable chunk sizes (e.g., 10GB blocks) making transfers over networks or long-term disk sets reliable.
2. Isolated Parity Directories: par2 recovery files are maintained in a completely separate directory infrastructure from your data slices. If an underlying storage volume experiences filesystem bitrot, the parity blocks can cleanly rebuild damaged .dar slices automatically.
3. Point-in-Time Recovery (PITR): Historical queries let you restore to the state captured by any backup in your archive history — one PITR per backup run, per calendar day.

Full documentation index

My use case

I needed the following:

• Backup my workstation to a remote server

• Backup primarily photos, home made video and different types of documents

• I have cloud storage mounted on a directory within my home dir. The filesystem is FUSE based, which gives it a few special features

  • Backup my cloud storage (cloud is convenient, but I want control over my backups)
  • A non-privileged user can perform a mount
  • A privileged user cannot look into the filesystem --> a backup script running as root is not suitable

• Have a simple way of restoring, possibly years into the future. dar fits that scenario particularly well: the restore tool can be preserved with the archives, reducing dependence on the original machine or package repositories.

• During backup archives must be tested and a restore test (however small) performed

• Archives stored on a server with a reliable file system (easy to mount a directory over sshfs)

• Easy to verify archive's integrity, after being moved around.

I do not need the encryption features of dar, as all storage is already encrypted.

My setup

1. Primary backup to server with an ext4 file system on mdadm RAID1

2. Secondary copies to multiple USB disks / cloud

3. Archive integrity verification anywhere using Par2 and dar -t.

4. Archive repair anywhere if needed. By default dar-backup creates par2 redundancy files with 5% coverage. Enough to fix localized bitrot.

5. No dependency on original system

6. Docker image archived alongside the dar archives

   The dar-backup Docker image packages dar-backup, dar, and par2 in a self-contained environment — a time capsule of the exact tools needed to restore your archives, years from now, without hunting for the right versions or fighting package managers.

   A small helper script,

   save-dar-backup-image.sh, checks the latest released image against build-history.json and saves it as a compressed tar alongside the dar archives on the backup server. Run it as a cron job or systemd timer — it is idempotent and only pulls when a new image is available.

   # Example: run daily via cron
   DOCKER_ARCHIVE_DIR=/mnt/dar/docker-archives ~/.local/bin/save-dar-backup-image.sh

The result: my rsync to USB disks on the storage server picks up the Docker image automatically, so the restore environment travels with the archives onto every offsite copy.

This is intentionally treated as part of the backup set rather than as a convenience download. The long-term goal is that a future restore can begin with the preserved artifacts themselves, without first reconstructing today's software environment from the Internet.

A useful preservation practice is to periodically perform a cold recovery drill: restore using only the archive set, PAR2 files, catalogs, saved documentation, and preserved restore image. That tests the preservation system rather than merely the current installation.

Why PAR2 is especially good for portable / offsite copies

PAR2 parity is:

Self-contained (travels with the data)

Format-agnostic (works on any filesystem)

Location-agnostic (local disk, USB, cloud object storage)

Tool-stable (PAR2 spec has not changed in years)

That means:

Integrity protection moves with the archive.

Design choices

My design choices are deliberately simple, proven, and pragmatic:

• mdadm handles disks
• PAR2 handles data integrity
• You control when and how verification happens
• Errors have a fair chance of being diagnosed and fixed, due to well known tooling.
• No hidden magic, no lock-in

Quick Guide

Step-by-step walkthrough using the built-in demo application — install, backup, list, restore.

→ Quick Guide

dar-backup principles

dar-backup

dar-backup is built in a way that emphasizes getting backups. It loops over the backup definitions, and in the event of a failure while backing up a backup definition, dar-backup shall log an error and start working on the next backup definition.

There are 3 levels of backups, FULL, DIFF and INCR.

• The author does a FULL yearly backup once a year. This includes all files in all directories as defined in the backup definition(s) (assuming -d was not given).

• The author makes a DIFF once a month. The DIFF backs up new and changed files compared to the FULL backup.

  • No DIFF backups are taken until a FULL backup has been taken for a particular backup definition.

• The author takes an INCR backup every 3 days. An INCR backup includes new and changed files compared to the DIFF backup.

  • So, a set of INCR's will contain duplicates (this might change as I become more used to use the catalog databases)

  • No INCR backups are taken until a DIFF backup has been taken for a particular backup definition.

After each backup of a backup definition, dar-backup tests the archive and then performs a few restore operations of random files from the archive (see config file). The restored files are compared to the originals to check if the restore went well.

dar-backup skips doing a backup of a backup definition if an archive is already in place. So, if you for some reason need to take a new backup on the same date, the first archive must be deleted (I recommend using cleanup).

cleanup

The cleanup application deletes DIFF and INCR if the archives are older than the thresholds set up in the configuration file.

cleanup will only remove FULL archives if the option --cleanup-specific-archives is used. It requires the user to confirm deletion of FULL archives.

Use --dry-run to preview which archives, PAR2 files, and catalogs would be removed without deleting anything.

Examples:

cleanup --dry-run -d media-files --log-stdout
cleanup --dry-run --cleanup-specific-archives -d media-files media-files_INCR_2025-12-22

manager

darhas the concept of catalogs which can be exported and optionally be added to a catalog database. That database makes it much easier to restore the correct version of a backed up file if for example a target date has been set.

dar-backup adds archive catalogs to their databases (using the manager script). Should the operation fail, dar-backup logs an error and continue with testing and restore validation tests.

How to run

Manual setup for a real installation — configuration, catalog databases, first backup.

→ Getting Started

Status

1.0.0 milestone reached

October 9, 2025, version 1.0.0 was released after extensive testing.

GPG Signing key

To increase the security and authenticity of dar-backup packages, all releases from v2-beta-0.6.18 onwards will be digitally signed using the GPG key below.

Name:        Per Jensen (author of dar-backup)
Email:       dar-backup@pm.me
Primary key: 4592 D739 6DBA EFFD 0845  02B8 5CCE C7E1 6814 A36E
Signing key: B54F 5682 F28D BA36 22D7  8E04 58DB FADB BBAC 1BB1
Created:     2025-03-29
Expires:     2030-03-28
Key type:    ed25519 (primary, SC)
Subkeys:     ed25519 (S), ed25519 (A), cv25519 (E)

B54F 5682 F28D BA36 22D7  8E04 58DB FADB BBAC 1BB1

gpg --list-keys --with-subkey-fingerprints dar-backup@pm.me

License

These scripts are licensed under the GPLv3 license. Read more here: GNU GPL3.0, or have a look at the "LICENSE" file in this repository.

Requirements

• A linux system
• dar
• parchive (par2)
• python3
• python3-venv

On Ubuntu, install the requirements this way:

    sudo apt install dar par2 python3 python3-venv

Homepage - Github

'dar-backup' package lives here: Github - dar-backup

Community

Please review the Code of Conduct to help keep this project welcoming and focused.

Projects these scripts benefit from

1. The wonderful dar achiver
2. The Parchive suite
3. shellcheck - a bash linter
4. Ubuntu of course :-)
5. PyPI