Skip to the page
Get started

Docs · Administration

Storage and the audit trail

What has piled up, how to remove it, backups and restores, and the record of who did what.

#Storage

Storage in the sidebar, for admins and owners. It opens on four parts, listed in the sidebar: Overview, Tables, Maintenance and, for owners, Backups. Each has its own address, such as /storage/backups.

#Overview

Four figures:

  • the size of the database file, every workspace included, because the number does not otherwise add up against this workspace's tables;
  • the rows this workspace holds;
  • the largest table;
  • for owners, when the last backup was taken.

Below them, What takes the room ranks the tables by rows. Open one to look inside. Where it lives gives the file's path, with a button to copy it.

#Tables

One row per kind of thing, with a count, all scoped to this workspace: Checks, data sources, comparisons, apps, schedules, run history, kept run rows, known differences, environments, integrations, systems, library entries, and the activity log.

Four are deletable from here, and they are the ones that grow: run history, kept run rows, source runs and known differences. Everything else answers:

Rows here are deleted where they are managed, so that what depends on them is visible at the time.

Which is the right answer. Deleting a Check from a table view would hide the four things that go with it.

A table the licence does not cover is left out entirely rather than shown empty — a tab called Activity holding nothing would be a lie about the installation.

#Maintenance

#Remove old run history

Run history is the one thing here that grows without anybody deciding it should. Removing it loses the record of past runs, not the checks themselves.

Choose an age (30 days to a year) and confirm. The server accepts between 1 and 3650 days. Zero is refused, because delete everything including this morning's run is a different intention that should be stated differently.

It removes Check runs and source runs. It does not touch the audit trail.

#Reclaim disk space

An owner's, not an admin's.

Deleting rows does not shrink the file — the space is reused, not returned. This rewrites the database to give it back, and locks it for everybody while it does.

Everyone waits until it finishes, which on a large file can take a minute. Do it out of hours.

On a shared Postgres it is refused, with the correct explanation: reclaiming space there belongs to whoever operates the database.

#Backups

An owner's part. Every workspace on the installation is in each backup, so where the licence names the installation's owner, only that person can use it.

Every copy is taken with SQLite's own online backup, so it is safe while Mosaic keeps running. Copies are kept in a backups folder beside the database.

  • Automatic backups. On by default: one copy a day, at 02:00 on the machine's clock, keeping the last 7. Choose the time and how many to keep. A machine that was asleep at that hour takes the day's copy when it wakes. The schedule is kept beside the backups, not in the database, so restoring an old backup does not also bring back an old schedule.
  • Back up now. Before an upgrade, a big clear-out, or anything you may want to undo.
  • Download. Asks for your password again, because the file holds every workspace's data.
  • Restore. Asks for your password, then replaces the whole installation with the backup. Every workspace goes back to that moment. Before anything is replaced, a copy of the database as it is now is taken and listed as Before restore, so a restore can itself be undone. A backup from an older version of Mosaic is upgraded as it opens. One from a newer version is refused. If your session did not exist yet at the time of the backup, you are signed out.
  • Restore from a file. Upload a backup you downloaded, or one from another machine. It is checked first: it must be an intact Mosaic database. Then it joins the list, and you restore it from there.

Taking, downloading, uploading, restoring and deleting a backup, and changing the schedule, are all in the audit trail. A restore is recorded in the restored database, which is the one that carries on.

On a shared Postgres, Backups explains that the database's own tools do this job, together with MOSAIC_MASTER_KEY. On the hosted service, we take the backups.

#Observability

System and security events recorded for this workspace.

A top-level sidebar destination, readable by viewers — being told your own reconciliation broke is not a privilege.

Columns: Time, Event, Actor, Target, Detail. The actor is an email, or System. A key is recorded as a key rather than as a blank, so a key did this and a person did this are different events.

#What is recorded, and what is not

Two rules govern the whole log.

Only what changes who can reach what, or where data goes. A row per Check run would bury the nine events a year that actually matter, and runs have their own history.

Never the thing itself. A password reset records that one happened, never what was set. No credential, token or row of anybody's data reaches it.

So you will find: sign-ins and sign-outs, accounts added, removed, promoted, disabled or reset; workspace renames and deletions; the AI switch; publishing and unpublishing; API keys created and revoked; licences installed and removed; systems created and removed; history purged and the database compacted; and the meaning-and-schema decisions people made.

You will not find: individual runs, queries, or anything anybody's data said.

#Retention

There is none. Nothing ever deletes audit events — purging history does not touch them, and they cannot be deleted from the Storage screen, because a log an administrator can quietly edit is not a log.

The Observability screen shows the latest 500 for the workspace. The Storage screen can page further back.

Writing to the log never fails an action: a full disk loses audit rows rather than stopping work.

#What a run was computed from

Every run of a Check records the definition it used: its sources (with passwords masked), its comparisons, rules and parameters, stored once and named by a fingerprint. A run reopened later says whether the Check has changed since, and what — "Source Store POS — config.query changed" — so a figure from last month is never read as though today's rules produced it.

Only what decides the numbers is part of it. Rearranging the table's columns is not a change to the Check.

#The audit trail

Who did what: signing in and out, people and roles, publishing, keys, integrations — and creating, editing and deleting Checks, sources and comparisons. An edit is written down once per person, per thing, per ten minutes, naming the fields that changed and never their values, because a query is saved as it is typed and a keystroke is not an event.

#Exporting it

Admins and owners can export the whole trail as CSV from the activity screen — Export CSV — including the network address of each action, which the screen itself does not show. It is the file an auditor asks for, or the one a SIEM reads.