Backing up an Event Store database is straightforward, however it is reliant on carrying out the steps below in the correct order.
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.
Most data is stored 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 of 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.
This option can be expanded upon 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 the case of disaster on the primary cluster. If you are using this strategy then it is recommended to only support manual failover from Primary to Secondary as automated strategies risk causing a split brain problem.