Hi, > This assumption was challenged via OAK-1357 with the idea that the > MongoDB > backup can already produce consistent (non-blocking) backups so there's > nothing to be done in this area. Also restoring means only replacing the > old db with the backup one.
the MongoDB management service (MMS) mentioned by Jukka is one option, but I think we should also have a backup mechanism that works without a third party dependency. the other methods discussed in the MongoDB documentation [0] do not guarantee consistent backups in a sharded cluster, but I wonder if we can make use of the oplog. we could first create an approximate point in time backup as described here [1]. the backed up shards may not provide a consistent view across the mongo cluster. to get the shards in a consistent state we would query the oplog on each of the shards and apply them up to a known point that is consistent. regards marcel [0] http://docs.mongodb.org/manual/core/backups/ [1] http://docs.mongodb.org/manual/tutorial/backup-sharded-cluster-with-filesystem-snapshots/
