Recovery

When a long-running operation fails or your terminal disconnects, use Soviez recovery commands before editing files or containers manually.

--doctor vs operation recovery

Tool	When to use
--doctor	General host health: Docker, disk, services, common misconfigurations
--operation-recover, --update-recover, etc.	A specific install/update/restore/migration operation failed or was interrupted

Start with --doctor for “something is wrong” situations. Use operation-specific recover when you have an operation ID from a failed task.

Principles

• Prefer --*-recover, --*-reattach, and --*-retry on the owning operation
• Do not manually delete candidate containers mid-update without understanding rollback implications
• Untrusted restore recovery goes through quarantine promote/reject — never skip scans
• Apt lock timeouts: wait for other apt owners or schedule maintenance — do not kill apt

Commands

soviez.sh --doctor

soviez.sh --operation-recover <operation-id>
soviez.sh --operation-reattach <operation-id>
soviez.sh --operation-retry <operation-id>

soviez.sh --update-recover <operation-id>
soviez.sh --update-rollback <operation-id>

soviez.sh --restore-recover <operation-id>
soviez.sh --restore-rollback <operation-id>

soviez.sh --migration-recover <operation-id>
soviez.sh --migration-cutover-rollback <operation-id>

soviez.sh --ssl-repair <environment-id>
soviez.sh --reattach <operation-id>

Update rollback window

After a successful update, a time-limited safety window (default 24 hours) allows rollback to the previous version. Check --update-status for remaining window time.

Quarantine recovery

If an untrusted restore is in quarantine:

soviez.sh --security-quarantine-status <id>
soviez.sh --security-quarantine-scan <id>
soviez.sh --security-quarantine-promote <id>   # only after review
soviez.sh --security-quarantine-reject <id>

Never promote on FAIL. When in doubt, restore to Stage instead of Production.

Related

• STATUS_AND_DIAGNOSTICS.md
• TROUBLESHOOTING.md
• RESTORE.md