httm: File-Level Recovery for Unix Snapshots

Why httm Exists Alongside Whole-Dataset Snapshots

ZFS, Btrfs, and NILFS2 can preserve historical filesystem states, but the README says those systems are not designed around finding unique versions of one file. That gap matters when a configuration file changed six times across six snapshots and an administrator needs the version used before a service stopped working. Restoring the entire dataset may expose unrelated files to the same old state.

httm addresses that file-level problem. It searches snapshot locations for versions of selected files, removes duplicate versions according to modification time and size, and presents each remaining version with its size, date, and location. The same interface can lead to an interactive restore instead of a full filesystem rollback. This makes the tool most relevant to administrators who already maintain snapshots but do not want to use snapshot selection as their normal file-recovery method.

The project is aimed at Unix and Linux command-line users, including ZFS and Btrfs operators, homelab administrators, FreeBSD users, and people managing backup copies through rsync, Restic, or Time Machine layouts. Its support for non-copy-on-write datasets is particularly useful when snapshots come from mounted backups rather than local filesystem features. The README also describes deleted-directory traversal, checksums, parseable output, and optional shell bindings.

httm does not create a complete backup policy. The README does not explain scheduling snapshot creation, retention enforcement, remote transport, integrity reporting for the entire backup set, or recovery from a failed backup service. Those responsibilities remain with the snapshot or backup system supplying the stored versions.

How httm Builds a File History

The documented architecture begins with filesystem locations, not with a separate version database. httm searches multiple datasets and snapshot mounts, compares file metadata, and reports the locations of distinct versions. The README states that uniqueness can be determined from metadata alone, as rsync can, or through checksums. Metadata deduplication can treat files with the same modification time and size as equivalent, while checksum comparison can expose versions that share those attributes.

The tool supports more than one path to historical data. It can inspect local snapshot versions and locally replicated versions. It can also search remote backup pools, including layouts in which replicated remote directories are overlaid over live directories. For datasets without filesystem snapshots, it can use directories synchronized with rsync, covering filesystems such as ext4, XFS, and NTFS when those directories represent useful history.

Deleted files are another specific part of the model. According to the README, recursive search can list deleted files and can reach files hidden behind deleted directories. A path lookup against the live filesystem alone would miss an old entry once its parent directory has been replaced or removed.

Results can be emitted in newline, null, tab-delimited, JSON, and CSV styles. This allows direct terminal reading as well as processing by another script. The default preview command is a `diff` comparison with the live file, but the project permits a custom preview command. Restore operations can be guarded by precautionary snapshots, while a roll-forward operation can copy a selected historical file forward without deleting intervening snapshots.

Installing httm from Source on a Unix Host

The README suggests packages for support purposes, including tagged native packages for Debian-based and Red Hat-based distributions, a community Homebrew formula, and an unsupported personal package archive. Its source installation uses Cargo. The documented `cargo install --locked` command selects the repository's latest release tag. The executable is placed under `$HOME/.cargo/bin` unless the user moves it elsewhere.

The following is the README's source build sequence after Rust is available. The command installs the tagged `httm` release from the Git repository.

latest="(wget -nv -O - "https://api.github.com/repos/kimono-koans/httm/releases/latest" 2>/dev/null | grep tag_name | cut -d: -f2 | cut -d'"' -f2)"
cargo install --locked --git https://github.com/kimono-koans/httm.git --tag "$latest"

The project also documents this remote installation script. It downloads and executes a script from the repository's `master` branch.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/kimono-koans/httm/master/packaging/install-from-source.bash)"

The README does not publish exact first-run output, so there is no supported result to quote. Its optional zsh integration installs file-selection and snapshot-browsing key bindings.

httm --install-zsh-hot-keys

That command documents `ESC+s` for dropping selected snapshot filenames onto the command line and `ESC+m` for browsing all snapshots of a file. The man page is separate because Cargo does not install it automatically. Its documented installation copies the page into a directory already present in the system man path.

cp ./httm/httm.1 /usr/local/share/man/man1/

A First File Browsing Session

The shortest documented starting point is to run the installed `httm` executable from a shell session. It is a Rust CLI intended to operate over filesystem paths, so the first meaningful session depends on whether relevant snapshot mounts, replicated snapshot directories, or rsync history are already visible to the local account.

httm

The README describes the output as file sizes, dates, and corresponding snapshot locations for unique versions. It does not document a universal argument-free startup state, so users should not expect identical behavior across ZFS, Btrfs, Restic, Time Machine, and rsync layouts. If no files are listed, the relevant local paths or mount configuration are the first items to check.

A practical first session should remain read-only. Start by locating one file whose history matters, compare its displayed versions, and inspect the associated snapshot path. The default preview compares a snapshot version with the live file using `diff`. A selected historical version can then be restored through the interactive restore mode. Before restoring, httm can create a precautionary snapshot, but that safeguard does not replace testing the target path or checking whether the destination is writable.

