Ridge Operations

Ridge operations are explicit, bounded, and local. Use the database APIs, ridged operator commands, or Ridge Admin capability-driven controls. Never copy or modify live storage files directly.

Integrity

Run integrity checks after suspected storage damage, restore, or a maintenance incident. Integrity validates catalog, B+Tree, row, version, and index relationships. A failed check is a stop condition; preserve diagnostics and avoid further mutation until the cause is understood.

Backup

Start ridged with an existing private absolute backup root:

ridged --data=/srv/ridge/main --backup-root=/srv/ridge/backups

Ridge Admin then exposes named backup creation and verification. Backup names follow [a-z_][a-z0-9_]{0,63} and are never browser-provided paths.

RIDGE ADMIN BACKUP STATUS;
RIDGE ADMIN BACKUP CREATE ridge_20260727_120000;
RIDGE ADMIN BACKUP VERIFY ridge_20260727_120000;

Backups contain a versioned manifest, exact sizes, and CRC-32 checksums. Verification must complete before restore.

Offline restore

Restore only into an unused absolute target:

ridged --backup-root=/srv/ridge/backups \
  --verify-backup=ridge_20260727_120000

ridged --backup-root=/srv/ridge/backups \
  --restore-backup=ridge_20260727_120000 \
  --restore-target=/srv/ridge/restored_20260727

Restore validates the manifest and database, publishes the catalog last, and refuses an existing target. Cutover and rollback remain separate operator actions. Do not restore over the active database.

Vacuum and indexes

Vacuum preserves the oldest live snapshot and reuses bounded free pages. Reindex and schema maintenance must use supported commands and capability checks. Schedule potentially expensive work, inspect active sessions, and retain a verified backup before structural changes.

PITR and diagnostics

ridge_ops provides commit/timestamp archive PITR, restore drills, migration records, maintenance, health and metrics snapshots, slow-query logs, quotas, read-only operation, and disk-full injection. PITR restores commit boundaries; it is not arbitrary physical WAL replay.

Safe operator sequence

  1. Confirm the database, data prefix, build identity, and capability version.
  2. Inspect health, active work, disk space, and current backup status.
  3. Create and verify a backup before risky maintenance.
  4. Run one bounded operation.
  5. Reopen when required and run integrity.
  6. Verify logical data through SQL.
  7. Record the result and keep rollback inputs until acceptance.