GNU tar has its own incremental index via `--listed-incremental=FILE`. Unlike Borg or Restic, which have their own more complicated repository formats, this leaves me with just one additional file (the `.snar`) alongside a dumb, portable full-disk tar archive.

The nice part is that, unlike repositories that require both read/write access patterns, tar can compute deltas using only the small `.snar` file, while the main `full-disk.tar` can remain buried in write-only Glacier storage. This makes it a much better fit for Glacier's write-once model and 180-day minimum retention.

My current plan is to upload a full-disk tar to an external HDD + Glacier on a weekly cadence, and the `.snar`-based deltas daily. That gives me a pretty simple cloud backup solution for a few bucks a month (after burning through $100+ of free credits).

Luckily tmux has a well-established "control mode" protocol designed for iTerm2 that can serialize internal state updates into a stream of text messages. So I do write client-side of this feature right inside tmux.

When it's ready, you will able to embed remote sessions inside local tmux instance by calling something like "ssh example.com tmux -CC attach". It will auto-detect "control mode" escape sequence and create special "remote session" you can switch into.

If you are interested, connect with me (snizovtsev@gmail.com) so I will notify when feature is ready and ask for early testing before making upstream proposal.

Earlier in my career, I managed to use Zopfli once to compress gigabytes of PNG assets into a fast in-memory database supporting a 50K+ RPS web page. We wanted to keep it simple and avoid the complexity of horizontal scaling, and it was OK to drop some rarely used images. So the more images we could pack into a single server, the more coverage we had. In that sense Zopfli was beneficial.