Shadows

A shadow is a guest’s replicated copy on the recovery side of a pair: a qcow2 file, or a native ZFS, LVM, or Ceph/RBD volume, depending on the storage you chose. The Shadows page shows every shadow Asternodis can find on the recovery side and classifies each one:

• Active: part of a live replication (a protected guest points at it).
• Orphan: sitting in storage with nothing referencing it, such as a guest you stopped protecting, a leftover from a moved or re-seeded shadow, or a shadow from a pair that no longer exists.
• Leftover clone: a stray clone from an interrupted failover or DR test. Safe to delete; deleting it frees the storage and unblocks that guest’s replication. Listed under the Leftovers filter tab, whose count includes leftover DR tests. The same clone name is also how a running operation reads or boots a copy: a recovery-point content check, a capture, a DR test or a copy-path failover. So a scan that lands inside one of those shows it as Clone in use instead (with the operation named in the row): it has no Delete and is removed when that operation finishes.
• DR copy: the recovered guest a failover promoted on this site, kept after an Abort failover or a failback so you can still inspect what the guest looked like here. It is stopped; deleting it destroys that guest and its disks on this site only. Has its own filter tab (“DR copies”) and count tile (“DR copies kept”). A copy that is still in use (its guest is failed over or mid-operation, it is the copy a running DR test booted, or it is not provably stopped, meaning it is running or its power state could not be read) is badged DR copy · in use instead, with a note saying which and no Delete: Asternodis will not offer to destroy a guest it cannot prove is stopped.
• Leftover DR test: a DR-test copy still on the recovery node after its test ended without tearing down. It is debris, not a copy kept on purpose, so it is listed under Leftovers rather than DR copies. Safe to delete once it is confirmed stopped; one that is still running, or whose power state could not be read, reads DR copy · in use, with a Stop DR test link.
• Reverse-sync scratch: staging the reverse lane writes on the primary while a guest is failed over. A row here means the guest is home again and the staging outlived it (an interrupted failback). Safe to delete; the next failover recreates it if needed.
• Orphaned point: a retained recovery-point snapshot a removed pairing or a re-seed left behind. Its row names the snapshot on a line of its own, because its location is the base volume’s name plus a suffix and a narrow column can hide exactly the suffix (a re-seed recreates the shadow; on LVM-thin and Ceph the points are cleaned up with it, and any that linger are listed here to delete).
• Stale reverse baseline: on LVM-thin or Ceph recovery storage, the snapshot a failover takes of a guest’s shadow so a later failback can prove the delta and skip a whole-disk reverse copy (ZFS needs none: the DR copy’s origin snapshot is its baseline). Failback removes it, and so does deleting the DR copy an Abort failover kept. One that outlives both is listed here once the guest is home; deleting it touches neither the shadow nor the guest’s recovery points.
• Leftover clone-seed snapshot: the snapshot a throwaway clone was taken from, listed only once its clone is provably gone. It only holds space, and on Ceph it is protected, which also stops its parent image being removed. Safe to delete.

For each shadow you see its backend (qcow2 file or volume), storage location, size, age, and the owning pair. A directory/NFS/CIFS (file-backed) shadow names its storage like any other. A guest re-seeded onto the same storage address shortly after its old shadow was deleted stays listed as Active throughout.

Some artifacts live on the source side and are listed here too, read across the pair from either site:

• Replication snapshot: the snapshot on a guest’s own storage that the next incremental is computed against. In use while the guest is protected; dead weight once it is not.
• Orphaned disk: a guest-shaped volume on the node that holds the guest’s configuration, which that configuration references nowhere (not attached, not as an unusedN entry, not under a snapshot). Proxmox would list it as unused after a rescan; it only holds space. Deleting it re-checks the configuration on the node first, so a volume the guest has attached since the scan is refused. While a failback is seeding a guest’s new disks on that node they look exactly like this, so they are withheld until the failback finishes, and if that record cannot be read, the delete is refused rather than guessed.
• Old home disk: a guest’s own disk left on the node it used to live on by a failback to a chosen node (a full copy went to the new node; the old one is deliberately not deleted). That route copies only guests whose disks are on storage the home node alone can read (a non-shared ZFS pool, node-local LVM-thin, or a local directory), so a guest moved over shared storage leaves no old disk behind. Offered for deletion only when Asternodis’s own record confirms the guest now lives on another node. The same shape of finding for a guest Asternodis does not protect is shown as an Unreferenced disk: listed for review, never offered for deletion, and left out of the orphan count and the space total. Copies kept by Proxmox’s own storage replication (a job in replication.cfg that targets the node, or a dataset carrying __replicate_ snapshots) are a guest’s standby disk, not a leftover, and are never listed.
• Superseded overlay: a reverse-lane overlay on the guest’s home storage that a newer one replaced. Nothing prunes these, and one may hold the only copy of a failed-over window’s writes, so Asternodis never removes one itself: it is listed for review while the guest is protected, and becomes deletable here once it is not.
• Merged overlay: the safety copy a failback keeps after merging its overlay into the production disk, one per disk. Its contents are already in that disk; like a superseded overlay, it becomes deletable here once the guest is no longer protected.

Scanning

A background scan sweeps the recovery storages every 10 minutes (the first runs about two minutes after the controller starts) and reclassifies every shadow. You can also trigger a scan on demand. The page shows the current scan status (including what it’s scanning right now), a history of past scans, and filter tabs for Active, Orphan, Recovery points, Leftovers and DR copies.

A scan that can’t fully cover every storage (a node that’s briefly unresponsive, a pool that could not be listed) says so on the page: a storage it could not read is reported as not covered, never as clean.

Shadows are listed flat, one row per replica, with a search box above them: type any part of a guest name, a VMID, or a storage ID to narrow the list. On an estate with a lot of replicas that is usually faster than scrolling, and it searches every column shown rather than just the guest.

Shadows physically exist only on the recovery side of a pair, so from a source site the Shadows page reaches across the encrypted peer link to show the replicas held at the recovery site. You get one view of every replica across both sites.

Reclaiming space from orphans

Orphaned shadows still consume storage. Delete an orphan straight from the page to free its space. Asternodis removes the underlying qcow2 files or frees the ZFS/LVM volume. For a Ceph/RBD-backed shadow, the delete confirms no node in the cluster still has the image mapped before it removes anything.

Because a retired pair can leave dozens of orphans behind, you can select many at once and clear them in a single bulk delete, with a per-kind breakdown before you confirm, instead of clicking through them one by one. A shadow whose size couldn’t be read shows as not measured, and the page’s Total size tile then reads at least the measured amount, so an unmeasured shadow’s space is never silently counted as zero.

Active shadows can’t be deleted here. Every delete, single or bulk, is re-verified against a fresh scan and refused for anything a live replication still uses, so you can never cut a protected guest’s recovery copy out from under it, even if the list was captured a few minutes before you clicked. If the acknowledgement of a delete is lost on its way back to your browser, the page says so and points you at the Tasks bell and the Operations page to see what actually happened, rather than inviting a retry of work that may already have run.