The README also describes interactive browse, select, prune, and restore modes. Those modes are not interchangeable: pruning acts on snapshot names containing a filename, while restore selects a file version. It also lists shortcut options for showing only the last snapshot and omitting duplicates of the live file. These controls help reduce noise, but the exact flags should be discovered through the packaged man page.

Checksums, Previews, and Restore Safety in httm

Metadata deduplication is the most consequential design choice. The README describes default unique-version detection based on modify time and size. This is inexpensive and follows the comparison model associated with rsync, but it cannot guarantee that two files with identical metadata are identical. httm therefore also offers checksum-based uniqueness checks. That option is appropriate when equal-size files with preserved modification times make metadata-only results ambiguous.

Checksum verification is not a complete backup audit. The feature concerns deciding whether individual file versions are unique. The README does not say that httm verifies every block, reports repository corruption, or replaces a snapshot pool scrub. Repository integrity should remain a responsibility of ZFS, Btrfs, Restic, Time Machine, or the applicable backup system.

Previewing is similarly bounded. The default `diff` comparison gives a quick view of differences between a historical file and its live counterpart. A custom command can change that presentation, but its output depends on the selected command and file type. Binary files, permission changes, extended attributes, directory structure, and ownership are not documented as complete parts of the preview workflow, even though httm has optional build features related to extended attributes and ACLs.

For restoration, the README describes precautionary snapshots and forward restoration. Forward restoration avoids replacing the current history with an older snapshot state and preserves intervening snapshots. It does not make the destination safe by itself. Path ownership, permissions, parent directories, and application-specific state must still be considered. The repository is interactive first, but it also offers machine-readable output for scripts that need to make their own restore decisions.

Where httm Differs from rsync and Whole-Pool Tools

rsync is the clearest documented comparison point. httm explicitly says it can work with datasets synchronized using rsync and follows a related uniqueness concept based on file metadata. The approaches differ in purpose: rsync transfers or replicates files between locations, while httm searches already available history and exposes file versions for browsing or restoration. An rsync deployment can therefore supply reusable historical directories without making rsync itself a file-version browser.

Compared with whole-pool snapshot selection, httm changes the unit of recovery. Selecting an older filesystem snapshot can restore a broad set of files and metadata at once. httm instead identifies a particular file version and its source location, which is more appropriate when only one configuration or document needs recovery. Its README also says that httm can roll forward to a previous file snapshot, avoiding destruction of later snapshot states.

The tradeoff is that httm depends on correctly exposed storage. Snapshot files hidden inside an unmounted dataset are not available merely because their parent filesystem supports snapshots. Remote repositories must also be accessible in layouts that httm recognizes. The README does not claim that every ZFS property layout, Restic repository configuration, or Time Machine directory arrangement can be searched without preparation.

The packaged scripts, including `ounce.bash`, `bowie.bash`, `equine.bash`, and `nicotine.bash`, indicate that httm is intended to compose with shell workflows and interactive selectors. They are examples rather than required components. Basic listing and restore operations depend on the `httm` executable and discoverable history, not on a mandatory front end.

Maintenance, Packaging, and MPL-2.0 Costs

The repository is not archived. Its last push was on 2026-09-18, matching the date of release `0.51.0`. The release history also lists `0.50.2` on 2026-06-30 and `0.50.1` on 2026-06-08. These dates show recent source and release activity, but the repository does not promise a fixed support window or long-term release schedule.

Native packaging is fragmented by design. Tagged releases may contain packages for Debian-based and Red Hat-based systems, while the README points Arch users to an example `PKGBUILD`. The Arch example includes a warning that it may need editing for the latest release. Red Hat users may also need `rpm -i --replacefiles` according to the linked issue. Package differences and community-maintained archives add operational variation when a system cannot build directly with Cargo.

The optional ACL build feature requires `libacl1-dev`, as stated in `Cargo.toml`. Default features include standard-library support, extended attributes, and `malloc_trim`; ACL support is not part of the default set. This matters when packaging because administrators may need system development headers beyond a Rust toolchain.

The project uses the MPL-2.0 license. Distribution or modification should be reviewed against the MPL-2.0 terms and obligations applicable to the files involved. Upgrades also require attention to snapshot compatibility and CLI behavior between releases, because the release listing does not define a long-term upgrade contract.

Editorial conclusion

httm suits Unix administrators, homelab operators, and backup users who understand snapshot layouts and want selective file recovery rather than whole-pool rollback. It is a poor fit for users expecting a self-contained backup system, automatic retention policy, or unattended restore workflow. Before adoption, verify that available snapshot mounts or backup directories can be discovered by httm, decide whether metadata-only or checksum-based uniqueness is appropriate, and test restores in a non-production path.

Frequently asked questions

Official sources

1. kimono-koans/httm on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases