Backups you can actually restore
A backup nobody has restored is a rumour. Where Cloud by Naasson makes restoring easier, and where the work stays yours.
Every system has backups. Far fewer have backups anyone has restored. The gap between the two is where data loss lives.
The working definition we use is short. A verified backup is one that has been restored at least once, not one that merely exists.
Nine databases, nine backups
Almost any Helm chart in the catalogue can bring up its own database. That is convenient for one application and becomes a problem by the tenth. Nine applications with their own databases means nine Postgres instances, nine sets of settings, and nine backup schedules, not all of which work.
So the catalogue has a shared database mode: applications connect to one instance whose name is set at install time. The main gain is one place for backups. A backup taken in one place on one schedule has a chance of being checked; nine copies in nine places are checked by nobody.
The shared mode has a price. One instance is one point of failure, and a careless application now slows down its neighbours. A separate database still makes sense where an application has special restore requirements or cannot be stopped together with the rest.
Updates need a backup first
Chart versions in the catalogue are pinned, so an application never updates itself. An update is a version change in the repository and a commit; a rollback is a reverted commit.
That rollback covers the deployment, not your data. We are responsible for a pinned version deploying the same way it did at certification. We are not responsible for a new version of an application being compatible with your data: that is a question for the application’s author and for your backups. Hence the practical rule: before updating an application that holds state, take a verified backup.
Procedures that have been run
The ready-made infrastructure is assembled and checked in one cloud, and every procedure there, including restore, update and expansion, has been run rather than declared. That is the reason for one platform instead of several: each additional cloud would multiply the checking.
If you run the Kubernetes distribution yourself instead of a managed service, you also take on work the provider would otherwise do, including backing up etcd. It is an honest trade and not always a good one.
A backup plan you can read
A cluster report includes the backup plan alongside diagnostics and the commissioning check. It is a file, not a screen: it can be attached to a task, compared with the previous one and handed to someone without cluster access.
Dangerous live actions stay blocked until there is a proven backend, a permission model, backups and a rollback procedure. A command that reports success without doing anything is worse than one that refuses.