Pull-based backups. Client-side encryption. Server-controlled protection.

We are designing 8472backup as a focused backup system for administrators who want efficient storage, straightforward operation, and protection for existing backups even when a source machine has been compromised.

The project is currently in its early design phase. The features below describe our intended architecture and scope.

💡 Why We Are Building It

Our experience with existing backup tools has shaped what we want from 8472backup: efficient storage, straightforward administration, and protection enforced independently of the source machines.

BorgBackup gets many things right: deduplication, client-side encryption, incremental backups, and convenient access to archived files. We want to combine those strengths with a different operating model: centrally initiated pull backups and a minimum retention period enforced by the backup server itself.

8472backup grows out of that practical requirement.

🔄 Pull, Centrally Managed

The backup server will initiate scheduled backups by connecting to source machines through SSH and starting a restricted backup client.

Each client will describe what to include and exclude in a backup description file. Multiple backup sets will allow different selections and retention policies on the same host.

The server will coordinate backup runs and manage storage. Clients will also be able to initiate specific operations, such as registration, restore, and mounting snapshots, through restricted SSH access.

Our aim is a setup that remains understandable as the number of protected hosts grows.

🔐 Encryption Stays on the Client

Backup contents will be encrypted before leaving the source machine. The backup server will store encrypted data without receiving the keys needed to decrypt it.

We plan to support independent encryption keys per host or per backup set. Keys will never be shared across hosts.

The server will retain the metadata needed to manage snapshots, object references, and storage cleanup. File contents and filesystem metadata, including names and directory structure, will remain encrypted.

🛡️ (Ransomware) Protection Enforced by the Server

Every successfully completed snapshot will be protected for a configurable minimum period, initially planned to default to seven days from its server-recorded completion.

During that period, client retention settings will not be able to remove it. All data and metadata objects needed to restore the snapshot will remain protected, including unchanged chunks originally stored by much older backups.

After the protection period expires, normal retention rules will determine whether the snapshot remains.

This is intended to let the server reclaim space automatically while preventing a compromised client from destroying protected backup history. The guarantee depends on the backup server remaining secure; it cannot establish whether newly supplied source data is trustworthy.

📦 Incremental Storage, Complete Snapshots

We plan to use content-defined chunking, deduplication, and compression to reduce storage consumption and network traffic.

Each snapshot will describe a complete backup state while reusing data already present in the repository. Restoring a retained snapshot will not require keeping the first backup or replaying a chain of incremental archives.

Deduplication will operate within the configured encryption boundaries, without sharing data between different hosts.

🐧 Linux First

8472backup will be implemented in Python, using established libraries for performance-sensitive operations.

Linux will be the reference platform for both server and client in version 1.0. We will account for portability in the design, with additional client platforms following later.

The planned Linux feature set includes a systemd server service, command-line backup and restore operations, and read-only snapshot mounting through FUSE.

🧭 A Focused Scope

We want predictable behaviour, explicit configuration, and recovery procedures that administrators can understand and test.

Our development priorities include interrupted operations, crash recovery, integrity checks, and safe storage cleanup. Performance and storage efficiency comparable to Borg are engineering goals that will need measurement.

We intend to keep the system small enough to inspect, maintain, and operate with confidence.

🤝 Fully FOSS

We intend to release 8472backup as fully functional free and open-source software.

All features, including protection and recovery capabilities, will be available without a paid tier. There will be no freemium edition.

We are considering optional commercial services such as deployment assistance, migration, configuration reviews, and support. Payment would cover our work and agreed availability.

🚧 Project Status

8472backup is currently an architecture and design project. It is not yet available for production use.

We will publish development progress, technical decisions, and releases as the project takes shape. If you operate Linux backups and recognise the need for this combination of pull, encryption, and server-enforced protection, we would welcome hearing about your requirements.