Skip to main content
One session a month, covering the work that is too slow for a weekly check but too important to leave to a quarterly review.

​
Restore Rehearsal

A backup that has never been restored is not a backup. Recovery for both database instances is a manual process with no scripted restore, so the real recovery time is whatever a manual restore takes on the day. This rehearsal is what turns that into a known number.
Each month, take a real backup and restore it on your own machine:
1

Take the most recent archive

Download the latest archive from the backup bucket. Use a real one rather than a fresh dump, so you are testing the artefact that recovery would actually depend on.
2

Restore it locally

Restore the archive into a local MongoDB on your own machine with mongorestore. Restoring locally keeps the rehearsal well away from anything live.
3

Verify the contents

Count documents in several collections and compare against the source. Spot check a few recent records to confirm the data is current as well as present.
4

Record the elapsed time

Write down how long the restore took, including the download. That number is the recovery time objective.
Rotate which database you rehearse with, so that over a year the important ones have all been proven rather than just the convenient one.

​
Capacity and Data Growth

  • Project disk exhaustion. Using the weekly disk figures, extrapolate when each volume fills. On the legacy instance the operating system and the data share a single 30 GB volume, so this date is an outage date rather than a degradation date.
  • Review collection growth. Identify which collections are growing fastest, and whether growth is trading volume, audit history, or something unintended such as a retry loop writing duplicates.
  • Check index health. Look for unused indexes consuming memory on an instance that does not have much, and for collections that have grown enough to need an index they did not need before.
  • Right size. Consider whether the instance types still fit, particularly the burstable legacy instance if CPU credit exhaustion has appeared in the weekly checks.

​
Cost Optimisation

Where the weekly cost review watches for change, this session acts on it.
  • Storage lifecycle. Review lifecycle rules on the backup and export buckets so old objects transition to cheaper storage classes or expire.
  • Idle resources. Look for unattached EBS volumes, old snapshots, unused Elastic IPs, empty CloudFront distributions and dev resources that outlived their purpose.
  • Dev environments. Consider whether dev resources need to run continuously, given dev and production databases share one instance and dev traffic is intermittent.
Last modified on September 4, 2026