When a server is nearly full, a directory called “old” starts to look helpful. It might contain something removable. Or it might contain the only copy of something we still need; the person who named it has left us an adjective, not a retention policy.
In a shared-server cleanup last month, I set the preservation requirements and approved specific removals. We copied selected historical files off the server and verified them before deleting the server copies, then reviewed build cache separately. Storage volumes whose ownership was unresolved stayed where they were.
The difficult part was deciding what each item was still for. An older deployment package may be the version we need if the current release fails. A stopped service may still have data worth keeping. A resource can be unused at the moment and still belong to somebody’s recovery plan.
Here’s a fictional cleanup list of three items that have been sitting untouched for months:
| Item | What we know | Decision |
|---|---|---|
| Old deployment package | A preservation copy is verified, its owner approves removal, and no deployment or recovery procedure still needs the server copy. | Remove that server copy. |
| Previous application release | It is the agreed rollback version. | Retain it. |
| Unattached data volume | We haven’t established who owns the contents. | Investigate ownership. |
Sorting these by age wouldn’t answer the question. We need to check the running and stopped services, scheduled jobs, and recovery arrangements that might still refer to them. On a shared server, we also need to know whether somebody else is using the same build resources before we clear them out.
Copying files elsewhere introduces another question: what have we actually preserved? In this cleanup, the selected files were streamed to a local archive, so the nearly full server didn’t need room for a second large copy. The verification compared file sizes and hashes, checked that the source hadn’t changed during the transfer, and read the completed archive again before removal. That gave us a verified copy of the selected historical files, but it didn’t give us a fresh backup of the live websites.
The build-cache review supplied a useful example of why “we have the source locally” needs checking. Two local working files differed from the versions retained on the server. We preserved the exact server versions before removing the approved cache records; the newer working copies couldn’t stand in for the inputs to those older builds.
We didn’t perform a clean rebuild from the preserved inputs. That remains a separate test, with its own questions about dependencies and the build environment. The cleanup record says what was copied and checked, so the next person doesn’t have to discover that limit while trying to recover a service.
After removal, we measured available filesystem space and checked the affected services. The recorded checks showed that previously healthy services remained healthy, and no services were restarted. Those were checks of the scoped services at the time, not a test of every application workflow. The space measurement mattered too: a cleanup tool’s estimate of removable data isn’t a measurement of the space the server actually recovered.
The retained copies need owners and a reason to keep them, otherwise we’ve moved the next cleanup problem to another disk. A useful record says what the archive contains, why it remains, and what decision would let us retire it. A review date is a reminder to make that decision, not permission for a scheduled job to make it for us.
If we still can’t identify the owner of a volume, leave that question in the handoff with someone responsible for answering it. Freeing enough space to work safely gives us time to investigate; it doesn’t turn an unknown volume into a disposable one.
—jhunterj