Our backup restoration functionality is currently tied to the "Fork database" feature. Navigate to the service's "Overview" page and you will see a "New database fork" button in the top-right corner. This will allow you to make a separate new database service that is cloned from the current one's backups.

Any point of time starting from the first backup listed in the backups tab can be entered as the restore target for the new service. Once this new service is running, you can change your application's connection settings to point to it.

Manual restoration is something that you should only need to do when you have accidentally destroyed data from your application or by your DB administrator. We handle outages and software failures automatically by replacing broken nodes with new ones that resume right from the point of failure.

Note that forked services can also be very useful for example for testing purposes, allowing you to easily create a completely realistic separate copy of the actual production database with its data.

The reason why we have not allowed a service to be rolled back to backup within itself, at least yet, is that it creates alternative timelines for the database and these add complexity for the user. So for now, each database service has a single linear history timeline.

Did this answer your question?