Recovering a household document archive is mostly a sequence problem. You want to find the right backup, confirm that it is readable, restore a small file without touching the live archive, and only then bring back the larger folder. That order matters because a restore can overwrite newer work or expose a second problem: the backup exists, but its key, path layout or permissions are not available.

This guide assumes a Linux archive stored in a folder such as ~/Documents/Archive and a backup made with BorgBackup or a similar snapshot tool. The same decision process also applies to File History, Time Machine and a cloud-synchronised copy. It is a recovery procedure, not a promise that every deleted file can be recovered.

Stop and identify the recovery point

Do not begin by copying a backup over the live archive. First write down:

• the folder that is missing or damaged;
• the approximate date when it was last correct;
• the backup location, repository or service;
• the account, key and passphrase required to read it;
• a separate destination for the test restore.

Disconnect or pause any sync job that could propagate an empty or damaged folder. If the archive is on an external disk, mount it read-write only when the backup tool requires it, and check that the mount point is the one you expect. A second directory on the same disk is not protection against disk failure.

If you have several snapshots, choose one just before the loss and another earlier one. A recent snapshot may contain the mistake; an older one may contain the wanted document but miss later additions. Record the choice before changing anything.

Make a test restore first

Create an empty destination outside the live archive:

mkdir -p ~/Recovery/document-archive-test

Choose one small, non-sensitive document whose name and contents you know. Restore only that file, then check its filename, modified date and readable contents. If it is a scanned document, confirm that the expected pages open rather than trusting the file size alone.

The test answers practical questions before an emergency restore: can the backup be opened, is the passphrase available, do you know the archive name and stored path, and does the restored file belong to the expected date? If any answer is no, stop and resolve it before restoring the whole directory.

Recovering from a BorgBackup repository

List the repository and its archives before extracting anything. Replace the example path with your own repository:

borg list /media/you/BackupDisk/borg/document-archive

Use the exact archive name printed by that command. Borg stores paths as they appeared when the archive was created, so inspect the archive before selecting a file:

borg list /media/you/BackupDisk/borg/document-archive::ARCHIVE_NAME

For a dry run, Borg can read metadata and data, check hashes and HMACs, decrypt and decompress without writing files:

cd ~/Recovery/document-archive-test
borg extract --dry-run \
  /media/you/BackupDisk/borg/document-archive::ARCHIVE_NAME

When the test is satisfactory, extract one known path. The path below is illustrative; use the path shown by borg list:

cd ~/Recovery/document-archive-test
borg extract /media/you/BackupDisk/borg/document-archive::ARCHIVE_NAME \
  home/you/Documents/Archive/receipts/2026/example.pdf

Borg’s current documentation says extract writes into the current working directory, so cd to the destination first. It also notes that selecting only part of a tree can prevent parent-directory metadata from being restored. For a full recovery, extract the archive into an empty recovery directory, inspect it, and then merge the needed files deliberately.

Do not delete or prune the source archive after a successful extraction. A readable backup is still your fallback until the restored archive has been checked and copied to another safe location.

Recovering with File History or another snapshot system

Windows File History provides a useful model: open the folder that used to contain the file, choose Restore previous versions, select the date, preview it in File History, and use Restore to another location when you want to avoid replacing the current version. Time Machine and other snapshot tools have equivalent ideas: select a point in time, restore to a separate folder, and compare before replacing anything.

For cloud storage, check both the archived folder and the provider’s deleted-items or version-history view. Download a copy to the local recovery directory instead of moving the provider’s only copy. If a sync client reports conflicts, keep both versions until you know which one is authoritative.

Validate the recovered archive

Use a short checklist rather than a single successful command:

1. Count a sample of expected folders and compare names with your notes.
2. Open several PDFs, images and office files from different dates.
3. Confirm that OCR sidecars, indexes or metadata files came back if your search workflow needs them.
4. Check ownership and permissions before putting the directory back into a service.
5. Compare the newest recovered date with the selected backup date; newer files may belong to a different snapshot.
6. Save a manifest of the recovery point and any files that were missing or unreadable.

If the archive is encrypted, keep the key and passphrase with your documented recovery plan, but not inside the archive itself. If the restore exposes permission errors, first use the same Linux account that created the backup and inspect ownership. Avoid running the entire recovery as root unless you understand how that will affect later searches and edits.

Put it back without losing the evidence

Keep the recovered copy separate until validation is complete. When it is correct, rename the current live archive rather than deleting it, for example Archive-before-recovery, and move the recovered folder into place. Keep the old directory until a fresh backup and a small restore test both succeed.

If only a few files were lost, merge those files instead of replacing the whole archive. If the archive was damaged by malware, an accidental bulk rename or a failing disk, preserve the original evidence and consider a read-only copy before repair. A backup restore cannot undo changes made after the chosen snapshot.

Prevent the next emergency

Document the archive path, repository path, snapshot naming pattern, key location, restore destination and a contact who can follow the steps. Schedule occasional restore tests, not just backup jobs. Keep another copy in a different place; one external disk can be stolen, encrypted, destroyed or fail.

For the setup side, see the guide to backing up a local document archive with BorgBackup. For archive structure, the guide to organizing a home document archive is useful when deciding what a recovered tree should look like. Those pages describe preparation; this article focuses on safely bringing a known snapshot back.

Sources and limitations

The Borg extract documentation supports the dry-run, path-selection and current-directory details above. Microsoft’s File History restore guide supports the Windows workflow and the option to restore to another location. A community discussion on recovering an overwritten Mac file illustrates why recovery depends on having a usable previous version or backup, but it is anecdotal and is not used as authority for commands.

The safest recovery milestone is small: identify the right snapshot, restore one known file into an empty folder, and verify it. Only then restore the broader archive and keep the original backup untouched.