kyo360-code

Storage

Volume bindings, protection, and the write brake

Volume bindings

repos

FAST

/mnt/fast/kyo360-code/repos

412.0 GB

replica → das-b · 6h · in sync 41m ago

lfs

BULK

/mnt/storage/a/kyo360-code/lfs

1.1 TB

artifacts

BULK

/mnt/storage/a/kyo360-code/artifacts

124.0 GB

cap 500.0 GB

cold → archive @ 30d

index

FAST

/mnt/fast/kyo360-code/index

18.0 GB

○ EPHEMERAL

ephemeral · not backed up · rebuildable

archive

BULK

/mnt/storage/c/kyo360-code/archive

892.0 GB

Protection

●

SnapRAID parity

synced 19h ago

protects: drive loss, bit rotdoes NOT: deletion, a bad force-push, ransomware

●

rsync replica

in sync 41m ago

protects: volume lossdoes NOT: deletion — it replicates on the next run

●

Bundle backups

full 2d, incremental 4h · verified ✓ · drill ✓ 6d ago

protects: deletion, corruption, operator error, GitLab lossdoes NOT: nothing much — this is the real one

Disk floor

Free 640.0 GB · floor 200.0 GB · 3.2x headroom

writes ALLOWED

Below the floor, pushes, LFS uploads and artifact ingest are refused. Reads continue. This host has one filesystem shared with Postgres, every managed app and every VM disk — filling it is a platform-wide outage, so the brake is load-bearing rather than defensive decoration.