Clusterward backs up what makes your applications tick and brings it back in a few clicks: database backups with download and restore into a new database, snapshots of your volumes, every earlier version of a deployment, and your entire workspace configuration as a file.
Kubernetes backup in Clusterward covers four layers: databases via Scaleway Managed Database backups, persistent volumes via Block Storage snapshots, deployments via the exact image version of every rollout, and the workspace configuration as an export. Restores happen alongside what is running, or with a safety copy taken first – never blindly on top of it.
Snapshots run on schedule, and you can start a backup of a database yourself at any time.
Backups, snapshots and earlier deployments are listed in the cockpit with their timestamps.
A database is created fresh alongside the old one; a volume gets a safety snapshot first.
You point the application at the restored data and restart – whenever you choose.
Every layer has its own way back – in the cockpit, without scripts and without a console.
Scaleway Managed Database backups in the cockpit: when the last snapshot ran, how often snapshots run and how long they are retained – adjustable on the instance page.
One click backs up a single database, retained for 7, 30 or 90 days. For download, it is prepared as a compressed SQL file.
A backup is restored into a new database with its own user and password. The running database stays untouched until you switch over.
Scheduled snapshots with retention, a snapshot before every deletion, and restores with a safety snapshot taken first. This also applies to the disks a Helm chart brings along itself.
“Restore this version…” in the deploy history rolls out exactly the image of an earlier healthy version – for Helm, the chart version and values.
Every rollout records the image the tag points to at that moment. New builds also get a fixed sha tag in the registry.
Before a customer is torn down, a verified database dump and bucket archive are already in your backup bucket.
The entire configuration as a single JSON file: applications, infrastructure, pipelines, users, audit log. Passwords and keys are never included.
Restores require the name to be typed as confirmation and never run automatically. Every action is recorded in the audit log.
Snapshots and backups are created in Scaleway itself and are also visible in the console.
Persistent volumes are backed up as Scaleway Block Storage snapshots.
A rollout’s image is uniquely identified by its sha256 digest, no matter where the tag points later.
Dumps as pg_dump or SQL, archives as ZIP, exports as JSON – readable without Clusterward.
Every layer has its own backup and its own way back.
| Layer | Backed up as | Way back |
|---|---|---|
| Database | Scaleway snapshot and per-database backup | New database alongside the running one |
| Volume | Block Storage snapshot, including disks from Helm charts | Restore with a safety snapshot |
| Deployment | Image digest of every rollout | Roll out an earlier version again |
| Customer in offboarding | Dump and ZIP archive in the backup bucket | Download, restore with standard tools |
| Workspace configuration | JSON export | File for your records or a migration |
| Cluster add-on | Previous chart version on the add-on | Upgrade back to the previous version |
Database backups are part of Managed databases – that is also where you’ll find instances, additional users and imports from existing databases.
How volume snapshots and restores work in detail is covered under Volumes & snapshots; rolling back to an earlier version under Deployments.
What gets backed up when a customer leaves is described under Tenant pipelines.
Whether a crash is really over after a restore is shown by the logs of all instances under Logs & monitoring; what Helm charts do with their disks is covered in the post Helm charts and their disks.
Postgres and MySQL connected privately, one database per service.
Go to Managed databasesPersistent data with a snapshot before every deletion.
Go to Volumes & snapshotsGit, container image or Helm chart – rolled out with a health check.
Go to DeploymentsWe back up a database, restore it alongside the running one and roll out an earlier version of your application.
