Backups and restore

Every database 1ClickOps runs on your server is backed up once a day without you doing anything. Here is where those backups live, what they do not protect you from, and how to go back to one.

When backups are taken

Once a day. Any database on your server that has had no successful backup in the last 24 hours gets one. A backup that failed is tried again; it is not skipped.
Whenever you press Back up now on the database’s Backups card.
Before a Push live, for each database your live app uses. See Staging and “Push live”.

The 7 newest backups of each database are kept on Free, 14 on Pro and 30 on Team. Older ones are removed.

This covers databases that run on your server. A database you only linked stays with its provider, and 1ClickOps does not back it up.

Where they are kept

Backups are files on your own server. They never come to us. We keep only a list: each backup’s name, its size, and whether it worked.

A backup on the same server as the database protects you from a mistake or a bad update. It does not protect you from losing the server itself. If the server is gone, so are these backups, and we cannot get your data back for you.

A second copy somewhere else is set up on the server's Settings page, under Off-site storage. Choose where the copies go, enter the bucket and its key, and press Save and test. The server writes one test file before it saves anything.
If whoever runs your server set up outside storage on the server itself, 1ClickOps leaves it as it is unless you choose Replace. A backup marked off-site copy has a second copy elsewhere. One marked on this server only does not.
There is no download button. Backups stay on your server by design.

How to restore

Press Back up now first. Then you can also come back to today.
On the Backups card, press Restore next to the backup you want.
The card asks “Replace current data?”. Press Yes, restore.

That question is meant literally. After a restore, the database is as it was when that backup was taken. Whatever was added since then is no longer in it.

Why it is safe to try

A restore that goes wrong does not leave you with half a database.

The backup file is read from start to finish before anything is loaded. An incomplete file is refused.
The backup is loaded into a separate, temporary database first. Your real database is swapped for it only when the whole load has succeeded.
If anything fails on the way, your database is left exactly as it was.

Loading a file or copying another database into yours goes through this same path. See Databases.

Redis is the exception. Its backups are taken like the others, but a Redis backup cannot be restored from the dashboard.