Backing up an Event Store database is straightforward, but relies on you carrying out the steps below in the correct order.
Backing up a database
- Copy all *.chk files to the backup location.
- Copy the remaining files and directories to the backup location.
rsync -a /data/eventstore/db/*.chk /backup/eventstore/db/ rsync -a /data/eventstore/db/index /backup/eventstore/db/ rsync -a /data/eventstore/db/*.0* /backup/eventstore/db/
Restoring a database
- Create a copy of chaser.chk and call it truncate.chk.
- Copy all files to the desired location.
Many people do not rely on hot backups in a highly available cluster but instead increase their node counts to keep further copies of data.
Eventstore stores most data in chunk files, named
chunkX.Y, where X is the chunk number, and Y is the version of that chunk file. As Event Store scavenges, it creates new versions of scavenged chunks which are interchangeable with older versions (but for the removed data).
Consequently, it is only necessary to keep the file whose name has the highest
Y for each
X, as well as the checkpoint files and the index directory (to avoid expensive index rebuilding).
There are many other options available for backing up an Event Store database. For example it is possible to set up a durable subscription that would write all the events to another storage mechanism such as a key/value or column store. These methods would require a manual set up for restoring back to a cluster group.
You can expand upon this option to use a second Event Store node/cluster as a back up. This is commonly known as a primary/secondary back up scheme. The primary cluster runs and asynchronously pushes data to a second cluster as described above. The second cluster/node is available in case of disaster on the primary cluster. If you are using this strategy then we recommend you only support manual failover from Primary to Secondary as automated strategies risk causing a split brain problem.