Unused storage belongs in a review queue, not a delete queue

What Kubernetes added, and when

In its 21 September announcement, Kubernetes describes the PersistentVolumeClaimUnusedSinceTime feature reaching beta in 1.37 and being enabled by default. The PVC protection controller maintains an Unused condition and a transition timestamp. Pending and running consumers count as references; terminal Pods do not keep the claim in use. This article revisits that announcement for October storage reviews. It is not a new release announcement for 24 October, and the behavior must be checked against the cluster version and feature configuration actually installed.

That condition answers a reference question. It does not establish whether the data has business value, when an application last wrote it, or whether another recovery procedure depends on it. Our analysis is that this evidence should shorten an investigation while leaving the disposal decision explicit. A storage interface becomes more useful when it can say why an object is a candidate, who must review it and which facts remain unknown. A large reclaimable-looking total should never conceal those distinctions.

Find an owner before choosing a retention rule

Start a review with a stable object identity, namespace or workspace, application relationship and observation time. A friendly volume name may be reused or may outlive the application that created it. Look for the owner who can explain why the data exists and how it would be recovered. If ownership is missing, put that absence in the review queue instead of assigning the volume to whoever happens to be on call. Unowned data is a governance problem before it is a cleanup opportunity.

Use an illustrative example: a test environment is removed after a migration rehearsal, leaving its storage behind. The same outward condition could also describe a deliberately paused production service or a database retained for rollback. The usage observation is identical; the correct decision is different. Identify the application lifecycle and the obligation attached to the data. A label such as temporary can support the review, but its meaning needs a documented owner and expiration rule. Otherwise the label merely restates an assumption that no one has verified.

Suppose the review window is shorter than the interval of an infrequent reporting job. Its storage may look idle throughout the entire window even though the next scheduled run still needs it. The investigation should therefore include the expected consumer lifecycle, not just the most recent resource snapshot. Ask the owner which future event would make the data necessary again and whether that dependency has actually been retired. This question turns a vague request to keep everything into a concrete retention reason, while giving genuinely abandoned test storage a route to a documented expiry decision.

Understand what the removal would actually do

An object’s disappearance from an API and the release of its underlying bytes are not interchangeable outcomes. The persistent-volume documentation describes reclaim behavior, including Retain and Delete policies. Inspect the actual storage class, volume and provider behavior for the selected object before planning removal. A controller accepting a request does not establish the final storage result. This distinction matters both for protecting data and for avoiding a false promise that a particular amount of space will immediately return.

The same review principle applies on a single server. A measured directory, an image-store estimate and filesystem free space describe different things. Shared layers, snapshots, reserved space and an open deleted file can make a simple subtraction misleading. Use measurements as evidence for a specific action, not as a guarantee about its result. After an approved operation, measure the relevant storage boundary again and record what actually changed. Keep the owner, policy version and object identity in the completion record. Keep an accounting gap visible rather than inventing a folder that can be safely deleted.

A paused consumer can still have a live recovery obligation

Before reclaiming a candidate, ask whether it contains a rollback source, an isolated restore under investigation, retained uploads or an archive required by the current recovery policy. Check the operation journal where one exists. An interrupted migration can leave data on two servers while authority remains unresolved. Removing the apparently idle side can turn a recoverable ambiguity into permanent loss. The absence of a current application reference does not settle which copy an operator may need to inspect next.

Give recovery material a separate lifecycle from disposable caches. Identify the recovery point, its relationship to the current service, the retention window and the condition for releasing it. If a test restore is still running or its outcome is unknown, preserve its job identity and follow the installed recovery procedure. Do not treat the scratch directory’s age as proof that the operation ended. Where the system cannot report an authoritative state, escalate that exact object for inspection rather than broadening a cleanup command to neighboring paths.

Turn a candidate list into a bounded operating process

A practical review queue can carry four explicit outcomes: retain for an active dependency, retain for a named recovery obligation, eligible under an approved expiry rule, or unresolved. Add the evidence and owner behind each decision. A grace period can give a returning workload time to reveal a missing dependency, but time alone does not establish permission. Select that period for the application’s operating cycle and recovery needs. A monthly job and a disposable development preview do not have the same useful observation window.

Where automation is appropriate, scope it to a reviewed class of objects whose lifecycle is already understood. Keep a read-only preview separate from the operation that removes anything. Recheck identity and eligibility at execution, cap the scope, and preserve an audit result. These are proposed design requirements, not claims that the new PVC condition implements a cleanup engine. A tool that discovers unused claims has done valuable work even when the correct output is a short review list rather than an enabled Delete all button.

Apply the same evidence discipline to server cleanup

Hostwatch’s cleanup guide distinguishes measured paths, approved cache targets and review-only storage. Its inventory can help connect a path to a service, while the cleanup controls remain limited to their configured scope. This article does not announce Kubernetes PVC deletion through Hostwatch or a general-purpose volume pruner. A service dependency, backup archive or unexplained filesystem difference should remain outside an automatic cache action merely because the disk is nearly full. Pressure increases the value of a precise boundary.

The new Kubernetes condition is useful because it exposes one previously awkward piece of evidence in a standard place. The responsible next step is to connect that evidence to ownership, lifecycle and recovery. The success measure is not the largest possible deletion count. It is a clear decision about each approved candidate, an observed storage result and continued confidence that retained services can run and recover. A smaller, defensible reclaim is more useful than a dramatic free-space number whose hidden cost appears at the next restart.