Skip to content

MongoDB Backup & Restore Proposal

Jump to bottom
Jim Medlock edited this page Aug 19, 2017 · 1 revision

Introduction

Since devGaido relies on MongoDB to preserve the users state across sessions it's important that the database be periodically backed up and restoration be practiced to ensure that user data is protected and can be recovered in the event of a catastrophic error. This is important since we have the responsibility to our users to protect their progress and any data they entrust to the application.

The basic strategy is to periodically make 'hot' backups of the production database and to preserve those copies to be used to restore the system to its pre-error state. A 'hot' backup is defined as one taken while the application is active to eliminate downtime.

The remainder of this discussion documents the 'hot' backup/restore strategy to be added to devGaido devops, as well as the test methodology and results.

Recovery Objectives

The determination of how often a backup is to be taken is based on two application defined metrics.

  • Recovery Point Objective (RPO) is the maximum amount of time in which a data loss could be tolerated.
  • Recover Time Objective (RTA) is the maximum amount of time the application can be out of service for a recovery operation.

The goal of many applications is to minimize both of these to limit the amount of possible data loss and the time needed to complete a recovery operation. Minimizing the RTA requires that backups be taken on a more frequent basis which increases disk space and impacts application performance. The reason for the latter is there are points at which segments of the database must be serialized and memory caches flushed in order for the backup to be viable.

Hot Backup Strategy

Due to the low user volume of devGaido and its small database size the standard MongoDB mongodump and mongorestore will be used for backup and restoration operations. MongoDB provides other more robust options that can be used as devGaido scales up. However, until they are needed this simpler, more straight forward method will be used.

Test Strategy

Test #1

Validate that the hot backup can be taken while the applications is active and that the database can be restored with no loss of data or integrity.

Test Steps

  1. Verify that the devGaido backend is up and running
  2. Using Mongo Compass capture an image of the data in the database
  3. Run mongodump -o ../dgbackups to create a backup
  4. Run mongorestore --drop ../dgbackups to restore the database
  5. Validate that the application is still running
  6. Using Mongo Compass capture a new image of the data in the database and compare it to the one taken prior to the backup

Test Results

This test was successful as demonstrated by the following results.

  1. Verify that the devGaido backend is up and running
...
[./node_modules/webpack/hot/log-apply-result.js] (webpack)/hot/log-apply-result.js 1.31 kB {0} [built]
   [0] multi (webpack)-dev-server/client?http://localhost:8081 webpack/hot/dev-server webpack-dev-server/client?http://localhost:8081 react-hot-loader/patch ./src/client/index.jsx 76 bytes {1} [built]
[./node_modules/webpack/hot/log.js] (webpack)/hot/log.js 1.04 kB {0} [built]
[./src/client/App.jsx] ./src/client/App.jsx 3.17 kB {1} [built]
[./src/client/index.jsx] ./src/client/index.jsx 1.23 kB {1} [built]
[./src/client/pages/shared/GAListener.jsx] ./src/client/pages/shared/GAListener.jsx 3.29 kB {1} [built]
[./src/client/store.js] ./src/client/store.js 1.83 kB {1} [built]
    + 800 hidden modules
webpack: Compiled successfully.
[session-file-store] Deleting expired sessions
  1. Using Mongo Compass capture an image of the data in the database
_id:"github|1287072"
data:Array
   0:Object
      type:"ADD_BOOKMARK"
      itemId:"srcctrl"
      itemCategory:"paths"
      version:"1.0.0"
   1:Object
      type:"SET_CURRENT_PATH"
      pathId:"srcctrl"
   2:Object
      type:"SET_LAST_TOUCHED_LESSON"
      lessonId:"trygit"
   3:Object
      type:"COMPLETE_LESSON"
      lessonId:"trygit"
      version:"1.0.0"
  1. Run mongodump -o ../dgbackups to create a backup
[jim@jim-manjaro devgaido]$ mongodump -o ../dgbackups
2017-08-16T19:21:34.621-0500    writing admin.system.version to
2017-08-16T19:21:34.622-0500    done dumping admin.system.version (1 document)
2017-08-16T19:21:34.622-0500    writing devgaido.users to
2017-08-16T19:21:34.625-0500    done dumping devgaido.users (1 document)
  1. Run mongorestore --drop ../dgbackups to restore the database
[jim@jim-manjaro devgaido]$ mongorestore --drop ../dgbackups
2017-08-16T19:22:44.639-0500    preparing collections to restore from
2017-08-16T19:22:44.640-0500    reading metadata for devgaido.users from ../dgbackups/devgaido/users.metadata.json
2017-08-16T19:22:44.957-0500    restoring devgaido.users from ../dgbackups/devgaido/users.bson
2017-08-16T19:22:44.959-0500    no indexes to restore
2017-08-16T19:22:44.959-0500    finished restoring devgaido.users (1 document)
2017-08-16T19:22:44.959-0500    done
  1. Validate that the application is still running

From a browser session validated that the app continues to function and displays the dashboard contains the expected state for the user - started, bookmarked, and completed paths and lessons.

  1. Using Mongo Compass capture a new image of the data in the database and compare it to the one taken prior to the backup
_id:"github|1287072"
data:Array
   0:Object
      type:"ADD_BOOKMARK"
      itemId:"srcctrl"
      itemCategory:"paths"
      version:"1.0.0"
   1:Object
      type:"SET_CURRENT_PATH"
      pathId:"srcctrl"
   2:Object
      type:"SET_LAST_TOUCHED_LESSON"
      lessonId:"trygit"
   3:Object
      type:"COMPLETE_LESSON"
      lessonId:"trygit"
      version:"1.0.0"
Clone this wiki locally