Senior Solution Architect, MongoDB

Sam Weaver

#MongoDBMangementService

MongoDB Backup Overview

Agenda

• Recap the need for backup• Cover methods for backing up

MongoDB•Introduce MMS Backup•Walkthrough

Disasters do happen

and sometimes they are our fault

• Risks– Storage failure– Power outage– Programmer error– Hardware failure– Data centre failure– Cyber attack

• Storage level options

• MongoDB Backup Service

Availability and Durability

• Relative to any particular risk– How much data can you afford to lose? (RPO)– How long can you afford to be offline? (RTO)– What price are you willing to pay to remove the

risk?

• Solutions– Replication– Application engineering?– Backup

Addressing Risks

Replication

• Built into MongoDB, only ops and infrastructure cost

• Very little to zero data loss in failure

• Down for a very short interval

• BUT… programmer errors will replicate almost instantly

Application Engineering

• Flexible

• Expensive, time and money

• Good use of engineer?

Backup

• Slower to restore

• Can suffer from being out of date

• Fairly cheap

• Isolated

• Covers most risks

• Mongodump/mongorestore

• Storage level options

• MongoDB Backup Service

Backup Approaches

• Can be run online or offline

• Oplog aware for point in time restores

• Filter in, filter out

• Considerations– Data size– Sharding

Mongodump/MongoRestore

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

• File system or block storage snapshots

• Fastest way to backup/restore

• Considerations– Journal– Consistency– Backup granularity (whole file system back

up?)– Ops expertise– Storage of snapshots or data file backups

Storage-level Backups

Using the MongoDB Management Service (MMS) for Backup

How it Works

Overview

• 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 48 hours to enable 24 hour Point-in-time restores

Under the Hood

Once your agents are up...

Once your agents are up...

• Choose which replica sets to enable backup on

•Choose which collections/namespaces to include/exclude

• An initial sync is taken of your data

•Edit snapshot policy

potential choices (select the snapshot you’d like to restore to)

Snapshot screens

Click the “restore this snapshot” , select the delivery method, and complete these fields

Notes: one time link means one time link and no it will never work again and no you cannot email it round and it will work for someone else etc

confirm your 2FA

fun!

get your restore ID

if you check the status on the job, there will now be a http link available.. This will download a tar.gz file to your computer.

• Create a dbpath for the MongoDB data files

• Create a symbolic link pointing to the data files

or create the database path and migrate the

data files

ln -s <hash-snapshot-name> /data/db

• Start a mongod using your new data directory

as the dbpath

mongod --dbpath /location/of/data

Download the data files

Restoring Sharded Clusters

• Balancer paused every 6 hours

• A no-op token is inserted across all shards

and config servers

• Oplog applied to replica sets until point in

which token was inserted

• Provides a consistent state of database

across shards

Click your cluster (in blue font)

You can select a snapshot to restore from OR you can take the way more fun route to restore from a checkpoint. Click “restore!”

here is a list of all the restore

cluster checkpoints for your

sharded cluster. You can select

one of these points in time.

This is the slower option, since

MMS will then rebuild a snapshot

up until the time you’ve entered.

Depending on retention settings

the window of time available to

select from will be limited.

• You will receive one data file to download

for each shard• And one for the config server(s)

•Same process as before for moving the

data files to the server

Restoring Sharded Clusters

Mongodump File system MMS Backup

Initial complexity Medium High Low

Confidence in Backups Medium Medium High

Point in time recovery of replica set

Sort of ☺ No Yes

System Overhead High Can be low Low

Scalable No With work Yes

Consistent Snapshot of Sharded System

Difficult Difficult Yes

Recovery Approaches

Key Benefits

Point in Time

• Oplog stored for 48 hours

• Restore your replica set to any point-in-

time in the last 24 hours by creating a

custom snapshot

•Configurable!

Snapshot Policy

• Every 6 hours for 48 hours

• Every day for 1 week

• Every week for for a month

• Every month for a year

•Configurable!

Easy to Restore

• Pull from custom URL via HTTPS

– One time link that expires when used

• Push via SCP

– Just enter the hostname and auth

method (password or key file)

– The directory to push the data to

Unlimited Restores

• Confidence in your restore process

• Build development, QA, analytics

environments without impacting

production

Fully Managed

• Created by the engineers that build

MongoDB

• No need to write or maintain custom

backup scripts

Getting Started

Getting Started

1. Create an account at

mms.mongodb.com

2. Install MMS Monitoring on your

deployment

3. Register at mms.mongodb.com/backup

4. Install MMS Backup on your deployment

5. Start initial sync

6. Rest easy!

Restore from a point in time snapshot documentation

https://mms.mongodb.com/help/tutorial/restore-from-point-in-time-snapshot/Restore from a stored snapshot https://mms.mongodb.com/help/tutorial/restore-from-snapshot/

Configure your backup data delivery method https://mms.mongodb.com/help/tutorial/restore-select-delivery-format/

All documentation available:http://mms.mongodb.com/help/

Getting Started

mms-sales@mongodb.com for one

month free!

Questions?

Senior Solution Architect, MongoDB

Sam Weaver

#MongoDBMagementService

Thank You