Point-in-Time Recovery Without the Enterprise Price Tag

description: A deep dive into HuskHoard's open-source PITR engine — how the catalog tracks version history and byte offsets across physical media, and how you roll back a single file without touching the rest of the volume. Point-in-Time Recovery Without the Enterprise Price Tag

If you've priced out Veeam, Commvault, or a Zerto license recently, you already know the punchline: granular point-in-time recovery is one of the most aggressively monetized features in enterprise storage. Vendors charge for it because it genuinely solves a hard problem — and because buyers are often in enough pain that they'll pay whatever it costs.

HuskHoard is an open source datatiering archive for Linux that ships PITR as a first-class feature, built directly into its catalog engine, free under AGPL v3. This post is the deep dive that the project's docs don't yet cover: how versioning actually works under the hood, how the catalog tracks byte offsets across physical media (disk, LTO tape, and S3), and how you roll back a single file without touching anything else on the volume.

Versioning vs Backup: Stop Using the Words Interchangeably

Before getting into mechanics, it's worth being precise about terminology, because these two words describe fundamentally different operations with different tradeoffs.

A backup is a complete redundant copy of a dataset at a point in time. The goal is full-loss recovery. If your server catches fire, you restore the backup. The cost is that you're duplicating data — 10 TB of active data requires at least 20 TB of total storage to have one backup copy.

Versioning (or PITR at the object level) is a historical record of how a specific file changed over time. The goal is granular rollback — recovering from an overwrite, a corruption, or a ransomware event that targeted specific files. It doesn't guarantee you can recover from total hardware loss unless your versions live on separate media. But it lets you say "give me /etc/nginx/nginx.conf as it was three weeks ago" without restoring your entire backup set.

The confusion is expensive. People who treat their archive as a backup get burned when the archive goes down (there's no redundant copy). People who treat their backup as a versioning system get burned when they need to roll back a single file and discover they have to restore 2 TB of snapshot data to get at it.

A solid DR strategy uses both:

Scenario	What You Want
Server catches fire / disk fails completely	Backup — full restore from a redundant copy
Developer overwrites critical config file	PITR — roll back that specific file in seconds
Ransomware encrypts 10,000 files	PITR — roll back affected files to pre-infection version
VM guest OS corrupts itself	Backup — restore the whole VM image
VM config file or snapshot is accidentally deleted	PITR — roll back just that object

HuskHoard handles versioning (PITR at the file/object level) natively. For full redundancy, pair it with N-way r…