bit Boilerplate has no backup or restore for the server its CD deploys

Start with the R&D notes and verify the listed tool capabilities against their sources, then resolve the open choices for supported database options and restore testing. Trace how the app host adds publish-mode containers and how the deploy skill configures deployment; done means a design that covers the stated backup, restore, retention, and restore-test requirements.

The deploy skill and the CD that came with #14382 put a project's server on the team's own Linux VM, as a Docker Compose project that .NET Aspire publishes from the app host. Nothing backs that server up yet, and nothing restores it.

We'll build our own backup and restore tool for this. It may use some of the existing tools below inside, but it's ours, and the template sets it up with the rest of the deployment.

What it has to do

• Back up what a deployed project keeps on its server:
  • its database: PostgreSQL, SQL Server, MySQL or SQLite, depending on the project's options;
  • redis-persistent, which holds Hangfire's jobs and the distributed lock (redis-cache needs no backup);
  • the uploaded files, when they stay in the api's local volume, and a copy of them when they live on S3-compatible storage;
  • the small volumes: the Aspire dashboard's telemetry and DbGate's settings.
• Write the backups, encrypted, to the project's own S3-compatible storage (the template recommends Cloudflare R2), on a schedule and with retention.
• Restore to the latest backup, and to a point in time where the engine allows it.
• Test its restores by itself, regularly, and fail loudly when one doesn't work.
• Stay free, and work on a server that has no inbound port: the runner pulls its jobs and cloudflared dials out.
• Fit the template: the app host adds it in publish mode, and the deploy skill sets it up with the rest.

R&D (2026-10-30)

Release dates were read from the GitHub API on 2026-10-30. Everything listed is free unless marked paid. These notes are input for the design, so check each claim against its source before relying on it.

Database-native tools

Volume and file tools

None of these has point-in-time restore; a restore goes back to a snapshot.

Notes

• Consistency. A plain VM has no filesystem snapshots, so a file-level tool that reads a live database volume gets a copy that isn't even crash-consistent. Dump first, stop the container, or use a database-native tool.
• WAL-G
  • backup-push can stream over the replication protocol (docs), so a sidecar needs no access to PGDATA. That mode has no delta backups and uses a single stream.
  • WAL archiving needs wal-push inside the database image. The alternative is wal-receive in a sidecar, which holds a replication slot.
  • wal-g#2550 reports that the official postgres:18 image (and so pgvector/pgvector:pg18) has no CA certificates, and that WAL-G then retries the TLS error to R2 without logging it, which looks like a hang.
• pgBackRest and barman-cloud need their binary next to PGDATA: a custom database image, with backups run through docker exec or from a sidecar that shares PGDATA.
• eeshugerman/postgres-backup-s3 has been archived since Aug 2024. The MySQL counterpart of the dump images is databacker/mysql-backup (MIT, 1.5.0).
• SQL Server
  • Backup to S3-compatible storage isn't supported in Express, the only free production edition; the container image defaults to Developer. On Linux, the S3 endpoint's CA has to be in /var/opt/mssql/security/ca-certificates before SQL Server starts.
  • The free route is a scheduled sqlcmd running BACKUP DATABASE and BACKUP LOG … TO DISK (Express has no SQL Agent), into a volume shared with whatever uploads the files, since sqlservr writes them.
  • On a paid edition, the R2 write-up above found the REGION option failing. R2 also wants equal-size multipart parts, while SQL Server's part sizes vary between 5 and 20 MB, so it needs a test at real database size.
  • WAL-G's SQL Server mode targets Windows, and its docs cover full backups only.
• MySQL 9.7. Percona XtraBackup 9.7 is still a release candidate (Jul 2026), so WAL-G would use mysqldump and binlog-push, reading the binlogs from the data volume.
• Litestream
  • A sidecar on the same named volume is supported, on local disks (not NFS or SMB).
  • Microsoft.Data.Sqlite retries busy errors until its command timeout, and the app's own checkpoints make Litestream take extra snapshots.
  • Version 0.5 removed client-side encryption.
• Redis
  • Redis 8 has the BACKUP START/SEAL/LIST/CLEANUP commands, which take a consistent online copy of the multi-part AOF, restored with preload-file aof:…/appendonly.aof.manifest.
  • The older route: set auto-aof-rewrite-percentage 0, wait for aof_rewrite_in_progress:0, copy appendonlydir, then turn it back on.
  • A dump.rdb copied into /data is ignored while AOF is on; preload-file rdb: loads it.
  • WAL-G (redis backup-push --type aof), nfrastack and offen's stop label also work.
  • Restoring an old Hangfire state can run jobs again or drop them.
• Aspire. Neither Aspire nor CommunityToolkit/Aspire has an integration for any of these. Each would be a container the app host adds in publish mode only (AddContainer or AddDockerfile), sharing the named volumes it backs up through WithVolume(sameName, path, isReadOnly: true) and getting labels through PublishAsDockerComposeService.
• Cloudflare R2
  • The free tier covers 10 GB-month, then $0.015 per GB.
  • R2 has no S3 versioning or Object Lock. Its bucket locks also block overwrites, so they fit only prefixes a tool never rewrites.
  • Backups want a bucket of their own, with a token scoped to it.

What the research would use if we only combined existing tools

• PostgreSQL: WAL-G. A thin image FROM pgvector/pgvector:pg18 that adds wal-g and ca-certificates, with archive_command='wal-g wal-push %p' and archive_timeout=60; a cron sidecar runs backup-push nightly and delete retain FULL 7, with a libsodium key. pgBackRest for large databases.
• SQL Server Express: a nightly full backup and a log backup every 15 minutes (FULL recovery model) with sqlcmd, into a backup volume that restic pushes to R2.
• MySQL: MySQL Shell in a mysql:9.7 sidecar, dumpInstance nightly and dumpBinlogs every 15 minutes, once proven against R2; WAL-G otherwise.
• SQLite: a Litestream sidecar with snapshot.retention: 168h.
• Redis: a nightly job running BACKUP START, SEAL, the copy, then CLEANUP; offen's stop label is simpler when a few seconds of downtime are fine.
• Files: on R2, rclone sync to the backup bucket with a dated --backup-dir and a lifecycle rule; in a local volume, restic.
• Small volumes (dashboard, DbGate): offen nightly, with stop labels, age encryption and 14 days' retention.
• Restore testing: a weekly scheduled workflow on the self-hosted runner that restores everything into throwaway containers on an isolated network, PostgreSQL to "now minus one hour", then checks it: pg_amcheck and the latest __EFMigrationsHistory row, DBCC CHECKDB, PRAGMA integrity_check, Redis DBSIZE, and restic check --read-data-subset=10%. A failed run is the alert. GitHub turns scheduled workflows off after 60 days without activity in a public repository.

Still open

• Whether MySQL Shell and SQL Server's native backup work against R2 at real database sizes.
• Whether wal-receive uploads partial WAL segments.
• How Kopia schedules snapshots without its server running.