Post on 12-May-2015
description
transcript
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
Questions?
Senior Solution Architect, MongoDB
Sam Weaver
#MongoDBMagementService
Thank You