Audit log
Every action that reads or changes user data, and most configuration changes, is written to Restow’s audit log, through the web interface, the integration API, or an admin-consent flow. This is not optional logging: the database itself rejects UPDATE/DELETE on the audit table (append-only).
What’s recorded
Section titled “What’s recorded”Each entry carries who (a user, an API key, or “system”), when, what (an action, e.g. “Restore requested” or “Admin consent granted”), for whom if it was done on someone else’s behalf (impersonation), the target (a mailbox, a source, a webhook, and so on), the tenant, and the IP address the request came from.
Categories span sign-in, sources, directory sync, backup, restore, verification, storage, settings, tenants and members, API keys, webhooks, licensing, the archive, endpoint backup, Proxmox VE backup, mail import and export, updates, the operator notice, and administrator access recovered on the server’s command line (restow admin recover, see Setup wizard).
Since 0.4.0 the log also records, among others:
| Area | Actions |
|---|---|
| File shares | file_share.created, file_share.updated, file_share.tested, file_share.password_changed, file_share.settings_changed, file_share.quota_changed, file_share.private_network_approved, file_share.private_network_withdrawn, file_share.backup_requested, file_share.restore_requested, file_share.restore_test_requested, file_share.run_cancel_requested, file_share.browsed, file_share.searched, file_share.download_created, file_share.downloaded, file_share.retired, file_share.reactivated, file_share.purge_requested, file_share.repository_password_shown, file_share.repository.denied |
| The mounter | mounter.enable_requested, then mounter.enabled or mounter.enable_failed (Enable network shares) |
| Immutable backups | storage.target.immutability_changed, storage.target.immutability_verified |
| Ransomware detection | suspicion.false_alarm, suspicion.false_alarm_revoked, suspicion.hold_released, settings.ransomware.updated |
| Notifications | report.matrix_updated |
| Agent policies | settings.agent_policy.updated, tenant.agent_policy.updated, endpoint.config.changed |
| Proxmox VE | pve.boot_test.requested, pve.snapshot.browsed, pve.snapshot.downloaded (also for the files of VMs) |
| Updates and the database | update.jobs_paused, update.jobs_resumed, update.dump.downloaded, update.dump.deleted, database.move.requested, database.move.started, database.move.succeeded, database.move.failed, database.old_copy.removal_requested, database.old_copy.removed |
Since 0.4.2 it records, among others:
| Area | Actions |
|---|---|
| Updates | update.planned (an update planned for a chosen time; dropping the plan writes update.cancelled with planned: true), update.plan_failed (a planned update could not start), update.fleet_started (nodes and agents asked to update), pve.node.update_requested (an update of a Proxmox VE node requested), endpoint.update_requested (an agent update requested) |
| Settings | settings.time_zone.changed (the installation’s time zone), settings.pve.updated (the Proxmox VE settings of the installation) |
| Stopping backups | pve.backup.cancelled (a guest backup), pve.queue.cancelled (queued guest backups withdrawn), pve.queue.paused and pve.queue.resumed (a node’s queue), endpoint.backup.cancelled (a machine’s backup). Runs of file shares are recorded as file_share.run_cancel_requested. |
| Proxmox VE repositories | pve.repository.reinitialized (a container’s repository was missing on the primary, a new backup chain began), pve.repository.reset (an administrator reset it) |
| The Restow server’s own VM | pve.guest.restow_server (a guest marked as the Restow server, or the mark taken back), pve.guest.self_backup_confirmed (backing it up with Restow confirmed) |
| Restore | snapshot.calendar.read (the calendar of a backup opened) |
Since 0.4.5 it records, among others:
| Area | Actions |
|---|---|
| License keys | license.installed, license.replaced and license.removed now carry the key’s update terms (series, updatesUntil, the signing key) and whether they cover the running version (License and editions). |
| Removing machines | endpoint.removed (with the mode, delete or keep until they expire), endpoint.removal.held, endpoint.removal.deferred, endpoint.removal.completed, endpoint.removal.failed (Uninstall) |
| Stopping and starting jobs | backup_job.run_cancelled (the backups of a mail, machine, file share or copy job stopped, on the job and, for machines, per machine as endpoint.backup.cancelled), pve.job.run_requested (a backup of every guest of a Proxmox VE job requested), pve.job.cancelled (the backups of a Proxmox VE job stopped) |
Since 0.4.7 it records, among others:
| Area | Actions |
|---|---|
| Objects no longer backed up | directory.inactive.confirmed (an administrator confirmed with Yes, intended that one object is no longer backed up) and directory.inactive.bulk_confirmed (the same for several at once). A note given through the API is part of the entry (Objects that are no longer backed up). |
| Proxmox VE | pve.guest.excluded (a guest excluded from backup, or included again; the entry carries the number of queued backups that were withdrawn before they reached the node) (Excluding a guest from backup) |
| Own app of a source | source.own_app.expiry_updated (the expiry date of the client secret of a source’s own app changed, without entering the secret again) (Reminders before an app credential expires) |
| Prices | settings.pricing.updated (the provider’s prices changed, with the values before and after) (Multi-tenancy) |
| Jobs | backup_job.updated now also records changes.archive when the recommended job switches the archive on in a mail job (Backup jobs) |
Tamper evidence
Section titled “Tamper evidence”Entries are chained per tenant (each entry links to the hash of the one before it) and sealed with a daily anchor, so a change made after the fact is detectable: it breaks the link to the next entry, or no longer matches the day’s anchor. In the viewer, Verify now re-checks the whole chain and reports exactly where a break is, if there is one, and since when entries can no longer be vouched for. Tamper-evident means a change shows up when the chain is checked; it does not mean that someone with full control of the database could not make one.
Finding entries
Section titled “Finding entries”In the viewer (Business and Service Provider), filter by tenant (provider admins can read every chain and choose “All tenants” or the installation’s own entries; tenant admins see their own tenant’s chain), action or action category, actor (email, name or user ID), target, and a date range, and open an entry for its detail. Every entry that reads user or backup data on someone’s behalf (an admin opening another user’s mailbox in Restore, a report generated across a tenant, a permission check) appears here too, not just the actions that change something.
Exporting the log (since 0.3.1)
Section titled “Exporting the log (since 0.3.1)”In the viewer, Export next to the filters downloads the entries that match the current filters, in one of two formats:
- As CSV (spreadsheet): one row per entry with the time, tenant, actor, the person acted for, action, target, IP address, details, the previous hash, the entry’s hash and whether the hash is valid.
- As JSON (with hashes to check the chain): every hashed field of every entry, oldest first, so the chain can be checked outside Restow. The file also carries the filters used and the formula of the hash.
One export holds at most 50,000 entries. If more match, the newest 50,000 are exported and the JSON file says truncated; narrow the period to get the rest. The export follows the viewer’s scope: provider administrators export any chain they may read, tenant administrators their own tenant’s. Taking the log away is itself recorded in the log (audit.exported, with the format, the filters and the number of entries). The delivery logs of alerts and reports export as CSV in every edition, see Alerts and reports.