Keeping Your Data Safe

Andrew Erlichson (andrew@mongodb.com)VP, Education & Cloud Services

Disasters do happen

Sometimes they are our fault

4

• Lose very little to zero data in a failure

• Down for a very short interval (availability is high)

• BUT: programmer errors, deliberate data loss is often replicated nearly instantly.

Replication

5

• Much slower to restore (availability suffers)

• Out of date to some extent

• Fairly cheap

• Well isolated

• Handles all risks

Backup

6

• Checkpointing through Snapshots

• Isolation

Backup Defined

7

• mongodump/mongorestore

• Storage-level solutions

• MMS Backup (new!)

Backup Approaches

8

Replication

9

• Can be run in live or offline mode

• Oplog-aware for point-in-time operations

• Filter can be applied in both directions

• Considerations– Working set– Sharding

mongodump / mongorestore

10

Backing upmongodump --host foo.bar.com --oplog --out /data/backup

Restoring

To a running mongodb

mongorestore –host foo.bar.com --oplogReplay /data/backup

Directly to the filesystem

mongorestore –dbpath /data/backup

Using Mongodump

11

• Copy files in your data directory (e.g. /data/db)

• Filesystem or block storage snapshot

• Fastest way to backup/restore

• Considerations– Consistency– Backup granularity– Ops expertise

Storage-level Backups

12

• Don’t turn off journaling– Safe to take a snapshot of a running system if

journaling journaling.

• No Journaling– either shutdown a node or use fsyncLock()

If you have Snapshotting

13

• Use a volume manager that can handle taking incremental snapshots.

• Turn on journaling

• Backup from a secondary node

• Take a snapshot ever six hours (or whatever frequency you need)

• Use features with the volume manager to take incremental snapshots.

Single Replica Set – Best Practices

14

Sharded Systems

15

• Option 1: Run mongodump against the mongos router– But can’t use --oplog option– impractical for large system

• Option 2: Backup each shard individually– Stop the balancer– Shutdown a replica set secondary on each shard– Shut down a node of the config server– Run mongodump or take snapshot of each shard– Run mongodump against the config server– Restart the config server, restart the balancer,

Sharded System

16

What is MongoDB Management Service (MMS)?

17

MongoDB Management Service

MongoDB, Inc.

18

Free Monitoring

19

MMS Backup: Big Picture

Point in time restores• Restore replica to any moment in

last 24 hours.

Reliable• Developed and monitored by

MongoDB• Redundant data centers• Fully managed solution

Handles Sharded Systems• Consistent Snapshots

Frees up Engineering to do Engineering• Are backups your core competency?

20

Unlimited free restoresSeed dev, test, or new environments

21

• From the initial sync, we rebuild your data in our datacenters and take a snapshot

• We take snapshots every 6 hours

• Oplog is stored for 24 hours

MMS Backup (under the hood)

22

Sharded Clusters

Backup Agent

Shard0 Shard1 Shard2

OPLOG

MongoDBDatcenter

Encrypted Oplog

Detect NOP and create snapshot for each shard

NOPsSnapshot

SnapshotSnapshot

NOPNOP

NOP

23

Mongodump File system MMS Backup

Initial complexity Medium High Low

Confidence in Backups

Medium Medium High

Point in time recovery of replica set

Snapshot Moments only

Snapshot Moments only

24H

System Overhead High Varies Low

Scalable No With work Yes

Consistent Snapshot of Sharded System

Difficult Difficult Yes

Recovery Approaches

24

1. Create an account at mms.mongodb.com

2. Install MMS Monitoring Agent on your deployment

3. Install MMS Backup Agent on your deployment

4. Start initial sync

5. Rest easy!

Getting Started with MMS Backup

25

MongoDB WorldNew York City, June 23-25

http://world.mongodb.comSave $200 with discount code MODERNAPPS

#MongoDBWorld

See how Bosch, UK Government Digital Service, Carfax, Stripe and others are engineering the next generation of data with MongoDB