The Single Point of Failure Illusion
We need to talk about what "archiving" actually means. A terrifying number of facilities think of an archive as simply the destination at the end of a project. You finish cutting a feature, you package up the assets, and you dump them onto a spinning hard drive on a shelf, or a single LTO tape in a vault. Problem solved, right?
Wrong. If your data exists in exactly one place, you do not have an archive. You have a ticking time bomb.
The archive is permanent
Once data is written to a tape or an S3 bucket, it is safely "put away." You don't have to worry about it anymore because enterprise storage media is designed to last.
All media is mortal
Hard drives suffer bit rot. Tapes get dropped, snapped, or degaussed. Cloud providers suffer localized outages, billing glitches, or go out of business. A single copy is always a single point of failure.
Redundancy is the only permanent solution. That doesn't just mean backing up your active work — it means backing up your archive, too. A true archiving system must guarantee that cold data is securely duplicated before it ever allows the original high-speed copy to be deleted.
N-Way Replication: What It Actually Means
You’ve probably heard of the 3-2-1 backup rule: three copies of your data, on two different media types, with one offsite. It is the gold standard for active production data. But when dealing with petabytes of cold archive data, maintaining three distinct copies gets expensive and architecturally complex.
This is where N-Way Replication comes in. Instead of relying on a human to manually clone drives or a rigid enterprise appliance that only speaks to proprietary tape libraries, HuskHoard lets you define N destinations for any given tiering policy. When a file gets cold, HuskHoard doesn’t just move it. It fans it out.
If you set N=2, HuskHoard writes a copy to your local bulk storage array and a copy to a cloud bucket. If you set N=3, it might write to a local tape, an offsite tape, and a glacier tier simultaneously. You define the N, and the daemon handles the plumbing.
The Media Diversity Rule
Why not just replicate to three hard drives and call it a day? Because identical media types share identical failure domains. If a power surge fries your NAS, it fries all the disks in it. This is why HuskHoard is built to span fundamentally different storage architectures.
How HuskHoard Replicates Under the Hood
In traditional setups, moving data to three different places requires a patchwork of rsync scripts, LTFS mounting utilities, and cloud CLI tools. HuskHoard abstracts all of this into a single atomic operation defined by a simple TOML policy.
When this policy executes, HuskHoard doesn't just copy the file sequentially. It leverages Rust's asynchronous I/O to perform the entire operation in parallel, ensuring the highest possible throughput while strictly verifying data integrity.
If the tape drive is busy or the network connection to S3 drops halfway through the dispatch, HuskHoard simply aborts the migration for that file. The original file stays intact on your fast storage. It will try again during the next policy run. Data is never deleted until redundancy is mathematically proven.
Reading from Replicas: The Fallback Mechanism
We know that HuskHoard uses fanotify to intercept read requests to stub files. But if a file has three replicas, which one does it pull from when a user double-clicks it?
The answer is a latency-aware decision engine built into the HuskHoard daemon. It evaluates the available replicas and automatically selects the path of least resistance, keeping your applications running smoothly without any user intervention.
fanotify.This fallback mechanism means you can lose your entire local backup array, and your users won't even notice. The next time they try to open an archived project, it might take a few seconds longer to buffer from S3, but the file will open. The path is still valid. The application has no idea that the local disk array is currently on fire.
The Catalog Knows All
Tracking identical chunks of data across completely disparate media types is complex. LTFS indexes only know about the tape they are written on. AWS dashboards only know about what is in the bucket. The Husk Catalog is the centralized ground truth that unifies them.
Because the catalog lives on your host machine and tracks the metadata of every single replica independently, you can verify your redundancy at a glance.
You can even ask HuskHoard to proactively verify the integrity of your replicas without pulling the whole file down, by comparing the recorded checksums against the live media.
By treating the filesystem path as merely a pointer to a catalog entry, and treating that catalog entry as a list of potential physical locations, HuskHoard frees your data from the fragility of any single piece of hardware. N-way replication isn't just a backup strategy — it is the only way to build an archive that outlives you.