I restored a cluster inside another Atlas project from an automated Cloud Provider snapshot.
I noticed on the backup history page [1] that most of the time was spent during “Transferring Snapshot - X%” stage. Why is this the case?
Technically, the underlying AWS EBS volume should be restored from an EBS snapshot.
Why do we have to wait for snapshot transfer in this case?
Are we doing something wrong by restoring to a cluster in another project?
Hi @MartinLoeper,
If you want us to review the cloud progress of your specific project please post the link with all the details as the current link has masked fields.
During a restore of the EBS volume we still need to build this new volume from the image as well as if the restore is done from a different region we have to move it to the region.
Please see the following recommendations for optimal restores:
Best regards,
Pavel
Hi @Pavel_Duchovny,
thanks for the information!
It is stated inside the docs that for optimal restore performance, the target cluster should exist "in the same Atlas project as the source cluster. ".
This is not the case in our current setup.
Does it mean that restore is taking much more time as the snapshot must be transferred from one Atlas project to another?
Is it best practice to put production and staging cluster into the same Atlas project?
Thanks,
Martin
Hi @MartinLoeper,
Having clusters across different projects have many consideration like your atlas user teams and permission saggregation, your DevOps ways of deploying and maintenance of your cluster.
Additionally there is database security features, although users and roles can now be bound to a cluster level, peering and other advance options might not.
If your only consideration is backup and its restore times it make sense to keep the clusters in one project having the same disk and instance size during restores as it can use the fastest available disk cloning methods.
Best
Pavel
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.