Backups

Cloud backs up two things: databases, as dumps, and application volumes, as archives. Backups run from schedules, go to Cloud's platform backup storage, and are listed with their outcome on the Storage page, on the Backups tab, and on each service's own Storage section. The final backups of services archived for billing have a tab of their own, as Archived services describes. Schedules and backups belong to the organization their service is in, and Storage lists the ones of the organization the console is in.

Every backup goes to Platform backup storage, a destination Cloud manages for you. It is set up the first time you choose an Automatic backup other than No automatic backup, when creating a database or a catalogue application or when attaching a volume, and every later schedule of yours uses it. The destination is yours rather than an organization's, so it serves all your organizations, and the Backups tab says so: "Backup destinations are yours, and serve all your organizations. The schedules and backups here are this organization's."

Destinations are managed by Cloud, and the console has no control to add one. Until you have one, the Backups tab reads "No backup destination is configured." and offers no way to add a schedule. Creating a database other than Redis, or attaching a volume, with an automatic backup sets it up.

When the platform itself has no backup storage configured, every form with an Automatic backup field shows "Automatic backups unavailable" instead, and nothing can be backed up from the console.

When you create a PostgreSQL, MySQL, MariaDB or MongoDB database, create a catalogue application, or attach a volume to an application, the form offers Automatic backup: Daily, Weekly, Monthly or No automatic backup. Daily is the default, and the Order summary lists backups as Included.

The choice creates a schedule. Its first run comes one interval after the service or the volume is created, so a new database has no backup for its first day. Press Back up now once it is running to have one at once.

Each schedule is a card titled "Backup for" the project and service, with an Enabled or Paused chip and these rows:

The four icon buttons under it, from left to right:

• Back up now runs the schedule outside its timer. It does not move the next run. It also works on a paused schedule. The console answers "Backup queued. Its status will update after verification."

• Pause schedule stops the timer without removing the schedule, and Enable schedule starts it again, with the next run one interval from that moment.

• Change schedule sets How often to Daily, Weekly or Monthly. Cloud sets the next run one interval after the moment you save.

• The last button archives the schedule. Its confirmation says that automatic backups for the service "will stop. Existing backups and their history are kept." Confirm with Archive schedule. A schedule that never ran is removed outright, since it has no history to keep.

Cloud checks for due schedules every minute. A run that comes due while the service is deploying, or while another backup of it is running, waits and starts once the service is free. A service runs one backup at a time.

Add backup schedule is the last tile of the schedule cards, or a button under "No backup schedules yet." It appears only once you have a destination.

1. Choose the Service. Databases other than Redis are listed, and applications with a confirmed volume. Suspended services are not.

2. Give a Schedule name, 1 to 60 characters.

3. Destination is Platform backup storage.

4. For a database, give the Database name: "The database to dump. This is independent of its disk volume." For an application, choose the Volume.

5. Choose How often, and whether Automatic backups start Enabled or Paused.

6. Press Save schedule. The console answers "Backup schedule saved."

A schedule's database or volume cannot be changed afterwards. To dump another database, archive the schedule and add a new one.

Backup history lists every backup, newest first, with Requested, Service, Type (Database dump or Volume archive), Status and Actions. The page checks again every 15 seconds while a backup is in progress.

Under the status, a line reads "Artifact:" and the stored file's state, such as retained, and the size in MB once it is known. A backup is Completed only after Cloud has found the one file it expected; a timeout never makes Cloud run a backup again by itself.

While a backup is Needs reconciliation, the service takes no other backup and does not deploy: both are refused with "This service has unfinished backup work." The sentences you may read under that status include:

• "The backup outcome is not yet known. Cloud will check it again."

• "The backup finished, but its stored object has not been verified."

• "The engine has not identified exactly one execution for this backup."

• "Backup configuration changed. Check the service before starting another backup."

A failed backup reads "The engine reported that this backup failed." Choose Backup completed and Backup failed on a channel under Notifications to hear about either without watching the page.

A Completed database dump whose file is retained has a Download button. The file is a gzip file named after the service and the time of the dump: .sql.gz for PostgreSQL, MySQL and MariaDB, .bson.gz for MongoDB. Cloud checks the stored file is exactly the one it recorded before sending it, and refuses with "The exact backup file could not be verified." when it is not.

What is inside the gzip file is the database's own dump format. Back up a database and restore it shows how to check it before you rely on it.

In Backup history, volume archives have no Download button. The final backups of an archived service download from the Archived tab, volume archives included (Archived services), and the API downloads any retained volume archive as a tar file (Download a backup).

Every backup on platform backup storage is kept. Cloud does not prune them, and they stay in Backup history after their schedule is archived or their service is deleted. The one exception is the final backups of a service archived for billing, which Cloud deletes 30 days after archiving, on the date the Archived tab gives.

When a stop for billing lasts, Cloud archives the organization's paid services: it takes a final backup of each one's data, then deletes the service (Archived for billing). While the organization has an archived service, Storage shows an Archived tab beside Backups, and the email at archiving links to it.

Each archived service has a card with its name, what it was and its project, Archived, when Cloud archived it, and Backups kept until, the date Cloud deletes its final backups. Under them, each final backup has Download once Cloud has verified its stored file, usually within the hour, and reads "Downloadable once Cloud has verified it" until then: a database dump as a gzip file, as Download a database dump describes, and a volume archive as a tar file named after the service. A service still being archived lists the final backups finished so far.

An application with no volume, a Redis database, a compose stack and a service that never ran have nothing Cloud backs up, so their cards list no backup. Once the date passes, Cloud deletes the final backups, and the card shows when, with nothing left to download. Nothing on the tab restores a service: create it again and load its data from the backups you downloaded, and support can help you rebuild it.

A PostgreSQL, MySQL, MariaDB or MongoDB database can take a dump before each of its own deployments. On the database's Storage section, under Backup before deployment:

1. Set Before deployment to Back up this database.

2. Choose the Database backup schedule to use. It "Uses this schedule's database and destination, even if its timer is paused." With no dump schedule for the database, the section says "Add a database backup schedule to enable this."

3. Press Save deployment backup.

The deployment waits until the dump is stored. If the dump fails, the deployment continues with "The pre-deploy database backup failed. This deployment continued without a verified backup." If its outcome is unknown, the deployment waits: "The pre-deploy backup outcome is unconfirmed. Deployment is waiting until the dump is accounted for." A schedule used here cannot be archived until Before deployment is set back to Disabled.

To recover a database today, download its dump and load it into a database with that engine's own tools, from a machine that reaches it through public access. Back up a database and restore it walks through it. A volume archive cannot be recovered from the console today.

A suspended account takes no backups, in any of its organizations, and Back up now is refused with "This account is suspended by Cahaves. Contact support to have the suspension lifted." A schedule that came due during the suspension runs once the account is active again. Billing explains suspension.