Do not start with recursive deletion
Record the host's actual capacity error and who administers the service. A full volume, quota or exhausted file count can require different recovery. The following is a conservative triage checklist, not provider-specific command instructions. Never delete uploads, database files or unfamiliar directories merely because they are large.
- Keep the first redacted application or host error.
- Ask the authorised operator to inspect capacity through the host's supported controls.
- Do not send a server login or private directory dump in the enquiry.
Know what a recovery action can destroy
Temporary files, logs, uploads and database data have different retention and recovery needs. A scheduled backup message does not prove the latest data can be restored. Confirm the affected data boundary and trusted restore evidence before any destructive action. If no safe candidate is known, a capacity change may need separate account-holder approval rather than guessing what to delete.
- No storage purchase or quota increase is implied by this guide.
- Do not erase the only diagnostic evidence.
- Do not remove database-managed files outside the database's documented procedure.
Restored capacity is not full acceptance
After an authorised recovery, check the agreed read and write flow, uploads and relevant background work. A page rendering can hide failed writes, missing files or a stopped queue. Identify why capacity grew so the same incident does not immediately return; retention and monitoring changes should be separately scoped and approved.
- Record remaining headroom and the verification time.
- Check that cleanup did not remove required application content.
- Keep restoration exceptions visible.
Request a bounded recovery
Send provider type, redacted capacity error, affected flow and whether a verified restore point exists. The quote depends on the safe recovery route and data risk, not an invented minutes-to-fix promise. Production actions require the authorised operator and explicit agreement.
Sources and limits
- PostgreSQL: backup boundaries Checked 2026-10-10.
- A normal database dump covers one database, not cluster-wide roles or every website file.
- Django: backups and logging Checked 2026-10-10.
- Database and uploaded media need backup strategies and logging should be reviewed.