Service Backups

Per-service backups (Pro and Enterprise) snapshot a service's managed volume into an encrypted restic repository on any S3-compatible destination. Each service owns its repository, so a restore is exactly one service's data.

How it works#

• Every backup job runs against the service's storage directory through restic, encrypted before it leaves the node.
• The repository lives under your S3 destination at s3:<endpoint>/<bucket>/zensailor/services/<service-id>.
• Schedules are daily, weekly and/or monthly, with retention applied after each successful run — delete rules run only on success, so a failed backup never destroys older snapshots.
• Database services are stopped during the backup so the snapshot is consistent, then started again — the deploy window never delays a backup.
• Restore keeps the current data as rollback material: the existing volume is preserved, the snapshot is written beside it, and you confirm the cutover.

From the dashboard#

Open the service → Backups tab. Configure the destination, choose the schedule and retention, then watch runs complete with snapshot sizes. The restore flow asks for the snapshot, shows what will be replaced, and records the restore in the service's history.

From the CLI#

# Show configuration and snapshots
zensailor service backup show <service-id>

# Configure schedule/retention
zensailor service backup configure <service-id> --daily --retention 14

# Test the destination
zensailor service backup test <service-id>

# Run now / restore / delete
zensailor service backup run <service-id>
zensailor service backup restore <service-id> <snapshot-id>
zensailor service backup delete <service-id> <snapshot-id>

Volume migration reuses the same repository#

When you migrate a volume to another node, the data travels through the backup repository: snapshot → verify → repoint the storage pin → move. The original copy is kept, never deleted. See Storage Across Nodes.