HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kimono-koans
httm
Rust2022–2024
kimono-koans / httm

httm

Interactive, file-level Time Machine-like tool for ZFS/btrfs/nilfs2 (and even Time Machine and Restic backups!)

Command LineSystems & InfrastructureSelf-hosted
Explore on GitHubRead Hacker News discussions
7Distinct people
29Mentions
1Explicit recommenders
1.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Interactive, file-level Time Machine-like tool for ZFS/btrfs/nilfs2 (and even Time Machine and Restic backups!)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

From the help and man page[0]: --roll-forward="snap_name" traditionally 'zfs rollback' is a destructive operation, whereas httm roll-forward is non-destructive. httm will copy…

mustache_kimono used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month29 dated mentions

Observed mentions: 2022-03-08 03:57:35 UTC to 2024-07-23 11:53:14 UTC.

012342022-03-01 00:00:00 UTC to 2022-04-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 commentsMar 20222022-04-01 00:00:00 UTC to 2022-05-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2022-05-01 00:00:00 UTC to 2022-06-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-06-01 00:00:00 UTC to 2022-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-07-01 00:00:00 UTC to 2022-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-08-01 00:00:00 UTC to 2022-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-09-01 00:00:00 UTC to 2022-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-10-01 00:00:00 UTC to 2022-11-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-11-01 00:00:00 UTC to 2022-12-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-12-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2023-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-01 00:00:00 UTC to 2023-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-03-01 00:00:00 UTC to 2023-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-04-01 00:00:00 UTC to 2023-05-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-05-01 00:00:00 UTC to 2023-06-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsMay 20232023-06-01 00:00:00 UTC to 2023-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-09-01 00:00:00 UTC to 2023-10-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-12-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2024-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-02-01 00:00:00 UTC to 2024-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-03-01 00:00:00 UTC to 2024-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-01 00:00:00 UTC to 2024-05-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-05-01 00:00:00 UTC to 2024-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-01 00:00:00 UTC to 2024-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-01 00:00:00 UTC to 2024-08-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 commentsJul 2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Mar 20222022-03-01 00:00:00 UTC2022-04-01 00:00:00 UTC312
Apr 20222022-04-01 00:00:00 UTC2022-05-01 00:00:00 UTC321
May 20222022-05-01 00:00:00 UTC2022-06-01 00:00:00 UTC101
Jun 20222022-06-01 00:00:00 UTC2022-07-01 00:00:00 UTC000
Jul 20222022-07-01 00:00:00 UTC2022-08-01 00:00:00 UTC101
Aug 20222022-08-01 00:00:00 UTC2022-09-01 00:00:00 UTC101
Sep 20222022-09-01 00:00:00 UTC2022-10-01 00:00:00 UTC101
Oct 20222022-10-01 00:00:00 UTC2022-11-01 00:00:00 UTC404
Nov 20222022-11-01 00:00:00 UTC2022-12-01 00:00:00 UTC202
Dec 20222022-12-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
Jan 20232023-01-01 00:00:00 UTC2023-02-01 00:00:00 UTC000
Feb 20232023-02-01 00:00:00 UTC2023-03-01 00:00:00 UTC000
Mar 20232023-03-01 00:00:00 UTC2023-04-01 00:00:00 UTC000
Apr 20232023-04-01 00:00:00 UTC2023-05-01 00:00:00 UTC101
May 20232023-05-01 00:00:00 UTC2023-06-01 00:00:00 UTC202
Jun 20232023-06-01 00:00:00 UTC2023-07-01 00:00:00 UTC000
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC101
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC202
Sep 20232023-09-01 00:00:00 UTC2023-10-01 00:00:00 UTC202
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC000
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC101
Dec 20232023-12-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
Jan 20242024-01-01 00:00:00 UTC2024-02-01 00:00:00 UTC000
Feb 20242024-02-01 00:00:00 UTC2024-03-01 00:00:00 UTC000
Mar 20242024-03-01 00:00:00 UTC2024-04-01 00:00:00 UTC000
Apr 20242024-04-01 00:00:00 UTC2024-05-01 00:00:00 UTC101
May 20242024-05-01 00:00:00 UTC2024-06-01 00:00:00 UTC000
Jun 20242024-06-01 00:00:00 UTC2024-07-01 00:00:00 UTC000
Jul 20242024-07-01 00:00:00 UTC2024-08-01 00:00:00 UTC312

What Hacker News says

