GUI-based Backup & Restore for danbyte environments

[deku-m]

Summary

Add a native, GUI-driven backup and restore system for full danbyte environments, covering database, media/files, and configuration — with selectable scope profiles, scheduling, and remote storage targets. Removes the need for external pg_dump/shell-script workflows (a common pain point in NetBox-style tools).

Motivation

Self-hosted IPAM/DCIM tools rarely solve backup/restore inside the product itself. Admins are left stitching together cron jobs, pg_dump, and manual file archiving. This feature makes disaster recovery, migration, and staging clones a first-class GUI operation.

Scope

Backup components

Component | Contents -- | -- Database | PostgreSQL dump (schema + data) Media/files | Uploaded images, attachments, documents Config | env vars, custom fields, plugin configuration, webhook/API token references (not secrets)

Backup profiles

• Full — database + media + config
• Config only — config + schema, no data (for cloning a setup)
• Database only — data without media (fast, small snapshots)
• Custom — per-component checkboxes

Scheduling

• Cron expression or simple dropdown (daily/weekly/monthly + time)
• Each schedule bound to its own backup profile (e.g. daily "database only" → local, weekly "full" → S3)
• Retention policy: max count or max age

Remote storage targets

• Abstracted via a StorageBackend interface (Upload, Download, List, Delete)
• Initial implementations: Local disk, S3-compatible (AWS S3, MinIO, Backblaze B2)
• Future: SFTP, WebDAV

Restore flow

• List of available backups (local + remote) with timestamp, profile type, size
• Restore preview: summary of what will be overwritten (e.g. "this will overwrite X devices, Y sites, N media files")
• Restore to same instance, or download-only for manual restore elsewhere
• Explicit confirmation step (destructive action warning)

Execution model

• Async, job-queue based (not synchronous in an HTTP request) — media archiving can be slow
• Job status surfaced in GUI with step-level progress (dumping database → archiving media → uploading to remote)
• Success/failure notifications via existing Slack/Teams alerting integration

[DenDanskeMine]

would be semi easy to implement as the auto upgrade does something similar today.
I could reuse some of the functions it has to make this.
That is however only a DB backup. but it can be extended to the other profiles quite easy.

However - A normal backup solution like veeam should never be skipped.

[deku-m]

would be semi easy to implement as the auto upgrade does something similar today. I could reuse some of the functions it has to make this. That is however only a DB backup. but it can be extended to the other profiles quite easy.

However - A normal backup solution like veeam should never be skipped.
I agree but sometimes its might be easy to just have this backup and move it to a docker for example that is spin up to test.

[DenDanskeMine]

Yep - i am for sure building it! Just wanted to clarify that a "real" backup should always be mandatory/never skipped.