Every machine’s backups: whether they were made, copied away from the house, and can be restored.
iAbout this page›
Jellyfin writes an archive, restic ships it to R2, and a second copy goes to the VPS. One week is kept, and then the archive is deleted from all three, which is why the ledger at the bottom of this page outlives it.
A backup that never left the house is the failure that matters most; a backup nobody can prove existed is the one after that.
Not measured hereThe nightly run does ship to R2 and to the VPS — the retention ledger below is its own account of that. What is not built is the rest of the measuring: nothing reports what R2 is holding or costing, nothing restores Jellyfin into a throwaway copy to see that it starts, and Jellyfin says only that it created an archive, so every stage after “created” reads as not done rather than as a tick. The monthly integrity check reads a slice of the data back, which proves the repository is sound — not that a restore of it would run.
R2 stored
11.8 GB
R2 cost / month
$0.18 · zero egress
Next run
03:30 nightly · in 5 h 40 m
Drill streak
5 weeks passing
Restore drills
last: pass
weekly · newest archive → throwaway container → checked against production
{{ d.sym }}← 12 weeks
PASS · Sun 24 Aug 03:12ameribrit-nightly-20260824 → containerusers 7 / 7items 15,879 / 15,881 · within tolerance4 m 12 s
An untested backup is a hope. The one failure (12 Jul) was a truncated upload — caught here, not on restore day.
Nothing on the server was changed. These are copies, in a folder only root can open: move what you need into place by hand over SSH, and look at it before you do. The folder is removed automatically seven days after the restore.
Not loaded{{ tiersWhy }}
No backup repository has been reported. The agent on the media server lists them once it has read-only access to the store.
{{ tr.name }}
{{ tr.stLabel }}
{{ tr.contents }}
Size{{ tr.size }}
Retention{{ tr.keep }}
Next run{{ tr.next }}
Last OK{{ tr.last }}
Last integrity check
{{ integ.line }}{{ integ.label }}
{{ integ.note }}
{{ integ.tail }}
On the media server
Only the newest archive stays on the media server. The rest of the week is in R2 and on the VPS.
iAbout this copy›
This is Jellyfin’s own listing, read from the server. The media server is where an archive is made, checksummed and shipped from, not where the week is kept; the ledger below is the record of the week.
Silent failureArchive was created and encrypted but never reached R2. The local copy is still on disk (1.9 GB) and counts toward the 5 GB free-space precondition.
Retention ledger
One week is kept. Anything older is deleted for real from the media server, the VPS and R2, and its row here is what is left of it.
iAbout Held›
Held means no deletion has been recorded for that store. The ledger writes down removals as they happen; it does not go back and re-count what each store still has.
Nothing in the ledger yet. It is written by the nightly backup on the media server — a line when an archive is made and one each time a store drops it — and the panel has not been sent any. Until it has run, this screen can only show what the stores still hold, which is the one thing a record like this exists to outlast.
A restore here never touches the live system. It copies files out of a snapshot into a root-only staging folder on a media drive and stops there. Putting a file back — or rolling Jellyfin’s database back from an archive, which means stopping Jellyfin first — is done by hand, by somebody who has looked at what they are putting back. Moving to new hardware is a different procedure again.
Restore files from a backup
The files are copied into a new staging folder on {{ hostName }}’s roomiest media drive, never over what is already there. Nothing is replaced and nothing restarts. Moving anything into place is done by hand afterwards.