Allows to share Cloud Provider Backup Snapshot with customer's Cloud Provider account
What is the problem that needs to be solved? Add an option (as it was in mLab) that allows to share the Cloud Provider Backup Snapshot (EBS Snapshot [1], in case of AWS) for Atlas Cluster with customer's Cloud Provider account. This action is easier, quicker and cheaper for customers than manually downloading the Atlas Snapshot.
Why is it a problem? (the pain) A) Operational pain: as of now (2020-02-18), if you require to execute disaster recovery scenario with restoration of your Atlas Cluster data outside of Atlas Clusters you'll need to create a Cloud Provider Backup Snapshot Restore job (POST /groups/[GROUP-ID]/clusters/[CLUSTER-NAME]/backup/restoreJobs/ Public API call [2]), then wait until that job will be finished and then manually download Atlas Snapshot(s) via HTTPS; B) Additional cost associated with manual restoration procedure: in order to know which Backup Snapshot file is related to which Shard/CSRS you'll need to download it, untar and check mapping.
[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html
[2] https://docs.atlas.mongodb.com/reference/api/cloud-provider-snapshot-restore-jobs-create-one/
Alexey
shared this idea
We do not have plans to do this. However we have released a new feature that allows you to schedule an export of your backup. https://docs.atlas.mongodb.com/backup/cloud-backup/export/
-
Venkata RamaRao
commented
Exporting/Downloading Atlas file-system backups is very slow for large backups (even with parallelized backups at shard level). Also, Atlas cloud backups export is NOT taking advantage of private route (AWS VPC Peering links). Also, customers have a need to copy the backups to different accounts/sites (failover account, ransomware account). Overall manually copying/exporting EBS snapshots data (backed by S3 buckets) is not efficient. Finally, Atlas backup export doesn't support incremental deltas. This means all subsequent exports will also copy full snapshot blocks (not the delta changed blocks)
There are 2 options that customers are looking for.
1. Enable EBS snapshots sharing feature with customer accounts. Once enabled, customers copy snapshots to their local VPC's in the same region which is very cost efficient because EBS snapshot copy will copy incremental detlas (not the full snapshot every time). In order to take advantage of incremental delta's snapshot the exact backup encryption keys must have to be present on customer VPC's. This means customers are forced to use CMK key option.
2. Enable cross-account backup using AWS Backup Service: AWS backup service will allow to directly take a copy of snapshot to cross-account (customer account). With this feature EBS snapshots will be auto-created/copied into customer destination accounts.
https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html
https://aws.amazon.com/backup/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc
https://aws.amazon.com/blogs/storage/create-and-share-encrypted-backups-across-accounts-and-regions-using-aws-backup/ -
Ralph
commented
Hi - this in my opinion is critical. We have just had an issue on a development environment where terraform performed a drop and recreate moving from an M5 to an M10. Not only is there no final snapshot, the cluster backups are not available post upgrade.
Having a backup exported to S3 or another underlying store would at least address this issue. Not being able to recover cluster backups especially immediately after an 'upgrade' using terraform performs a delete and recreate isn't ideal.