# How are people handling disaster recovery? **URL:** \ **Category:** Datomic Cloud\ **Created:** [October 14, 2021, 1:56pm UTC](https://forum.datomic.com/t/how-are-people-handling-disaster-recovery/1984 "2021-10-14T13:56:31Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![DanM](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/danm/32/486_2.png) [@DanM](https://forum.datomic.com/u/DanM)\ **Post date:** [October 14, 2021, 1:56pm UTC](https://forum.datomic.com/t/how-are-people-handling-disaster-recovery/1984/1 "2021-10-14T13:56:31Z")
I was looking at ways to back up Datomic Cloud, and found [Cloud backups & recovery - #13 by lukenelson](https://forum.datomic.com/t/cloud-backups-recovery/370/13), which is various people asking for it and the reponse being “It uses S3 and DynamoDB, both of which have very high data durability SLAs, so backups aren’t really necessary/supported yet”. This doesn’t paint a complete picture, IMO. Many of the folks in that thread are asking about backups so that they can do a local restore and examine the data. I am thinking more about an accidental or, worse, malicious deletion of our data by a hacker or disgruntled (soon-to-be-ex) employee. Sure, if they _do_ something like that we can pursue them legally for it, but an individual is highly unlikely to have the funds to cover the costs of our damages, and them potentially serving prison time would not help all the other employees now out of a job because the company has folded. I want to be able to ship the data off to a completely separate AWS account which is more heavily secured (no developer access outside of a restore, no access keys, physical MFA tokens required etc), so that if someone deletes objects from the S3 buckets or rows from the DynamoDB tables we can use the contents of that backup account to restore that data to at least within a day. How would people go about achieving that? ---
**Author:** ![tomc](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/tomc/32/221_2.png) [@tomc](https://forum.datomic.com/u/tomc)\ **Post date:** [October 15, 2021, 1:54pm UTC](https://forum.datomic.com/t/how-are-people-handling-disaster-recovery/1984/2 "2021-10-15T13:54:08Z")
S3 has built-in support for replicating to a different account, see [Replicating objects - Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html). It seems unnecessary, but you might also want to backup the DynamoDB table. You can do that too by [exporting the table to S3](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html) and using S3’s replication for that data as well. You might also consider a daily/weekly job to pull the S3 bucket onto a local hard drive. ---
**Author:** ![DanM](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/danm/32/486_2.png) [@DanM](https://forum.datomic.com/u/DanM)\ **Post date:** [October 15, 2021, 2:12pm UTC](https://forum.datomic.com/t/how-are-people-handling-disaster-recovery/1984/3 "2021-10-15T14:12:32Z")
Thanks for the reply! You say > It seems unnecessary, but you might also want to backup the DynamoDB table I had assumed that I would need both S3 and DynamoDB to restore a system, and that the two would need to be in sync. Is that not the case? Is the transaction log (what dynamo stores, according to [Datomic Architecture | Datomic](https://docs.datomic.com/cloud/whatis/architecture.html)) not necessary to access the data? I assume I would also run into trouble if the KMS key were deleted. AWS seem to have recently implemented multi-region keys, I wonder if that could go some way to alleviating _that_ issue, although the Datomic CloudFormation templates would need to be modified to provision a multi-region key. ---
**Author:** ![lukenelson](https://avatars.discourse-cdn.com/v4/letter/l/ee59a6/32.png) [@lukenelson](https://forum.datomic.com/u/lukenelson)\ **Post date:** [October 20, 2025, 9:06am UTC](https://forum.datomic.com/t/how-are-people-handling-disaster-recovery/1984/4 "2025-10-20T09:06:16Z")
So much for those SLAs tonight. (I guess in relation to availability, not durability – but you kinda need both…)