DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

Backups and data cleanup

Creating backups, scheduling cleanup, and the restore boundary you need to plan around.

How-toAdministratorOperator

Key points

  • Backups are gzip-compressed JSON Lines files written under DATA_BACKUP_DIR, defaulting to /data/backups.
  • The product supports backup creation, listing, checksum metadata, download, and cleanup.
  • Cleanup can be previewed before it runs, and can be scheduled with enable, disable, and run-now controls.
  • The default Compose topology does not mount the backup path as durable storage.
  • Settings are GitOps-managed through setting/system/data-management.yaml.

Before you start

Access
Administrator access to system data settings
Backups
A current database backup, since cleanup deletes records permanently

Steps

  1. 01

    Preview before deleting anything

    Preview reports what a cleanup would remove under the current retention settings without removing it.

    Preview a cleanupbash
    curl -sX POST "$NOPSAI_URL/v1/system/data/cleanup/preview" \
  -H "Authorization: Bearer $NOPSAI_TOKEN" \
  -H "Content-Type: application/json" \
  --data @cleanup.json | jq
    Replace before running
    • cleanup.json carries the retention window and the record types to consider.
    Expected result
    • Counts per record type. Nothing is deleted by a preview.
  2. 02

    Run it once, deliberately

    A manual run is the right first step: it produces a job record you can inspect before you automate anything.

    Run and inspect jobsbash
    curl -sX POST "$NOPSAI_URL/v1/system/data/cleanup/run" -H "Authorization: Bearer $NOPSAI_TOKEN" --data @cleanup.json | jq
curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/system/data/cleanup/jobs" | jq
    Verify
    • The job appears with what it removed.
  3. 03

    Schedule it

    A cleanup schedule can be enabled, disabled, and run on demand, so retention becomes a setting rather than a chore.

    Create and trigger a schedulebash
    curl -sX POST "$NOPSAI_URL/v1/system/data/cleanup/schedules" -H "Authorization: Bearer $NOPSAI_TOKEN" --data @schedule.json | jq -r .id
curl -sX POST -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/system/data/cleanup/schedules/$SCHEDULE_ID/run" | jq
    Verify
    • The schedule is listed as enabled and its manual run produces a job.
  4. 04

    Back up what cleanup will not restore

    Retention is not a backup strategy. The database holds every run record, credential, and setting; a cleanup that ran on the wrong window is only recoverable from a backup.

How it works

Always preview a cleanup before running it in an environment with real history. The preview reports what would be removed under the current retention rules.

Because there is no product-managed upload to object storage, exporting backups off the host is a deployment responsibility.

Limits

Current behavior
  • A complete product-managed restore workflow is not implemented. Plan recovery around your own PostgreSQL restore procedure.
  • There is no product-managed backup upload to object storage.

Implementation evidence

  • services/nopsai/data_management_gitops.go

    Cleanup schedule schema and GitOps ownership.