All eligible persistent volumes
Schedule backups for supported container binds and volumes while platform metadata is protected separately in the cloud backplane.
Protect persistent container data with encrypted Restic repositories, use application-aware tooling for PostgreSQL and MySQL, review backup events, and initiate supported restores through the portal.
Capabilities
Schedule backups for supported container binds and volumes while platform metadata is protected separately in the cloud backplane.
PostgreSQL uses pgBackRest and WAL archiving. MySQL uses XtraBackup/xbcloud-compatible tooling for consistent database backups.
Configure schedules on the component or initiate a manual backup from the resource view when a specific recovery point is required.
For file-based workloads, optionally stop the container briefly during backup to reduce inconsistency while files are being mutated.
Backup objects are stored in encrypted S3 buckets, while tools such as Restic add repository-level encryption.
Each compute location has a nominated S3 backup region, usually in the same city; Amsterdam workloads use Frankfurt storage.
How it works
Select schedule, retention, and whether the workload should pause for a consistent file snapshot.
Review successful and failed events and the snapshots available for the component.
Choose an available snapshot or supported database recovery point and initiate restoration.
Periodic backups can lose changes made after the latest successful snapshot. PostgreSQL PITR can reduce this window, subject to available WAL data.
Seemi uses live-migration-capable infrastructure, RAID-configured storage, and off-node backups, but critical customers should maintain additional customer-controlled backups and test restoration regularly.
Ready to move forward?