Some checks failed
API CI / API Lint (push) Successful in 47s
API CI / API Type Check (push) Failing after 47s
API CI / API Test (push) Successful in 1m0s
API CI / API Build (push) Failing after 50s
API CI / Build Docker Image (push) Has been skipped
Build Crossplane Provider / build (push) Failing after 5m51s
CD Pipeline / Deploy to Staging (push) Failing after 29s
CI Pipeline / Lint and Type Check (push) Failing after 36s
CI Pipeline / Build (push) Has been skipped
CI Pipeline / Test Backend (push) Failing after 1m33s
CI Pipeline / Test Frontend (push) Failing after 30s
CI Pipeline / Security Scan (push) Failing after 1m16s
Crossplane Provider CI / Go Test (push) Failing after 3m23s
Crossplane Provider CI / Go Lint (push) Failing after 7m27s
Crossplane Provider CI / Go Build (push) Failing after 3m27s
Deploy to Staging / Deploy to Staging (push) Failing after 30s
Portal CI / Portal Lint (push) Failing after 21s
Portal CI / Portal Type Check (push) Failing after 21s
Portal CI / Portal Test (push) Failing after 21s
Portal CI / Portal Build (push) Failing after 22s
Test Suite / frontend-tests (push) Failing after 30s
Test Suite / api-tests (push) Failing after 49s
Test Suite / blockchain-tests (push) Failing after 30s
Type Check / type-check (map[directory:. name:root]) (push) Failing after 23s
Type Check / type-check (map[directory:api name:api]) (push) Failing after 21s
Type Check / type-check (map[directory:portal name:portal]) (push) Failing after 19s
Validate Configuration Files / validate (push) Failing after 1m52s
CD Pipeline / Deploy to Production (push) Has been skipped
Co-authored-by: Cursor <cursoragent@cursor.com>
3.3 KiB
3.3 KiB
Ceph MON Recovery Plan - R630-01
Current Status
✅ ML110-01 MON: Running (but in "probing" state - no quorum)
❌ R630-01 MON: Failed (corrupted RocksDB due to failing disk)
❌ Cluster Quorum: Lost (need 2/2 MONs for quorum)
Root Cause Summary
- Hardware:
/dev/sdaon r630-01 has critical medium errors - Symptom: Ceph MON RocksDB database corrupted (
001572.sstI/O error) - Impact: MON cannot start, cluster has no quorum, OSDs cannot start
Recovery Strategy
Since ml110-01 MON is running, we can recreate the r630-01 MON. The MON will sync cluster state from ml110-01.
Prerequisites
- Fix or replace failing disk
/dev/sdaon r630-01 (or move MON to different disk) - Backup current state (already documented)
- Verify ml110-01 MON is accessible from r630-01
Recovery Steps
Step 1: Stop Failed MON Service
ssh root@192.168.11.11 'systemctl stop ceph-mon@r630-01'
ssh root@192.168.11.11 'systemctl disable ceph-mon@r630-01'
Step 2: Backup Corrupted MON Directory
ssh root@192.168.11.11 'tar -czf /root/ceph-mon-r630-01-corrupted-$(date +%Y%m%d-%H%M%S).tar.gz /var/lib/ceph/mon/ceph-r630-01/'
Step 3: Remove Corrupted MON
ssh root@192.168.11.11 'pveceph mon destroy r630-01'
Alternative if pveceph fails:
ssh root@192.168.11.11 'rm -rf /var/lib/ceph/mon/ceph-r630-01'
Step 4: Recreate MON on R630-01
ssh root@192.168.11.11 'pveceph mon create r630-01'
The MON will:
- Create a new RocksDB database
- Sync cluster state from ml110-01
- Rejoin the quorum
Step 5: Verify Recovery
# Check MON status
ssh root@192.168.11.11 'systemctl status ceph-mon@r630-01'
# Check cluster quorum
ssh root@192.168.11.11 'ceph quorum_status'
# Check cluster health
ssh root@192.168.11.11 'ceph -s'
Step 6: Restart OSDs
Once quorum is restored:
ssh root@192.168.11.11 'systemctl restart ceph-osd@1'
ssh root@192.168.11.10 'systemctl restart ceph-osd@0'
Disk Issue Resolution
Option A: Move MON to Different Disk (If Available)
If r630-01 has another disk with space:
- Create new directory on different disk:
/mnt/other-disk/ceph-mon/ - Update MON service to use new location
- Recreate MON in new location
Option B: Replace Failing Disk
- Replace
/dev/sdawith new disk - Restore Proxmox installation
- Recreate MON
Option C: Fix Filesystem (If Disk is Recoverable)
- Run
fsckon filesystem - Check SMART status:
smartctl -a /dev/sda - If disk is recoverable, proceed with MON recreation
Risk Assessment
- Low Risk: Recreating MON from healthy peer (ml110-01) is standard procedure
- Medium Risk: If ml110-01 MON also fails during recovery, cluster becomes unrecoverable
- High Risk: If disk continues to fail, MON will corrupt again
Post-Recovery Actions
- Monitor disk health: Set up SMART monitoring for
/dev/sda - Add third MON: Consider adding a third MON on a different node for redundancy
- Backup MON data: Regularly backup
/var/lib/ceph/mon/directories - Monitor cluster: Watch for recurring I/O errors
Notes
- Password Security: Root password was exposed. Rotate immediately.
- Quorum: With 2 MONs, both must be healthy. Consider adding a third MON.
- OSD Recovery: OSDs will automatically recover once MON quorum is restored.