One of the most common scenarios for needing to go to a backup is human error. Someone releases buggy code to production. You drop a collection by accident. Some hackers breached your internal network and dumped political slogans all over your data. Or maybe you’re just worried about such a thing happening, and you want to try starting over, just in case the worst should happen.
Note: Before being able to restore, you would have to configure how to receive the backup files, either HTTPS “pull” or SCP “push” restore formats. If you’re not sure about using HTTPS vs SCP, watch this tutorial.
Now that you’ve decided what format you’d like to use, make sure that whatever machine will be downloading the snapshot has sufficient disk space. On a Linux server, this can be done by running
df -h. In Windows, this information can be found in My Computer by right-clicking on the drive in question. In OSX, you can option-click the relevant hard drive in any Finder window. Then compare it to the size in your Sharded Cluster Status or Replica Set Status page in MMS.
Once you’ve decided on the delivery method, and know you have enough disk space, you can retrieve the snapshot. If you’re running sharded clusters, you can find your snapshots in your Sharded Cluster Status page. If you’re running replica sets, you can find them in your Replica Set Status page. In either case, you then click on the replica set or shard you want to restore and you will see your snapshots. Click on the “restore this snapshot” link for the snapshot you wish to restore. The popup will give you the ability to select the delivery method, and in the case of SCP, test it.
To restore your data, you can either:
- Restore from a Stored Snapshot, which is the fastest restoration method to restore historical information. Data from the stored snapshot will be slightly older than the very latest data received by the backup service, however, depending on the cause of the data corruption this might be acceptable or even ideal.
- Restore from a point in time in the last 24 hours. If you’re sure that your corruption issue took place within the last 24 hours, you can restore from a snapshot prior to when the failure occurred. MMS will then generate a new snapshot at your request based on the your selection via the UI. If the data corruption is from before 24 hours ago, you must restore from a stored snapshot (option #1).
If only one collection or database is corrupted, you may opt to use the mongodump utility in combination with your backup snapshots to pull out the data you need. Once extracted, the data can be imported into a running mongod using mongorestore.
To have this same functionality for sharded clusters, you should configure cluster checkpoints for MongoDB by going to the Sharded Cluster node within MMS Backup and clicking the gear icon that appears next to the cluster. These checkpoints can be configured to take place every 15, 30, or 60 minutes, and you can also decide how long to store each clustershot.
How Buffer uses MongoDB to power its Growth Platform
What is MACH Architecture for ecommerce?
In the past, retailers faced the looming battle of brick and mortar vs. digital buying experiences. While most in the retail industry accepted the inevitability of needing some kind of digital experience, COVID-19 forced retailers to refocus efforts to digital-first, or at the very least, hybrid digital and in-person buying options. What customers expect (and why legacy systems don't hold up) Which leads us to one of the underlying problems for modern retailers: legacy architecture. The digital solutions many depend on aren’t able to meet consumers’ digital-first (or at the very least digital-friendly) ecommerce expectations. Today’s customers expect: Mobile-friendly architecture - People shop from their phones. If your ecommerce experience was designed with web-first in mind, only retrofitting a mobile component to meet buyer demand, you may need to rethink your mobile offering. Omnichannel experience - Beyond having a mobile-friendly buying experience, consumers want to carry their purchasing power from channel to channel and even into the physical store. Think buying online and picking up in store (BOPIS), or starting an order from your phone and completing it in store, or vice versa. Dynamic product catalogues - Consumers want ample choice and a smooth search experience. Can your systems hold up with thousands of products all displayed, searchable, managed, updated, and dynamically enriched with discounts, product offerings, and more? They also expect real-time stock availability, both in store and online. They want to know you really have an item in stock at their local store before venturing out to buy it. Personalization - Personalization is so ingrained in the online retail experience now that consumers have come to expect it. They want real-time recommendations for the items they’re interested in, with predictions based on past online purchases and searches, items in their cart, and in-person buying experiences. Why is it difficult to live up to these expectations? For many in ecommerce, they’re still running monolithic applications built as a single, autonomous unit. This means even the smallest changes, like altering a single line of code or adding a new feature, could require refactoring the entire software stack, leading to downtime and lost business. In addition, the long-term opportunity cost of having your development team waste time simply maintaining and patching such a brittle ecommerce system is a constant drain, or Innovation Tax , on your business. So retailers face a unique challenge. The thought of overhauling their current systems lead to fears like downtime, expensive investments in new solutions, and ultimately, massive loss of profit. But providing an e-commerce experience that lives up to consumer expectations isn’t optional anymore; it’s how your business thrives. That’s where the MACH Approach comes in. MACH Approach: ecommerce modernization with flexibility in mind So, what’s the MACH approach and, to put it bluntly, why should the retail industry care? The MACH approach, championed by the MACH Alliance , an industry body of which MongoDB is a member, is focused on facilitating the transition from monolithic, legacy ecommerce architectures to modern, streamlined e-commerce applications. Microservices - Microservices break down specific business functionalities into smaller, self-contained services. Instead of taking your whole application offline to add new shopping cart features, you update specific elements of your architecture without disrupting the entire application. This affords developers a level of flexibility that monolithic systems can’t compete with. Greater developer flexibility means minimal downtime, faster updates, an improved experience for consumers, and ultimately faster time to value for your business. API-first - APIs, the pieces of code allowing communication between separate applications or microservices, should be at the forefront of solution development, instead of an afterthought. An API-first approach to development is just that — APIs are built first and all other actions are developed to preserve the original API for greater consistency and reusability. This approach ensures planning revolves around the end product being consumed by different devices (like mobile) and APIs will be consumed by client applications. Cloud-native - At this point, to say “the cloud is the future of app development” is cliche; we’re already there. Building and running applications exclusively in the cloud, whether public or private, allows you to reap all the benefits of cloud development from the start. There are also some cost-cutting benefits to cloud-native environments. You avoid the investment that often comes with on-prem equipment. Most cloud SaaS options have pay-as-you-go cost structures, ensuring you only pay for what you use and leading to most predictable monthly expenses. Using managed cloud solutions, like MongoDB Atlas , also frees up your development team to focus their efforts on where they’re needed most — actually developing your application — instead of sinking valuable time into burdensome administrative tasks. Headless - If your application is down, even for a minute, you run the risk of the consumer simply moving on to another retail option. Downtime equates to lost profits, so to avoid the dreaded disruption to your revenue stream, take a headless approach to application development. With headless, changes to the front end (web store layout, UX, frameworks, design, etc.) can be made without interruption to back end (products, business logic, payments , etc.) operations and vice versa. What's the upside for ecommerce? The four elements of the MACH approach come together to help ecommerce businesses reframe operations, avoid downtime, preserve revenue, provide the best user experience possible, and ultimately ensure your solutions are able to develop and evolve. To maintain a competitive advantage in a growingly competitive commerce market, your application needs to keep up. The MACH approach to ecommerce could be the ideal way to set your application and your business apart. Want to learn more about the MACH Approach and the role cloud-native database solutions like MongoDB Atlas play in the evolving world of digital retail? Get your free copy of Ecommerce at MACH Speed with MongoDB and Commercetools today.