Source identity
| Field | Recorded value |
|---|---|
| Source type | GitHub source |
| Original record | Janady13/missionmatch / docs/STORAGE_RELOCATION_PROPOSAL.md |
| Date | Not specified in source |
| Repository | Janady13/missionmatch |
| Revision | 720d47fae476b0d38477ae4401697d372b1ea2bc |
| Branch | feature/opportunity-to-outcome |
| Path or archive member | docs/STORAGE_RELOCATION_PROPOSAL.md |
| Original SHA-256 | 1c70b2f9e5b77f578d720e467a3505861377773cc9dbb528ce44e7ac1fb52293 |
| Git blob SHA | 3ca35f8833771e1d898dd93deacb8e333a3dc845 |
| Reading-copy SHA-256 | 1c70b2f9e5b77f578d720e467a3505861377773cc9dbb528ce44e7ac1fb52293 |
Recovered source transcript
Download complete source text ↓100 lines · 4.6 KB
# STORAGE: A CAPACITY ALERT AND A RELOCATION PLAN
Written 28 July 2026 as an approval item. Two things: a small one to build now,
and a decision that is yours.
## The measurement, taken tonight
/dev/nvme0n1p2 221G total 171G used 40G free 82%
/home/user/mmk 40G MMK kernel work, not missionMATCH
/var/www 5.2G the hosting business vhosts
/usr 4.8G
/home/user/megamind 1.4G
/var/lib 1.2G
/var/backups/missionmatch-db 76M ALL THREE DATABASE BACKUPS
## The problem, stated plainly
**The backups live on the same disk as the thing they protect, and that disk is
82 percent full.** Today that is 76 MB of dumps on a 221 GB volume, so capacity
is not the immediate risk. The immediate risk is correlation: a root disk failure
takes the backups and the platform together, and at that point there is no copy
anywhere. `/mnt/storage` is not mounted because the external drive is dead, and
`mm-db-backup.sh` already prefers it and already logs a warning every night that
it is writing locally.
The second risk is arithmetic. The document corpus is about to start growing:
tier one attachment sync is live, tier two is approved for a rolling harvest, and
37 MB of PDFs already arrived tonight from 25 notices. A corpus that grows and a
backup set that grows share the same 40 GB of headroom, and the largest single
consumer on the disk is 40 GB of unrelated MMK work.
## Part one, build now: the 85 percent alert
Small, and it should not wait for the decision below.
/usr/local/sbin/mm-disk-watch.sh, every 15 minutes via a timer
WARN at 85 percent, one alert on the transition
URGENT at 92 percent
Alerts through mm-alert.sh, the Track H notifier, which is proven working
Reports the top five consumers in the body, so the mail says what to delete
Positive control before it counts: point it at a threshold of 1 percent, confirm
it alerts, restore the real threshold, confirm it stops. Not built yet, because
it is not in tonight's approved scope; it is item 12 in your queue.
## Part two, the decision: what moves
**Option A, move the BACKUP TARGET off the machine.** Preferred.
The backups are the correlated risk, they are the smallest thing to move, and
moving them fixes the property that actually matters. Three sub options:
A1 a replacement external drive, mounted at /mnt/storage
mm-db-backup.sh already prefers it, so this is a mount and nothing else
cost: one drive. effort: minutes. removes: correlated disk failure only
A2 rsync.net or equivalent off site
you already owe a USER@HOST for this from an earlier item
cost: a few dollars a month. effort: an hour. removes: correlated failure
AND site loss AND the "one building" risk in the register
A3 both, A1 for fast restore and A2 for disaster
**A2 is the one I would choose.** The current state fails the same way whether the
disk dies or the building floods, and only off site addresses both. A1 is worth
doing anyway because a local copy restores in 8 to 10 seconds and a remote one
does not.
**Option B, move the DOCUMENT STORE.** Weaker, and here is why.
`MM_STORAGE_ROOT` is not yet set on production, so the document corpus currently
has no home there at all; on staging it lives in a scratch path. Moving something
that does not exist yet is planning, not relocation. The right version of Option
B is a DECISION about where it should be created: on a separate volume from the
start, so the corpus can grow without ever competing with the backups.
B1 put MM_STORAGE_ROOT on the same replacement drive as A1
simple, and it recreates the correlation the moment the drive is the only
copy of both
B2 put MM_STORAGE_ROOT on its own volume, backups elsewhere
the correct end state, needs two devices
**Option C, reclaim space instead.** 40 GB of MMK kernel work sits in
`/home/user/mmk`. That is not a missionMATCH decision and I have not touched it;
it is noted only because it is the single largest consumer and it may be
relocatable at no cost to anything here.
## What I recommend, in one line
Build the 85 percent alert now, mount a replacement drive as `/mnt/storage`
(A1), add off site as A2, and set `MM_STORAGE_ROOT` on the new volume when
document intake goes to production, which keeps the corpus and the backups from
ever sharing a failure.
## What I need from you
1. Approval to build the disk alert, which is self contained.
2. A choice between A1, A2, or both.
3. The `USER@HOST` for rsync.net if A2, which is still owed from Track H.
4. Nothing about `/home/user/mmk`, unless you want it considered.