Encryption, access control, and resilient architecture are all preventative measures that serve as the pillars of a good data resilience strategy. But what if disaster strikes even with these measures in place? For example, imagine a developer on your team accidentally deletes critical data with an incorrect query or your system is infected by ransomware. That's why remediation is essential to your data resilience strategy. No matter how strong your preventative measures are, you need a reliable way to backup and restore your data quickly when the unexpected happens. In this video, we'll discuss some of the key objectives that you need to define when developing your strategy for remediation. Then we'll explore how MongoDB Atlas' backup features help you recover. When preparing a disaster recovery strategy, businesses typically start with two critical metrics, your recovery point objective, or RPO, and your recovery time objective, or RTO. Your RPO answers the question, how much data can we afford to lose? It defines the maximum acceptable amount of data loss measured in time, whether that's seconds, minutes, hours, or even days. Your RTO answers, how quickly do we need to be back up and running? It defines the maximum acceptable downtime before your business is significantly impacted. By clearly defining your RPO and RTO for each workload, you can select the right combination of MongoDB Atlas features to meet your needs. So how does MongoDB Atlas help businesses meet these objectives? The foundation is our backup system. With MongoDB Atlas, backups can include snapshots that capture the state of your cluster exactly as it existed at that moment, and point in time recovery or PIT, which allows you to restore your cluster to any specific moment within your retention window. When you create an M10 and above cluster, you gain access to Atlas Cloud Backups. This feature stores your backups in the same region as your cluster and uses your cloud provider's built in snapshot functionality to create backups. Let's look at an example of how this can work. After enabling and configuring backups according to your backup policy, Atlas prioritizes taking snapshots from secondary nodes. For clusters in a single region, snapshots are automatically encrypted at rest and stored within the same region. For multi region clusters snapshots, Atlas will also consider the region priority when taking and storing snapshots. This ensures fast, efficient backup and restoration processes. MongoDB Atlas takes these snapshots automatically in the background without any manual effort from you, ensuring you always have recent recovery points available if something goes wrong. You can enable and customize snapshots in the backup policy settings section of your cluster management UI. This ensures that your backup strategy is tailored to your workload and compliance requirements. For example, you might wanna configure your snapshot schedule to align with your application's activity patterns. If your business primarily operates in one geographic region, you may choose to take snapshots late at night or early in the morning in that geography to minimize performance impact on your production database. You can also customize the frequency and retention period to ensure snapshots are stored for as long or as short as needed. If your company is required to comply with regulations such as GDPR or financial auditing laws, you may increase monthly snapshot retention to several years for archiving historical data. Additionally, Atlas Online Archive offers an efficient way to manage the data life cycle by archiving older or infrequently accessed data to a lower cost storage tier while keeping it queryable when necessary. When you use Online Archive, it helps optimize performance for active workloads while maintaining compliance and reducing costs associated with storing less frequently accessed data. If you require more granular recovery options, you can enable continuous cloud backups, which provides point in time or PIT recovery. This works by continuously capturing the oplog, which records every data change made to your database in real time. This allows you to restore your database to a specific minute rather than being limited to scheduled snapshot intervals. In other words, instead of losing hours of work by restoring to your last snapshot, you can pinpoint the exact moment before the problem occurred, say 02:46, and restore to that precise point, preserving all legitimate changes while eliminating only the problematic ones. It's important to know that continuous cloud backup requires additional storage and compute resources to capture the oplog data in real time. It's best for cases that require high precision and recovery, like businesses that must comply with certain regulatory standards. MongoDB Atlas also provides multiple region snapshot distribution when additional resilience is required. By distributing backup snapshots and oplogs across geographic regions instead of just storing them in your primary region, you protect against catastrophic regional failures, meet compliance requirements, and enable faster restores. You can configure which regions store your backup copies when setting up your cluster or under backup policy settings, like in this example, allowing you to balance recovery speed, cost, and compliance requirements based on your organization specific needs. Beyond geographic distribution, you can also protect all of your backups from tampering or accidental deletion with MongoDB Atlas's backup compliance policy. This feature enables organizations to further secure business critical data by preventing all snapshots and oplogs stored in Atlas from being modified or deleted by any user regardless of their Atlas role for a predefined retention period. This means even administrators with full access can't accidentally or maliciously remove your backups during the compliance window. This protection guarantees that your backups are fully WORM compliant. Write once, read many, a requirement for many regulatory frameworks. Only a designated authorized point of contact can disable this protection after completing a verification process with MongoDB support, adding an extra layer of accountability. You can enable this feature directly in the Atlas UI when configuring your backup settings for a project. Once enabled, you'll define your retention period, specifying how long backups must be protected before they can be deleted, And designate authorized points of contact who can request changes to the policy. Due to the immutability rules, disabling backup compliance policy requires support from MongoDB. This deliberate friction is by design as it protects your organization from both internal and external threats. With these features working together, MongoDB Atlas gives you the tools to recover quickly and precisely from any disaster, ensuring your organization stays resilient and your data stays protected. To plan your complete backup and recovery strategy, carefully review the MongoDB documentation or engage with professional services. For hands on guidance on restoring from backups, check out our cluster reliability skill. Let's recap what we covered in this video. Backup and recovery are essential components of any data resilience strategy, providing your last line of defense when disaster strikes. MongoDB Atlas offers automated snapshot backups that run continuously in the background, capturing your database at regular intervals without manual intervention. For more granular recovery needs, continuous cloud backup with point in time recovery lets you restore your database to any specific moment, minimizing data loss. Multi region snapshot distribution protects against catastrophic regional failures by storing backup copies across multiple geographic locations, ensuring our backups remain accessible even if an entire region goes offline. Finally, the backup compliance policy provides immutable, WORM compliant protection, ensuring your backups can't be tampered with or deleted during critical retention periods.