In this article
A live mirror protects a storage path; recovering the intended model version needs independent artifacts and a tested procedure.
Mirroring and version recovery solve different problems
RAID1 keeps live block data mirrored across the configured members. That can help with availability when a member fails under supported conditions. It does not create an independent history of model artifacts, and it cannot decide that yesterday’s tokenizer was the version an operator intended to retain.
The Linux RAID documentation describes array behavior and operational state. Keep array health separate from the application recovery plan. A healthy mirror can faithfully contain an accidentally deleted directory or a newly deployed but unsuitable model revision, because those changes are part of the live data.
Define what must be recoverable
List weights, tokenizer files, configuration, necessary custom code and deployment settings with their versions or hashes. Decide which artifacts can be downloaded again from a pinned source and which contain local changes or are difficult to reproduce. The answer determines what a recovery record must retain beyond a working storage array.
For each item, document the independent copy or reproducible source, access conditions and expected retrieval time. A pointer to a mutable repository branch is weaker than a pinned artifact reference. Keep credentials and decryption-key availability in the recovery procedure without placing secret values into the public technical inventory.
Test restoration outside the live path
The Borg extraction documentation illustrates restoration as a separate archive operation with an explicit destination context. The broader principle is to restore into a controlled location and verify the recovered result before introducing it into the active serving directory. Restoring successfully is different from assuming a scheduled backup job must have produced usable data.
Use a bounded example containing a known artifact manifest and a small representative file set. Verify names, versions, hashes and access permissions. A file that exists but belongs to the wrong model revision should fail the recovery check. Retain the test result and the procedure version so the next operator can repeat it.
Keep recovery time and storage availability distinct
Consider an illustrative scenario where a mirrored volume stays online after a member problem, but an application rollout later requires an older model bundle. The first event concerns live storage availability. The second requires a versioned artifact and a controlled deployment, even though the array never stopped serving reads.
Record retrieval, verification, deployment and model-readiness intervals separately. Downloading the weights is not the complete service recovery. Array rebuild activity can also change the operating conditions, so preserve that context when measuring readiness instead of comparing it silently with an idle storage baseline.
Produce a recovery map
A practical map connects each required artifact to its retained version, independent recovery source, verification method and tested restoration step. Keep the array-health record beside it as a different form of evidence. This prevents a redundant-disk configuration from being mistaken for backup coverage and makes the actual version-recovery boundary visible before an incident exposes it.
If a small recovery fixture succeeds, state its size and contents. That evidence does not establish retrieval time for a full weight bundle or availability of every external dependency during a site failure.