Tink vs Tarsnap
Tarsnap stores encrypted archives behind a keyfile. That is not a mechanic. Tink installs in one command, watches the Linux host, explains what is wrong, and helps you fix it.
Tarsnap runs the archive. Tink answers “why is this VPS sick?”
Accidental sysadmins land on Tarsnap because a prepaid keyfile looks cheaper than a NAS. Then the host volume fills, nginx dies, and tarsnap --list-archives still looks complete — no archive match for host fill. A filling /var is a Tink warning; it is not a Tarsnap job unless you scraped cron mail and watched it.
Tink is the other job: detect the issue on the machine, say why it happened in plain English, propose the command, and run it only after you approve. Keep using Tarsnap if you already run archives. Use Tink if you run Linux servers and want a mechanic.
| Feature | Tink | Tarsnap |
|---|---|---|
| Setup time | 30 seconds (one curl | sh command) | Hours — tarsnap-keygen, tarsnap.conf, cachedir, prepaid balance, then a host that still has no mechanic after the last archive reports created |
| What you get | Working monitoring, diagnosis, and approved fixes | Encrypted archives and a keyfile. Disk fill, nginx, Postgres, and certs stay your problem until you SSH past tarsnap --list-archives |
| Pricing | Free (Scout) / $9 / $29 per machine per month | Pay-per-byte storage plus prepaid balance. You still pay the person who owns the VPS after the last tarsnap -c stays clean |
| Hidden costs | None — fully managed | A quiet overnight archive, a healthy keyfile that is not host fill, and a second tool to tell you the box is sick while --print-stats still looks complete |
| Monitoring approach | Agent on the server — CPU, disk, services, logs, certs, ports | Tarsnap client, keyfile, cachedir, and remote archives. Tarsnap does not watch a quiet cert or host auth.log after the last archive finished |
| Configuration | None after install — heuristics and AI | tarsnap.conf, keyfile path, cachedir, include/exclude lists, and which failed tarsnap -c actually pages you |
| Plain-English diagnosis | Yes — AI explains root cause, impact, and fix | You read tarsnap --list-archives and --print-stats, then SSH into the host to change the Linux box Tarsnap already sits on |
| Fix execution | Proposes and executes approved commands with an audit trail | tarsnap -c and tarsnap -d — Tarsnap cannot free host disk, rotate a cert, or stop SSH brute-force unless you archived that path |
| Alerting | Built-in across 8 channels | Not a Tarsnap job — cron mail from a failed tarsnap -c plus a separate monitoring tool have to fire |
| Predictive alerts | Yes — disk fills in ~6 days, memory and CPU trends | Not a Tarsnap job — an archive date does not forecast a quiet host filling up |
| SSH brute-force detection | Built-in — parses auth.log every scan | Never — Tarsnap does not read host auth.log, journald, or firewall state after the last archive landed |
| Machine offline detection | Agent presence monitoring with multi-channel alerts | Silence if the Tarsnap cron dies after the last timer — unless you built a separate uptime check |
| Public status page | Shareable URL with 90-day history | None — Tarsnap has no customer-facing status page for the Linux host |
| Weekly fleet digest | Automated Monday digest + daily brief when issues are open | None — a --print-stats recap is not a plain-English fleet narrative |
| On-call tracking | Built-in /oncall command + incident acknowledgment | Not included — wire failed tarsnap -c mail into PagerDuty or another incident tool |
| Conversation interface | Telegram, WhatsApp, web dashboard, CLI | tarsnap --list-archives and SSH. No mechanic you text when /var filled and the last archive still showed created |
| Learning curve | None — works after install | Steep — keyfiles, cachedir, prepaid bytes, include lists, and which failure is Tarsnap vs the running host |
| Best for | Freelancers, small teams, accidental sysadmins (1-50 Linux servers) | Teams that already run Tarsnap for encrypted archives, not a sick-VPS mechanic |
When Tarsnap is the right choice
Keep using Tarsnap when you already want that exact job:
- Client-side encrypted archives — you need tarsnap.conf, a keyfile, and prepaid bytes, not a mechanic.
- An existing backup stack — tarsnap -c timers, cachedir, and --list-archives matter more than guest nginx, certs, and SSH on a quiet VPS.
- An existing lab or nested setup — Tarsnap already runs, the keyfile already exists, and someone owns the prepaid balance.
- Hosts that only page on archive or keyfile death — you already run failed tarsnap -c mail, not a sick-box SSH loop.
The real cost of “just watch tarsnap --list-archives”
Tarsnap runs archives and a keyfile. A working ops loop for five Linux boxes is not:
- A healthy archive still means you SSH into the host and change the box by hand when it gets sick later
- Host fill, nginx, certs, and SSH brute-force never appear unless a separate tool scraped those signals and a rule fired
- A filling /var is a Tink disk warning on every scan — Tarsnap will stay quiet until the next tarsnap -c fails
- A single VPS with a dead agent still needs a mechanic, not another archive date
For a 5-server team, Tink Mechanic at $45/month is cheaper than the engineer who keeps failed-archive notifications alive after a prepaid Tarsnap balance, and every scan includes a diagnosis a quiet --list-archives will not type.
No tarsnap.conf homework. No silent host. One command install.
Start MechanicAlso compare: Tink vs Amanda · Tink vs restic · Tink vs Borg