Is there a recommended solution for backups and disaster recovery when using Datomic Cloud? For on-prem, the following documentation exists, but I couldn’t find anything for Cloud. Thanks!
All data in Datomic Cloud is stored in S3 (as well as other highly durable storages), which provides very high durability guarantees, making secondary data loss prevention (i.e. backup) unnecessary.
However, we understand that in certain circumstances it may be desirable to ‘roll back’ a database. Datomic Cloud does not yet include the ability to ‘revert’ a database to a prior state.
We are considering options for this use case and encourage you to vote for or comment on this feature in our feature suggestion portal (accessible through my.datomic.com or by requesting an account from firstname.lastname@example.org).
I’m unable to access case 54485, even though I’m logged in to Receptive and can access other Datomic cases: “Sorry, but that request doesn’t seem to exist”.
I understand the reasoning against backups w.r.t. durability in storage, but I would still like the option of taking the data ‘off-site’ or snapshot/clone it to a separate restricted AWS account in another region (e.g. to protect both me and my org from me accidentally deleting everything with a couple of clicks or API calls) or ‘migrate’ to/from cloud, as well as the ‘revert’ case. Maybe also to copy from prod to test. Does it make sense that every larger Datomic Cloud customer have to make their own data exporter to satisfy auditors?
Very strange. Can you search for it in Receptive? The title of the feature request is “Reversion”? Just curious if you see it in the search but can’t access the feature.
I am adding a link to this forum post and a quote of your points to the discussion under the feature request.
When I search for “Reversion”, I only see “iterate indexes in reverse”, case 17927.
Easy incremental backup was my primary reason for sleeping well while using on-premise Datomic. This is an absolutely vital feature - please let us decide if AWS or operational code is safe enough.
Moreover, 99.99999% durability has nothing to do with risk management. Proper risk management is “what if”. Kolmogorov zero-one law (for operational purposes): something will either happen or not happen, with nothing in between. Even worse, AWS has a documented history of exploding tail events.
I am interested in backup/restore as well but for a different reason – I’d like to be able to restore a production DB locally to experiment on it.