29 sources
e12e·Jul 22, 2024
Hmm, this doesn't appear to be what I hoped it was: > Timeshift is similar to applications like rsnapshot, BackInTime and TimeVault but with different goals. It is designed to protect only system files and settings. User files such as documents, pictures and music are excluded. On the other hand, a quick search looking for "that zfs based time machine thing" did reveal a new (to me) project that looks very interesting: https://github.com/kimono-koans/httm
In Timeshift: System Restore Tool for Linux
mustache_kimono·Apr 14, 2024
Author here. Surprised as any one this on the front page of HN. > I don’t understand the use case. You go through the trouble of generating checksums when copying videos, but don’t want to regenerate the checksums when modifying the metadata? Appreciate the Q, but I suppose I really don't understand it. Could be the hour? I don't want to regenerate checksums once I know the underlying bitstream checksums are correct. I want to know the audio/video/whatever is the same as the day I received it, and I want to perform the exact same check to confirm. If I change the metadata, and I need to regenerate a checksum, I don't know that. > If you are this concerned about data corruption why not check the metadata also? One should of course. Please use ZFS, etc. There is perhaps no greater ZFS fan than me. See: https://github.com/kimono-koans
Read the rest
/httm But now imagine rewriting a stream to a different container. For instance, MP4 to MKV, or ALAC to FLAC. Wouldn't it be nice to know the bitstreams are the same?
In Dano is a wrapper for FFmpeg that checksums the internal file streams
mustache_kimono·Nov 25, 2023
> It's worth noting that copy_file_range is used by a lot of things. Yes, but the trigger feature, block cloning, only landed in the latest 2.2 release. If you immediately hopped on 2.2, and used a system with lots copy_file_range and FICLONE use, yes, you may have a problem (like, as you note, on Gentoo, where this problem surfaced). Most people were just hopping on the bandwagon. My distro ships 2.1.5, so I have a 6 month wait until this feature lands, so I was just building copy_file_range support into my ZFS apps, right before news of this bug hit.[0] > There are other things required to trigger the bug that are a lot less common though. Exactly. My guess is the incidence of this will exceedingly rare for the common user/small NAS user/etc. I've run a corruption detector[1], and what I've found mostly indicates false positives. F
Read the rest
ingers crossed, but, so far, no actual positive matches on a system with probably a little less than 1 million files. [0]: https://github.com/kimono-koans/httm [1]: https://gist.github.com/kimono-koans/2696a8c8eac0a6babf7b2d9...
In ZFS silent corruption bug found: replaces chunks inside copied files by zeroes
mustache_kimono·Sep 14, 2023
As others have noted, these are really opinionated suggestions. And while it's perfectly fine to have an opinion, many of these vary between "this isn't the way I'm used to Linux doing it" to the actually objectionable. The ones I find most personally objectionable: > - Don't make me name pools or snapshots. Assign pools the name {hostname}-[A-Z]. Name snapshots {pool name}_{datetime created} and give them numerical shortcuts so I never have to type that all out Not naming pools is just bonkers. You don't create pools often enough to not simply name them. Re: not naming snapshots, you could use `httm` and `zfs allow` for that[0]: $ httm -S . httm took a snapshot named: rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount > - collapse `zpool` and `zfs` into a single command `zfs` and `zpool` are just immaculate Un
Read the rest
ix commands, each of which has half a dozen sub commands. One the smartest decisions the ZFS designers made was not giving you a more complicated single administrative command. > - Provide an obvious way to mount and navigate a snapshot dataset instead of hiding the snapshot filesystem in a hidden directory Again -- you can do this very easily via `zfs mount`, but you'll have to trust me that a stable virtual interface also makes it very easy to search for all file versions, something which is much more difficult to achieve with btrfs, et. al. See again `httm` [1]. [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn... [1]: https://github.com/kimono-koans/httm
In ZFS for Dummies
Modified3019·Sep 5, 2023
Outside of it being a good idea to manually set `ashift=12` on each vdev creation (because disks lie and zfs’s whitelist isn’t omniscient. I’ve seen too many people burned by this) and `atime=off` for datasets (because burning IO updating the metadata because you’ve accessed something is just fucking stupid), the defaults are sane and you can basically refuse to care about them after that. Every system I’ve used has `compression=on` set as default, which currently means lz4. People set it manually out of paranoia from earlier days I think. For linux systems you can set `xattr=sa` and `acltype=posixacl` if you like, which offers a minor optimization that you’ll never notice. I suppose if you don’t like how much memory zfs uses for ARC, you can reduce it. For desktop use 2-4gb is plenty. For actual active heavier storage use like working wi
Read the rest
th big files or via a slow HDD filled NAS, 8GB+ is a better amount. Dataset recordsize can be set as well, but that’s really something for nerds like me that have huge static archives (set to 1-4MiB) or virtual machines (match with qcow2’s 64KiB cluster size). The default recordsize works well enough for everything that unless you have a particular concern, you don’t need to care. I should note, beware of rolling release linux distros and ZFS. The linux kernel breaks compatibility nonstop, and sometimes it can take a while for zfs to catch up. This means your distro can update to a new kernel version, and suddenly you can’t load your filesystem. ZFSbootmenu is probably the best way to navigate that, it makes rolling back easy. You also want to setup automatic snapshots, snapshot pruning, and sending of snapshots to a backup machine. Highly recommend https://github.com/jimsalterjrs/sanoid If you really find yourself wanting to gracefully deal with rollbacks and differences in a project, HotTubTimeMachine (HTTM) is nice to be aware of: https://github.com/kimono-koans/httm
In ZFS for Dummies
mustache_kimono·Jul 4, 2023
Excited, because in addition to ref copies/clones, httm will use this feature, if available (I've already done some work to implement), for its `--roll-forward` operation, and for faster file recoveries from snapshots [0]. As I understand it, there will be no need to copy any data from the same dataset, and this includes all snapshots. Blocks written to the live dataset can just be references to the underlying blocks, and no additional space will need be used. Imagine being able to continuously switch a file or a dataset back to a previous state extremely quickly without a heavy weight clone, or a rollback, etc. Right now, httm simply diff copies the blocks for file recovery and roll-forward. For further details, see the man page entry for `--roll-forward`, and the link to the httm GitHub below: --roll-forward="snap_name" tradi
Read the rest
tionally 'zfs rollback' is a destructive operation, whereas httm roll-forward is non-destructive. httm will copy only the blocks and file metadata that have changed since a specified snapshot, from that snapshot, to its live dataset. httm will also take two precautionary snapshots, one before and one after the copy. Should the roll forward fail for any reason, httm will roll back to the pre-execution state. Note: This is a ZFS only option which requires super user privileges. [0]: https://github.com/kimono-koans/httm
In ZFS 2.2.0 (RC): Block Cloning merged
mustache_kimono·May 11, 2023Recommendation phrase
From the help and man page[0]: --roll-forward="snap_name" traditionally 'zfs rollback' is a destructive operation, whereas httm roll-forward is non-destructive. httm will copy only files and their attributes that have changed since a specified snapshot, from that snapshot, to its live dataset. httm will also take two precautionary snapshots, one before and one after the copy. Should the roll forward fail for any reason, httm will roll back to the pre-execution state. Note: This is a ZFS only option which requires super user privileges. I might also add 'zfs rollback' is a destructive operation because it destroys snapshots between the current live version of the filesystem and the rollback snapshot target (the 'interstitial' snapshots). Imagine you have a ransom-ware installed and you need to rollback, but you want to view
Read the rest
the ransomware's operations through snapshots for forensic purposes. You can do that. It's also faster than a checksummed rsync, because it makes a determination based on the underlying ZFS checksums, or more accurate than a non-checksummed rsync. This is a relatively minor feature re: httm. I recommend installing and playing around with it a bit. [0]: https://github.com/kimono-koans/httm/blob/master/httm.1
In Bcachefs – A New COW Filesystem
mustache_kimono·May 11, 2023
Really excited about this. Once support hits in Linux, a little app of mine[0] will support block cloning for its "roll forward" operation, where all previous snapshots are preserved, but a particular snapshot is rolled forward to the live dataset. Right now, data is simply diff copied in chunks. When this support hits, there will be no need to copy any data. Blocks written to the live dataset can just be references to the underlying snapshot blocks, and no extra space will need to be used. [0]: https://github.com/kimono-koans/httm
In Bcachefs – A New COW Filesystem
mustache_kimono·Nov 28, 2022
> I’d hesitate to even mention l2arc or slog devices to someone that isn’t an experienced technical user, though, as they will probably go buy the wrong drives and may not even need the added complexity. Not just added complexity, I'd ask: Where is the performance gain? How likely is it on a home NAS you're ever going to hit the L2ARC, even if it is tuned to continually update and wear itself out? Very low. > Lastly, if you’re on zfs you can setup something like sanoid to automate snapshots. I just did that, hopefully it will save me next time I run rm -rf against the wrong folder by accident! PSA: sanoid is great and everyone should upgrade their experience of sanoid with httm[0]. [0]: https://github.com/kimono-koans/httm
In Building NAS with ZFS, AFP/Samba for Time Machine (2021)

Showing the 15 most recent of 29 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.