Hosted Dolt launched in May of this year. At launch, the product was very basic. You could go to https://hosted.doltdb.com and get a dolt sql server instance stood up in AWS in us-west-2. You would have access to logs, and metrics for your instance via the hosted dolt web ui. Shortly after launch we rolled out incident management and added support for us-east-1. Last week we launched automated a SQL Workbench for hosted, and this week we are announcing the release of automated backups.

Hosted DoltDB Backups

My colleague Aaron Son once said that you aren't a real database unless you have backups. Computer hardware tends to be pretty reliable, but given enough time, and enough usage, problems will occur. Hosted Dolt runs on AWS, and while EBS volumes are very reliable any serious application needs protection from data loss.

Dolt launched support for backups almost a year ago. Since then Dolt users have been able to set up and manage their own resources for storing Dolt database backups. They could set up a cron or some other machinery to trigger backups of all their databases. Hosted Dolt removes the overhead of creating and managing both the cloud resources for backups and the machinery needed to trigger them.

Why Does my Version Controlled DB need to be Backed up?

As a version controlled database, Dolt can handle many of the situations where a backup would be needed by other databases. If you drop a table, or write a bad delete statement you can revert to the previous commit. That said, there are still cases where a backup is needed.

1. Dropping a Database - Dolt manages its version control history on a database level. Commits to each database are stored independently. When you drop a database all the chunks and the history of the database get deleted. In order to recover from accidentally dropping a database you'll need to go to the backup. The backup will contain the entire history for a database and allow you to recover from this type of user error.
2. Hardware Issues - When an EBS volume goes down and is irrecoverable, the version control history is lost. However, it can all be recovered from a backup.
3. Data Corruption - If for any reason a dolt database becomes corrupt, this is another time when going to the backup is likely going to be the best way to get your database up and running again.
4. Destroying Your History - The Dolt command filter-branch allows you to alter your commit history. If you made a mistake in your filter-branch call you could alter your commit history in problematic ways that can't be reverted. In this case you will need to restore from a backup.

What Exactly goes into a Hosted Backup

When a backup is taken, each database on the hosted Dolt instance is copied in its entirety. In the future we may support incremental backups, but as of today we take a full copy of the databases nightly. In addition to the databases themselves, a copy of the privileges file and the server config file are also made.

Backups on hosted.doltdb.com and What's Next

Within your deployment there is a new tab for backups. Here you will see a list of all the backups that have been taken. Each backup has an ID and lists the databases that were backed up, the size of the backed up files, and when it was created.

Currently, restoring from a backup requires you to create a support ticket. Once the ticket is created we handle restoring from the backup manually. In the near future you will be able to restore from a backup, or create a new hosted deployment from an existing backup.

We have a long and exciting roadmap for hosted Dolt. The database itself, and the hosted offering are getting better all the time, and now is the perfect time to try it. Come talk to us on Discord, or create a hosted Dolt deployment today.