cloudthinker-ai Storage Expansion Runbook Skill
Expand storage on {{ target_host }} from {{ current_size }} to {{ target_size }}. Filesystem: {{ filesystem_type }}
Workflow
Phase 1 — Capacity Assessment
CAPACITY ASSESSMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CURRENT STATE
Host: {{ target_host }}
Volume / device: ___
Filesystem: {{ filesystem_type }}
Current size: {{ current_size }}
Used space: ___ (___%)
Available space: ___
Inode usage: ___% (check for inode exhaustion)
Growth rate: ___ GB/day
EXPANSION DETAILS
Target size: {{ target_size }}
Increase: ___ GB (___ % increase)
Estimated runway after expansion: ___ days
PREREQUISITES
[ ] Volume type supports online resize (e.g., AWS EBS gp3, Azure managed disk)
[ ] No pending volume modifications in progress
[ ] Sufficient quota / limits for new size
[ ] Budget approval for additional storage cost: $___/month
Phase 2 — Pre-Expansion Backup
PRE-EXPANSION BACKUP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Create volume snapshot before resize
Snapshot ID: ___
[ ] Verify snapshot completed and is usable
[ ] Record current mount options: ___
[ ] Record current fstab entry: ___
[ ] Record partition table layout (fdisk -l / lsblk)
[ ] Verify no active writes paused by snapshot (if applicable)
Phase 3 — Volume Resize
VOLUME RESIZE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CLOUD PROVIDER RESIZE (AWS EBS / GCP PD / Azure Disk):
1. [ ] Modify volume size: {{ current_size }} -> {{ target_size }}
2. [ ] Record modification request ID: ___
3. [ ] Wait for volume state: "optimizing" -> "completed"
4. [ ] Verify new size visible in cloud console
5. [ ] Check volume modification history for errors
ON-PREMISE / LVM:
1. [ ] Add new physical volume or expand existing LUN
2. [ ] Extend volume group: vgextend
3. [ ] Extend logical volume: lvextend
4. [ ] Verify new size with lvdisplay / vgdisplay
Phase 4 — Filesystem Extension
FILESYSTEM EXTENSION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PARTITION RESIZE (if partitioned):
1. [ ] Extend partition to use new space (growpart / parted)
2. [ ] Verify partition table updated (lsblk)
FILESYSTEM RESIZE:
ext4: resize2fs /dev/xxx
xfs: xfs_growfs /mount/point
btrfs: btrfs filesystem resize max /mount/point
1. [ ] Execute filesystem resize command
2. [ ] Verify new size:
- df -h shows: ___
- Expected: {{ target_size }} (minus filesystem overhead)
3. [ ] Verify filesystem integrity (no errors in dmesg)
4. [ ] Confirm mount options unchanged
Phase 5 — Post-Expansion Validation
POST-EXPANSION VALIDATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STORAGE HEALTH
[ ] df -h shows correct new size
[ ] Filesystem check reports no errors
[ ] I/O performance test (dd or fio baseline):
- Write throughput: ___ MB/s (vs. baseline: ___ MB/s)
- Read throughput: ___ MB/s (vs. baseline: ___ MB/s)
- IOPS: ___ (vs. baseline: ___)
[ ] No increased latency on storage operations
APPLICATION HEALTH
[ ] Application read/write operations functioning
[ ] Database (if applicable) reports correct data directory size
[ ] Log writes continuing without errors
[ ] No "disk full" alerts cleared / no new alerts
MONITORING
[ ] Disk usage alerts updated for new thresholds
[ ] Monitoring showing correct volume size
[ ] Growth rate tracking resumed
Phase 6 — Cleanup
CLEANUP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Remove pre-expansion snapshot after 48h stabilization
[ ] Update CMDB / infrastructure inventory with new size
[ ] Update capacity planning spreadsheet
[ ] Update infrastructure-as-code (Terraform, CloudFormation)
[ ] Close change management ticket
[ ] Set monitoring alert for next capacity threshold (e.g., 80%)
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Produce a storage expansion report with:
- Expansion summary (host, old size, new size, filesystem)
- Pre-expansion backup confirmation with snapshot ID
- Resize execution log with provider-specific details
- Filesystem extension confirmation with df output
- Performance validation (throughput and IOPS comparison)
- Updated capacity forecast with new runway estimate