Good backup software already exists. Before starting another project, we wanted to understand whether our requirements could be met by extending what we already use.
Our starting point was BorgBackup. We value its deduplication, client-side encryption, efficient incremental storage, and convenient access to archived files.
For our purposes, however, two requirements remained: an integrated pull model and a minimum retention period that the backup server can enforce independently of the client (for ransomware protection).
8472backup is our plan to bring those properties together in a focused, fully open-source tool.
🔍 We Started with Borg
Our original idea was to extend Borg with a server-side option along the lines of:
borg serve --protect 7dThe intended guarantee was straightforward: every successfully completed snapshot would remain fully recoverable for at least seven days, regardless of subsequent client requests or retention changes.
We explored contributing this through a pull request and discussed the approach with Borg maintainer Thomas Waldmann. Our understanding of his feedback was that the goal had merit, but implementing and maintaining it within Borg’s architecture would be difficult.
The apparent simplicity of the option hides substantial responsibility. The server needs a trustworthy completion timestamp, an independent record of protected snapshots, and reliable knowledge of every object those snapshots require.
Borg’s architecture places much of that knowledge on the client, with important metadata encrypted from the server’s perspective. Adding our guarantee would therefore reach well beyond an extra command-line option.
🔄 Why We Prefer Pull
In a typical push setup, each source machine initiates its backups and holds credentials that permit access to the backup destination.
With pull, the backup server controls when a backup starts. It connects to a source machine through SSH and invokes a restricted backup client. The client reads the selected files, encrypts the data locally, and returns it through the connection.
This concentrates scheduling and backup access control on the machine we can harden most consistently: the backup server.
We still secure every source host. The practical advantage is that protecting existing backup history should not depend on every one of those hosts remaining uncompromised.
Clients will also need restricted access for operations such as registration, restore, and mounting snapshots. Those operations must carry only the permissions they require.
🛡️ Pull Needs an Independent Protection Rule
Pull alone does not guarantee that old backups survive an attack.
A compromised source machine can supply damaged data, omit files, alter its backup description, or attempt to influence later retention decisions. Even a server-initiated backup must treat everything arriving from that machine accordingly.
Our planned rule is:
Every successfully completed snapshot remains protected for a configurable minimum period, measured from its server-recorded completion.
We currently plan a default of seven days.
Client retention settings may keep a snapshot longer. They cannot shorten the server’s protection period.
The protection covers the complete restorable snapshot, including unchanged chunks first stored months earlier. An object can only be reclaimed when no retained snapshot needs it and no active operation still depends on it.
🧹 Automatic Cleanup Is Part of the Design
Append-only access is a useful building block, but ongoing backup operation also needs storage reclamation.
We want the server to apply retention and reclaim unused space automatically, within explicit protection rules. Administrators should not have to suspend the protection model whenever routine maintenance is due.
This is one reason the server needs its own immutable record of completed snapshots and their object references. A later backup must never be able to rewrite the dependencies of an earlier protected snapshot.
If storage fills up, the system must preserve that guarantee rather than silently deleting protected history to make room.
🔐 The Server Must Never Need Decryption Keys
Our design separates responsibility for confidentiality from responsibility for retention.
The client encrypts backup contents before transmission. The server stores the encrypted objects and manages their lifecycle without receiving the keys needed to decrypt them.
To do that, the server will retain operational metadata such as snapshot identities, completion times, object references, and stored sizes. File contents, names, and directory structure will remain encrypted.
We consider that a useful architectural trade-off. The server learns enough to manage storage safely, while the contents remain confidential.
Encryption keys will be independent across hosts, with a planned choice between host-wide and per-backup-set keys.
📦 Familiar Strengths, Different Responsibilities
We want to retain the properties that make tools such as Borg attractive:
- Content-defined chunking and deduplication.
- Compression and client-side authenticated encryption.
- Incremental transfer and storage.
- Complete snapshots without a dependency on the first backup.
- Command-line restore and read-only snapshot mounting.
Our goal is a small system with understandable behaviour and explicit configuration. Performance and storage efficiency comparable to Borg are goals we will need to measure.
🧭 Why a Separate Project?
We considered extending an existing system first. That remains an important distinction in how we arrived here.
An extension that changes fundamental trust assumptions can become expensive to maintain. A fork must follow upstream development, while an upstream contribution must remain compatible with the project’s architecture and direction.
A separate project gives us control over the storage format, protocol, and protection rules from the beginning. Established libraries can still provide cryptography, compression, and other performance-sensitive operations.
That freedom comes with responsibility. Reliable commits, crash recovery, integrity checking, and correct restoration will be central engineering tasks.
🐧 Linux First, Fully FOSS
We plan to implement 8472backup in Python, using established native libraries through Python bindings where appropriate.
Linux will be the reference platform for both server and client in version 1.0. We will account for portability in the architecture, with other client platforms following later.
The software is intended to be fully FOSS. There will be no freemium edition or paid unlock for protection and recovery features. Optional commercial support may help fund the work.
🚧 Where We Are Today
8472backup is currently in its early design phase. It is not available for production use.
Our next work is to turn the protection guarantees into precise storage and protocol rules, then build and test them incrementally—including what happens when operations fail or a client behaves maliciously.
The project begins with a practical requirement: efficient encrypted backups whose existing history remains protected independently of the machines being backed up.
And yes, the name is a Star Trek Voyager reference. Similar territory, different species. 😉