1 Comment

Summary:

10gen, the company behind the popular MongoDB NoSQL database, has come out with a way for users to back up their data, so developers can focus on building applications.

datacenterimage1

There’s no question that MongoDB is popular among developers. 10gen, the company behind the NoSQL database, has been building out its executive team. Now 10gen is adding a support mechanism that could give users some assurance that they won’t lose their data in the event of a disaster.

The MongoDB Backup Service, now in limited release with general release slated for the summer, lets customers determine how often they want to back up their databases at colocation facilities 10gen uses. If a user wants to back up every six hours, for example, then that user has many options to choose from in the way of restoring a database to a previous state. They can choose the version from six, 12, 18 or 24 hours ago. Restores require two-factor authentication and work across multiple shards. Customers pay only for the amount of backup that they use.

10gen, based in New York and Palo Alto, Calif., expects the service to be a hit not necessarily with big companies but with small and medium-sized businesses. “It allows them to focus on building out applications instead of worry about this operational part of the infrastructure,” said Kelly Stirman, director of product marketing at 10gen. Regardless of company size, the feature could be valuable for anyone working in Mongo with larger data sets.

Beyond that, backing up means users can move data from a production environment into a testing environment to look for issues so their production environment won’t be affected.

While many MongoDB users already back up their databases, the systems are typically homemade, Stirman said. The MongoDB Backup Service, by comparison, is more reliable.

You’re subscribed! If you like, you can update your settings

  1. David Mytton Wednesday, May 1, 2013

    The particularly useful feature of this service is the ability to restore from any point in time. Snapshots are taken periodically and provide a quick way to restore but you can actually pick any date and time (down the second) to restore from. This is because it’s acting as a replication slave and parses the oplog, applying every change as if it’s a differential backup against the original sync. Pretty useful.

Comments have been disabled for this post