Backups and updates

What a backup protects

The thing worth protecting is not your media, which you have. It is everything the server built on top of it: profiles, watch history and resume points, collections and their rules, playlists, custom themes and artwork, your metadata corrections and which fields you locked, live TV sources and credentials, recording rules, API tokens, settings, and your server’s identity.

That last one matters more than it sounds. Restoring keeps the same identity, so as far as your account, your apps, and everyone you share with are concerned it is the same server. No relinking, no re-pairing every TV, no re-inviting anybody.

Setting it up

Settings → Backups.

• Where. Defaults to a folder inside the server’s data directory. Change it. A backup on the same disk as the thing it is backing up does not survive that disk dying. Point it at a second drive or a network share.
• When. Nightly, automatically. You do not schedule anything.
• How many to keep. Seven nightly and four weekly by default, adjustable in advanced settings.
• A passphrase, optional. Turn it on and archives are encrypted. There is no recovery: forget the passphrase and those archives are unreadable, and the page says so plainly rather than in small print.

Snapshots are small, roughly the size of your database, so nightly is cheap.

Recordings

Recordings are potentially hundreds of gigabytes, so they are not zipped into every snapshot. There is a separate opt-in setting that mirrors them to the same destination, copying only what is new each time.

Restoring

Settings → Backups lists your snapshots. Restore one, or upload an archive from somewhere else, which is how you restore onto a new machine.

Restore is all or nothing. It replaces the whole state and restarts the server. There is no picking out one profile or merging two histories, and that is a deliberate decision rather than a missing feature: merging two databases means matching identities across two sets of internal ids, and nobody in this category does it because the results are not trustworthy.

Before it replaces anything, it takes a snapshot of what is there now. So a restore is itself undoable, including the one you did by accident.

Because nightly snapshots are cheap, the practical “I deleted something yesterday” case is served by rolling back to last night and losing under a day of watch positions.

You can also download any archive through the browser, which is worth doing before a big change.

Standing a server back up from nothing

1. Install Multipass on the new machine.
2. Make sure your media is reachable at a path. It does not have to be the same path.
3. Open the new server, go to Settings → Backups, and upload your archive.
4. It restarts as your old server, with everything intact.
5. If the media is at a different path, use Move library on each library to point it at the new location. Your history survives that too.

Updates

The server checks once a day and tells you when there is something new. Nothing is ever applied without you clicking. There is no silent auto-update, and the daily check itself can be turned off.

An update waiting shows up as a badge in the top bar and, on Windows, in the tray menu. Settings → About → Update applies it, or Check now if you are impatient.

What applying does

1. Downloads the release and checks it against our signed manifest. A tampered or corrupted download is refused before anything is touched.
2. Swaps only the pieces that actually changed.
3. Restarts the server, keeping the previous version alongside.
4. Watches whether the new version stays up. If it crashes repeatedly, the old version and the pre-update database snapshot are put back automatically, the bad version is marked so it is not offered again, and you are told what happened.

You do not have to be watching when it applies, and you do not need to know how to roll anything back.

Docker is different

A Docker image cannot replace itself, because the tag is the version. The server still tells you a new release exists; applying it is:

docker compose pull && docker compose up -d

Applying updates on a server you do not own

You cannot, and neither can anyone else. Applying an update is the owner’s click on the machine’s own settings, deliberately.