Files

T

kyleandClaude Opus 5.5 d4e821799c Add an admin page for managing collector API keys

Admins (Microsoft 365 sign-in names in BACKUP_DASH_ADMINS) get an
Admin link to /admin.html, where they can create, list and revoke the
API keys collectors use, instead of running manage.py on the server.

Backend
- /api/v1/admin/keys (list, create, revoke), admins only (403
  otherwise); the user comes from the headers nginx sets after sign-in
- Changes need an X-Requested-By header, which another site's page
  can't add, so a signed-in admin's browser can't be used to forge them
- A new key is returned once; only its hash is stored. Names are unique
  for good, so revoked keys' history stays unambiguous
- Keys record who created/revoked them and the company they last
  reported for (schema v2; databases migrate automatically on start)
- /api/v1/me reports is_admin; manage.py shares the key code and
  records itself as creator/revoker

Frontend
- admin.html / admin.js: name validation shown after interaction
  (:user-invalid, aria-invalid kept in sync), the one-time key with a
  copy button (falls back to selecting it if clipboard access is
  refused), a key table flagging keys quiet for over 24 hours, and
  revoking confirmed in a <dialog>; results announced in a status region
- Shared el() and signed-in helpers moved to dom.js / signed-in.js
- Mock mode (?mock=1) includes sample keys

Tested: 15 new backend tests (access, forged requests, names,
duplicates, revoking, last-used company, v1 -> v2 upgrade); in the
browser, every admin flow in mock mode and at phone width; end to end
through the nginx config with the real API (a key created on the API
works for ingest; revoking it makes ingest 401; non-admins see an
explanation and no Admin link).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

2026-10-08 13:52:29 -06:00

tests

Add a Pester test suite for the collectors

2026-10-08 13:36:27 -06:00

Get-MarsCollectorDiagnostics.ps1

Fix MARS collector against a real agent's object model

2026-10-07 15:40:08 -06:00

Install-MarsCollector.ps1

Move code shared by the collectors into one module

2026-10-08 11:09:01 -06:00

README.md

Add an admin page for managing collector API keys

2026-10-08 13:52:29 -06:00

Send-MarsBackupStatus.ps1

Move code shared by the collectors into one module

2026-10-08 11:09:01 -06:00

README.md

Azure Backup (MARS agent) collector

A PowerShell script that runs on each server with the Microsoft Azure Recovery Services (MARS) agent and reports its backups to the dashboard. Each server appears as one job, named <SERVER> - Azure Backup by default.

Checked against: MARS agent 2.0.9274, a Files & Folders policy with completed backups only. Not yet seen on a real agent: a failed backup, a backup in progress, or a System State policy. Those paths are written to the same object model, but if one looks wrong, run Get-MarsCollectorDiagnostics.ps1 while it's in that state and send the output.

Install (on the server, as an administrator)

Runs under Windows PowerShell 5.1 (powershell.exe), which the agent's MSOnlineBackup module targets and which every supported Windows Server has.

Create a key for this server on the dashboard's Admin page, or on the dashboard host:
```
python manage.py create-key mars-acme-fs01
```
Copy the whole collectors folder to the server (the installer needs common as well as this folder), then from collectors\mars run:
```
.\Install-MarsCollector.ps1 -ApiUrl https://backups.example.com -Tenant "Acme Corp"
```
Add -JobName "File Server" to choose the name shown on the dashboard. It prompts for the key, then:
- writes C:\ProgramData\BackupDashboard\mars-collector.json (readable only by SYSTEM and Administrators)
- copies the script to C:\Program Files\BackupDashboard\
- registers the scheduled task Backup Dashboard - MARS collector (SYSTEM, every 60 minutes)

Preview the payloads, then backfill 30 days so the history view is populated straight away:

powershell.exe -File 'C:\Program Files\BackupDashboard\Send-MarsBackupStatus.ps1' -DryRun
powershell.exe -File 'C:\Program Files\BackupDashboard\Send-MarsBackupStatus.ps1' -LookbackHours 720

It can be installed alongside the other collectors: it uses its own config, state, log and task. Re-run the installer to change settings or update the script. It also installs BackupDashboard.Collector.psm1, the code shared by all collectors, next to the script.

What it sends

Dashboard	MARS
Company	`Tenant` from the config
Job	One per server, ID `mars:<computer name>`, so changing `JobName` renames rather than duplicates it
Status	Backup job state: Failed → Failed. Completed with failed bytes or an error → Warning. Aborted/cancelled or unrecognised → Warning. In progress → Running. Restore jobs are ignored
Started / finished	Job start / end time. MARS reports these in UTC without marking them as UTC; the collector handles that
Next scheduled	Next slot from the backup policy schedule, or the System State policy's if that's sooner. Empty (so never Overdue) for schedules that run every 2+ weeks, since which week is next can't be told
Message	Job and per-datasource errors (non-zero error codes), failed file counts, and the failed-file log path
Size	Bytes transferred, summed across datasources

Each run covers the last 48 hours (LookbackHours). Jobs already delivered are recorded in mars-collector.state.json.

Troubleshooting

Log: C:\ProgramData\BackupDashboard\mars-collector.log. Exit codes: 0 OK, 1 some runs failed to send (retried next run), 2 setup failed (config or MARS module).
Wrong status, sizes or messages: run .\Get-MarsCollectorDiagnostics.ps1 (read-only). It prints the real structure of the objects the agent's cmdlets return.

Testing without MARS

. ./tests/MockMars.ps1
./Send-MarsBackupStatus.ps1 -ConfigPath ./my-test-config.json -DryRun