When using a JDBC/JPA event store, you can indeed leverage any backups that your database of choice offers. Just be careful here what and how you want to back up, since aside from the event store, there are multiple other tables that may be of importance here:
- domainevententry - This is your event store, so you’re always going to want to back up this table
-
tokenentry - This table stores your tracking tokens. Whether or not you want to back this up, depends on how you’re handling your projections (or sagas). This table should be stored along with your projections. It is usually preferable to trigger a real replay, based on your existing tokens, than to have Axon recreate missing tokens from an empty tokenentry table. In the latter case, the framework won’t know you are actually doing a replay and as such will treat all events as if they are new, ignoring any
@DisallowReplayannotations, among other things. - sagaentry - This stores your serialized sagas. Typically you don’t want to replay sagas since they have side-effects or cause changes in the system, in which cases you’ll want to back up this table as well. If so, make sure you also back up your tracking tokens for your saga.
- associationvalueentry - Same as above. This table contains the associations values that link events to specific saga instances.
For your demo data, you might be fine by just backing up your eventstore, depending on what kind of data you have in there and what your application does with it. For production backups however, you’ll probably want to ga a bit further here and back up all other tables as well.
If you are using Axon Server, you do have some additional options available though, in the form of backup nodes and taking file system backups. See https://docs.axoniq.io/reference-guide/axon-server/administration/replication-groups#node-roles and Backups - Axon Reference Guide for more information on those solutions.