Dolt is a database and a version control system all wrapped up in one. It's a database that you can fork, clone, push, pull, branch and merge. It's a database that you can commit and rollback. It's a database that you can share with others and collaborate.

By necessity of all of these features, moving the data around to multiple copies is required. Just by virtue of using it, you are creating backups.

Dolt supports a specific feature to backup, nevertheless. The dolt backup command and the dolt_backup() stored procedures exist to enable users to create a pristine copy of their database. They also enable users to restore from a backup, should the need arise.

Aren't Backups Just Remotes?

Yes! Or maybe No? Honestly I had the same questions recently when I started playing with the feature. We've talked about this before, but it's worth repeating. First and foremost, backups are a snapshot of the data at a specific point in time. This includes the data which exists in an uncommitted state on each branch. (refresher that Dolt has two kinds of commits, we are talking about history commits here). Remotes only allow you to push and pull history committed data. Restoring from a backups gets you back to the state of the database at the time the backup was created. That includes all branches and all uncommitted data. It's like time travel. Restoring from remotes doesn't get you that.

Also, backups of databases are a table stakes feature which is necessary for a variety of compliance and regulatory reasons. It's a feature that is expected by users of databases, without needing to know the nuances of how Dolt works. It's fun to think of a parallel history where version control and databases were always a thing and we didn't need backups as they are defined in laws and regulations. But that's not the world we live in, so we have backups.

How Do I Backup?

The dolt_backup() stored procedure is the easiest way manage backups. If you want to create a backup to a copy on the files system of the database, you can run the following SQL command:

mydb/main> call dolt_backup('add', 'mybackup', 'file:///path/to/backup');

If you want to see the backups you have configured, there is a system table called dolt_backups. You can query it like this:

mydb/main> select * from dolt_backups;
+------------+------------------------+
| name       | url                    |
+------------+---------- -------------+
| mybackup   | file:///path/to/backup |
+------------+------------------------+

Right now you only have the target location of the backup configured. This is kind of like having a remote configured that you have not pushed to. To actually perform a backup you sync your current state to the backup state. In this case, your backup is empty so the sync sends the entire copy of your database to the configured backup location. Subsequent syncs only send the new data that needs to be backed up.

call dolt_backup('mybackup', 'sync');

Restoring from a Backup

Restoring from a backup is just as easy. One caveat is that backup restorations are always into a new database. To restore into an existing database would be destructive.

mydb/main> call dolt_backup('restore', 'file:///path/to/backup', 'mynewdb');

Then you can use that database as you would any other database:

mydb/main> use mynewdb;
Database changed
mynewdb/main>

The state of mynewdb is exactly the same as the state of the database at the time the backup was synced.

Conclusion

For day to day use, branches are the best way to jump between the states of your data. But backups have a place where data preservation at multiple levels is required. Backups can take advantage of cloud as well, similar to remotes. It's actually very similar to remotes in how you configure them. Just replace the dolt_remote operations with dolt_backup operations, and you'll be good to go.

We're always happy to talk with users who are solving real problems with Dolt. Come tell us on Discord!