Manual · Chapter 6

Keeping it alive

The lab is easy to build and easy to neglect. This chapter is the part that decides whether you still have your photographs in five years.

Backups that would restore #

There are three different things here and people confuse them constantly.

Read one back

A copy nobody has ever read back is not a backup; it is a hope. Verify on the Librarian page opens a catalogue snapshot and says whether it would actually restore. Do the same with your real backups, on a schedule, by actually restoring one file.

The one number worth knowing: how long since anybody proved a backup would restore? If the answer is "never", you do not have backups yet.

Standing jobs #

Households do not remember, which is how the only copy of the photographs gets lost. Health carries four standing jobs — scan, back up, verify a backup, refresh availability — each with an interval and a switch. Backups default to on.

They run when Ultralab is open and something is due. There is deliberately no background service: a daemon is another thing to install, supervise, upgrade and secure, and it would sit there with full access to your data root at all times.

On a Linux lab host that is on all the time, export the systemd timer instead. It calls the binary with --run-schedules, headless, on the machine that is already up.

A job that has not run because the app was closed says so rather than pretending it ran.

Updating safely #

Updating an application

Use Versions on the Apps page. Name a released version; Ultralab re-resolves the digest, re-renders and re-applies — keeping the previous render. If it goes badly, Roll back puts the old one back. That net is the reason offering an update at all is reasonable.

Check for rebuilt images tells you when something you are pinned to has been rebuilt upstream under the same tag, usually for a security fix.

If you are nervous about a particular update, an application being tried in the Sandbox is updated there, not Live. That is the free version of this decision.

Updating Ultralab itself

1. Save a Build first. If the new version disagrees with you about something, you can get the arrangement back.
2. Snapshot the catalogue from Health.
3. Download the new binary and check its hash.
4. Stop the running Ultralab, replace the file, start it again. Your data root is untouched — the binary is not where anything lives.

The window title and --version both tell you which one you are running.

Restoring #

Restore on the Librarian page replaces the whole Ultralab database from a snapshot — members included. You will be signed out afterwards, because the account you were signed in as came from the database that was just replaced.

It waits for any running job rather than racing it. Replacing the database under a running scan is how a catalogue gets corrupted.

If the machine is gone entirely: install Ultralab on the new one, restore your files from the real backup, load your Build to get the arrangement back, install the applications, then scan. The Build turns "which fifteen things did I have and how were they configured" from an evening into a minute.

When something breaks #

An application will not start

1. Check Values on the Apps page. Something it needs may be unset — it will be named.
2. Check for a port clash. Two things wanting the same port is the commonest cause.
3. Look at Health for what the runtime reports.
4. Install Dozzle from the catalogue and read the container's own logs. Nine times in ten the application is telling you exactly what is wrong.

The disk is full

Health will have been saying so. Recycle extras on the Librarian moves spare byte-identical copies to backups/recycle — and refuses to move a last remaining copy. Then look at Variants: the same film in three encodes is usually where the space went.

Nothing in Ultralab deletes anything to free space. Recycled files sit in a folder until you remove them yourself.

The Librarian says files are missing

Something moved or renamed them outside Ultralab. Relink reattaches the entry to where the file is now. If it really is gone, Forget removes the entry.

I cannot reach the lab from outside

That is the VPN, not the applications. Check the peer is connected on the device; check you are using the lab's network address once it is. If you are looking for a port to forward on your router, stop — that is the thing this design exists to avoid.

I forgot the steward password

There is no reset, because there is nobody to prove who you are to. The Ultralab database is lost; your files are not. Move ultralab.sqlite aside, start Ultralab, create a new steward, and scan your Datasets again. Load a Build to get the arrangement back.

Something looks wrong and I do not know what happened

Read the Audit. Installs, uninstalls, share grants, Build loads, restores and Sandbox resets are all in there with the login that did them.

A short list of habits #

• Sandbox first. It costs a few minutes and it cannot touch your files.
• Read "What will this do?" at least for anything that mounts photos/ or media/ writable.
• Save a Build whenever the lab is in a state you would be annoyed to lose.
• Restore one file from your real backup, once, on purpose. Then again in six months.
• Keep the admin list short.
• Never forward a port to make something reachable. Enrol a peer.
• Read Health when you open the app. It is four seconds and it is how you find out the disk has been at 95% for a fortnight.

← Chapter 5 · Back to the contents