Imogen Labs
Start a project

Eight.ly Backup Server

A backup has to come back.

Shipped

A completed upload is the start of a backup system. The harder questions are whether the next backup fits, whether the old one can be read, and whether a restore returns the same files. We built Eight.ly Backup Server around those questions.

Explore Eight.ly Backup Server
Inside Eight.ly Backup Server
  1. CaptureBack up machine data, application dumps or Docker volumes.
  2. Chunk and encryptReuse unchanged content and encrypt the backup data.
  3. RetainSnapshot indexes keep track of the chunks each version needs.
  4. Verify and restoreRead the snapshot, reconstruct the files and compare the result.

The problem

Copying everything again consumes storage and bandwidth. Keeping only a folder copy leaves questions about versions, integrity and what happened while an application was writing. A backup service also has to reclaim unreferenced data without deleting chunks that a retained snapshot still needs.

These are operational problems as much as storage problems. In September 2026, our own backup store filled its system disk. The backups existed, but the verifier could not read their indexes and cleanup had never reclaimed their unused chunks. The incident exposed a contract mismatch between the OS and the server.

Who it’s for

For Eight.ly OS owners, creators protecting production work, and operators backing up machines across Linux, macOS and Windows. It provides a separate backup target for a NAS or server, with deduplication for repeated data and a restore path that can be verified rather than assumed.

What we built

We built a content-addressed backup store, client-side encryption, compression and a browser interface for watching jobs and checking integrity. Content-defined chunks let successive backups reuse data that is already stored. The server is part of the Eight.ly system rather than a requirement to maintain another unrelated management stack.

We also built a cross-platform backup client with Docker volume support and hooks for application-consistent dumps. Historical round-trip verification covered Linux, macOS, Windows, Windows shadow copies and a Linux Docker volume. Those checks compared restored files with the originals, not just a successful upload response.

How it works

Data is divided into content-defined chunks so unchanged content can be shared across backup versions. The client encrypts the data, and snapshot indexes describe how the stored chunks reconstruct it. Integrity checks need to understand those indexes before they can say whether a snapshot is complete.

Retention has the same dependency. Cleanup first reads the retained indexes to discover which chunks remain in use. If an index is unreadable or truncated, it must stop. The September fix added support for both index layouts used by our products while keeping that refusal to delete on uncertainty.

What was hard

The real store made the defect undeniable. Both the relocated data and the untouched original failed verification in exactly the same way, which ruled out the move as the cause. Once the reader understood both formats, verification of that September 2026 store reported 38 snapshots and 2,038,174 chunks with none missing or corrupt.

Cross-platform support had its own trap: the first Windows path depended on a utility shipped with Windows Server. We replaced it with the shadow-copy interface available on client Windows too. The broader lesson is practical: restore on the operating system people actually use, and compare the resulting files. The original data gives the restored copy something concrete to answer to.

Have a similar problem?

Let’s build
what comes next.

Start a project