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.

Table of Contents (short)

• Quick start — try it in minutes
• Features — what dar-backup can do
• Why independent archives matter — the core design philosophy
• Documentation map — where to start learning
• Full documentation index — complete reference
• License — GPLv3

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)

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

Try dar-backup in minutes using the built-in demo:

# 1. Install dependencies (Ubuntu/Debian)
sudo apt install dar par2 python3 python3-venv

# 2. Create and activate a virtual environment
python3 -m venv ~/venv/dar-backup
source ~/venv/dar-backup/bin/activate

# 3. Install dar-backup
pip install dar-backup

# 4. Run the demo (creates sample archives, catalog db, and config)
demo --install
manager --create-db
dar-backup --full-backup --demo

What just happened?

• demo --install sets up a demo environment with test files
• manager --create-db initializes the archive catalog database
• dar-backup --full-backup --demo creates a full backup of the demo data

After each backup, dar-backup automatically:

1. Verifies archives with dar -t
2. Restore-tests random files byte-for-byte against source
3. Creates PAR2 redundancy files for bitrot repair
4. Notifies Discord on success/failure

Schedules are managed via systemd timers (auto-generated). Point-in-Time Recovery works through dar_manager catalogs — no database server needed.

Cleanup after trying the demo

To remove the demo directories:

demo --cleanup

This removes /tmp/dar-backup, /tmp/dar-backup-conf, and /tmp/dar-backup-data-dirs.

To uninstall dar-backup completely:

pip uninstall dar-backup
rm -rf ~/venv/dar-backup

Tested on Linux VMs

dar-backup is tested in fresh Multipass VMs created from standard distribution images. Each VM installs the distribution's DAR, PAR2, and Python dependencies before running the full pytest suite and mypy.

Latest full VM matrix: PASS at 2026-11-01T17:34:29Z for commit 644a6b0e44c1.

Each VM uses 2 vCPUs, 4G RAM, and a 40G virtual disk.

VM test methodology · Detailed and historical results

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
• 1500+ unit and integration tests — covering PAR2 bitrot repair, FULL/DIFF/INCR restore chains, PITR verification, and edge cases; run in CI, local large_scale tests and validated in Ubuntu and Fedora VMs.

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

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

user

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:       [email protected]
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 [email protected]

License

Licensed under GNU GENERAL PUBLIC LICENSE v3, see the supplied file "LICENSE" for details.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW, not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See section 15 and section 16 in the supplied "LICENSE" file.

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