> ## Documentation Index
> Fetch the complete documentation index at: https://playbook.smedleygroup.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Monthly Deep Dives

> The monthly session: restore rehearsal, capacity and data growth, and cost optimisation.

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

> [!WARNING]
>
> 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.