Orphaned disks: the question to ask before deleting

You deleted a machine. You look at the storage and the space did not come back. The disk is still sitting there, belonging to nobody.

This is not a bug in Proxmox. But if you start deleting without knowing how it happened, you can delete something that is genuinely needed.

Leftover disks stay behind for three different reasons

They appear side by side on the same screen, but their stories differ and so does the risk of deleting them.

No owner at all. The machine number in the disk's name belongs to no machine. The machine really was deleted and the disk stayed. Or that number was never used and the disk was allocated empty on purpose.

The machine exists, the disk is not attached. The machine is there, but this disk is not connected to any slot. Usually somebody detached it deliberately: they are moving data, taking a backup, and will attach it again.

Proxmox itself marked it as unused. It appears in the machine's configuration but is not in an active slot. This is a state the system is already telling you about.

Seeing all three in one list and deleting them together is the most dangerous move. In the middle two cases, the person who left that disk there usually still needs it.

How they appear

The most common path is this: you detach the disk from the machine first, then delete the machine. The moment you detach it, no record of it remains in the machine's configuration. Then when you delete the machine, the system does not know about that disk, because it is no longer written anywhere. The machine goes, the disk stays.

A half-finished disk move produces the same result: the copy exists in the new place and the old one could not be removed.

And there is a deliberate case: allocating an empty disk that belongs to no machine. That disk is orphaned by birth and is not residue waiting to be deleted.

The real issue: this list is a delete list

Most screens give you information. This screen makes you take a decision, and one that cannot be undone.

That makes the correctness of the list more critical than the correctness of an ordinary screen. And there is a sneaky failure mode here.

"Empty" and "unknown" are not the same thing

The way to find orphaned disks is this: get the list of all machines, get the contents of all storages, compare. If a disk in a storage appears in no machine's list, it is orphaned.

Now consider: what happens if the machine list cannot be retrieved?

If the program swallows the error and treats the list as empty, the result is this: no disk can be matched to an owner, so every disk in use looks orphaned. The screen offers you the disks of running machines as things to delete.

The same mistake exists in the other direction. If the storage list cannot be retrieved and is treated as empty, no storage is scanned and the answer comes back "no orphaned disks". Nobody deletes anything in that direction, but telling the user "clean" is also a claim, and you do not have the data to make it.

The shared lesson fits in one sentence: an empty answer and a failure to get an answer are not the same thing. The first says "there is no such thing", the second says "I cannot tell you". The moment a program conflates the two, it starts stating things it does not know.

Before you delete

Check the number: is the machine really gone, or is it a template? Templates have disks too, and a template may not appear in lists the way a machine does.

Look at when the disk was detached. A disk detached today is most likely somebody's unfinished work.

Look at snapshots: a disk may no longer be attached and still be depended on by a snapshot.

And the simplest one: instead of deleting, rename or move it first. If nobody comes looking for a week, delete it. If the space pressure is urgent enough to break a week of patience, orphaned disks are not your real problem.

What Atlas does

When Atlas lists orphaned disks it labels the three reasons separately: no owner at all, machine present but not attached, and marked unused by the system. Showing them as one pile would put different risks into the same box.

What is actually worth telling is this: the mistake above genuinely existed in this product, in three separate places.

When the machine list could not be retrieved, the error was turned into an empty array, which means every disk in use would have looked orphaned. When the storage list could not be retrieved, it was likewise treated as empty, which means the user would have received a baseless "clean" answer. And while picking a number for an empty disk, if the list of used numbers could not be retrieved the result was "no number is in use", so the choice fell to the first reserved number. Measured on a live machine: that number was already taken, by a template.

All three were fixed in the same direction: if the list cannot be retrieved, the list is not produced at all and the reason is stated. Giving no answer was preferred over giving half of one.

Here is how this differs from the measurement lessons written elsewhere in this wiki: there the question was "what period does this number describe". Here the question comes even earlier: did I actually get an answer?