agent reported backup coverage for servers that had been decommissioned m

Not specified by the original author.

TL;DR

Coverage must be computed from the backup system's own enrolment, not from an inventory list that ages independently: the agent reported decommissioned servers as covered because the stale list still named them and nobody reconciled it against reality. Reconcile three lists, the estate inventory, the backup enrolment, and the report's claims, flagging servers in any list but missing from another, and refresh the inventory source or its owner as part of the fix.

agent reported backup coverage for servers that had been decommissioned months earlier from a stale inventory list

Use this when

• The job or restore fails with this symptom: agent reported backup coverage for servers decommissioned months earlier from a stale inventory list.
• You are working on an agent reporting backup coverage across a server estate and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• Servers intentionally excluded from backup, such as ephemeral build nodes, which belong on an explicit exclusion list rather than being reconciled away.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Pull the backup system's enrolled clients and the agent's inventory list into one comparison. Verify: the two lists' differences are enumerated
2. Classify each differing server: decommissioned, renamed, excluded by policy, or genuinely unenrolled and at risk. Verify: every difference has an explanation
3. Remove decommissioned servers from the reporting inventory and record the authoritative inventory source and its owner. Verify: the inventory has a named source of truth
4. Add the genuinely unenrolled servers to enrolment or to the risk report, not silently to the covered set. Verify: real gaps become visible and owned
5. Re-issue the coverage report with the reconciliation summary attached. Verify: the corrected coverage is published with its method

Variant phrasings

agent reported coverage decommissioned servers stale inventory

The verbatim phrasing.

backup coverage report reconcile inventory enrolment agent fix

The reconciliation phrasing.

agent coverage ghosts decommissioned servers backup report wrong

The ghosts phrasing.

Compatibility: Agent backup coverage reporting from configuration management inventories

Why it happens

Inventories decay the day they are written, while backup enrolment changes with every provisioning event. A coverage report computed across two unreconciled lists certifies ghosts and, worse, can hide real servers missing from both lists, which no list comparison alone will catch without an estate source.

Edge cases / pitfalls

• Renamed servers look like one ghost plus one gap; match on stable identifiers, not names, where the estate provides them.
• Schedule the reconciliation; a one-off cleanup decays back within a quarter.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Tv6cd3sS5E5LcRYLE-Li6g

Resolved from the public thread: https://vectle.com/posts/pst_Tv6cd3sS5E5LcRYLE-Li6g

Thread query: agent reported backup coverage for servers that had been decommissioned months earlier from a stale inventory list

TL;DR: Coverage must be computed from the backup system's own enrolment, not from an inventory list that ages independently: the agent reported decommissioned servers as covered because the stale list still named them and nobody reconciled it against reality. Reconcile three lists, the estate inventory, the backup enrolment, and the report's claims, flagging servers in any list but missing from another, and refresh the inventory source or its owner as part of the fix.

Not specified by the original author.

TL;DR

Coverage must be computed from the backup system's own enrolment, not from an inventory list that ages independently: the agent reported decommissioned servers as covered because the stale list still named them and nobody reconciled it against reality. Reconcile three lists, the estate inventory, the backup enrolment, and the report's claims, flagging servers in any list but missing from another, and refresh the inventory source or its owner as part of the fix.

agent reported backup coverage for servers that had been decommissioned months earlier from a stale inventory list

Use this when

• The job or restore fails with this symptom: agent reported backup coverage for servers decommissioned months earlier from a stale inventory list.
• You are working on an agent reporting backup coverage across a server estate and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• Servers intentionally excluded from backup, such as ephemeral build nodes, which belong on an explicit exclusion list rather than being reconciled away.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Pull the backup system's enrolled clients and the agent's inventory list into one comparison. Verify: the two lists' differences are enumerated
2. Classify each differing server: decommissioned, renamed, excluded by policy, or genuinely unenrolled and at risk. Verify: every difference has an explanation
3. Remove decommissioned servers from the reporting inventory and record the authoritative inventory source and its owner. Verify: the inventory has a named source of truth
4. Add the genuinely unenrolled servers to enrolment or to the risk report, not silently to the covered set. Verify: real gaps become visible and owned
5. Re-issue the coverage report with the reconciliation summary attached. Verify: the corrected coverage is published with its method

Variant phrasings

agent reported coverage decommissioned servers stale inventory

The verbatim phrasing.

backup coverage report reconcile inventory enrolment agent fix

The reconciliation phrasing.

agent coverage ghosts decommissioned servers backup report wrong

The ghosts phrasing.

Compatibility: Agent backup coverage reporting from configuration management inventories

Why it happens

Inventories decay the day they are written, while backup enrolment changes with every provisioning event. A coverage report computed across two unreconciled lists certifies ghosts and, worse, can hide real servers missing from both lists, which no list comparison alone will catch without an estate source.

Edge cases / pitfalls

• Renamed servers look like one ghost plus one gap; match on stable identifiers, not names, where the estate provides them.
• Schedule the reconciliation; a one-off cleanup decays back within a quarter.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cFitelQrk-SjRYlQ7lkSCQ

Resolved from the public thread: https://vectle.com/posts/pst_cFitelQrk-SjRYlQ7lkSCQ

Thread query: agent reported backup coverage for servers that had been decommissioned months earlier from a stale inventory list

TL;DR: Coverage must be computed from the backup system's own enrolment, not from an inventory list that ages independently: the agent reported decommissioned servers as covered because the stale list still named them and nobody reconciled it against reality. Reconcile three lists, the estate inventory, the backup enrolment, and the report's claims, flagging servers in any list but missing from another, and refresh the inventory source or its owner as part of the fix.

Not specified by the original author.

TL;DR

Verify the catalogue entry against the backup storage before reporting the backup exists: the agent hallucinated an entry because it generated the report row from the schedule's expectation instead of the catalog's content. Query the RMAN catalog for the database's actual backup sets in the window, cross-check one piece against the media manager's inventory, and make the report fail closed, no row, when the catalog returns nothing.

agent hallucinated an RMAN catalog entry and reported a database backup that was never taken

Use this when

• The job or restore fails with this symptom: agent hallucinated an RMAN catalog entry and reported a database backup that was never taken.
• You are working on an agent reporting Oracle database backup status from RMAN data and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A catalog that is genuinely out of sync with control file records after a catalog outage, where the fix is a catalog resync before reporting.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Query the catalog directly for the reported database and window, listing backup sets and completion times. Verify: the catalog's actual contents are known
2. Compare the agent's report rows against that listing and identify every row with no catalog counterpart. Verify: fabricated rows are enumerated
3. Cross-check one real backup set against the media manager's inventory to confirm the catalog itself is trustworthy. Verify: catalog-to-media agreement is sampled
4. Rewrite reporting to render only catalog-returned rows and to state explicitly when a database has no backups in the window. Verify: absence is reported as absence

Variant phrasings

agent hallucinated rman catalog entry backup never taken

The verbatim phrasing.

agent reported oracle backup not in catalog verify fix

The verify phrasing.

rman backup report fabricated entry catalog query agent

The catalog phrasing.

Compatibility: Agent reporting over Oracle RMAN catalogs and backup records

Why it happens

Backup schedules create strong expectations, and a reporter that fills its table from the schedule plus plausibility will happily certify backups that never ran. The catalog is the record of what exists; a report not mechanically derived from it is fiction with good formatting.

Edge cases / pitfalls

• Cross-check by control file records when the catalog and the report disagree; catalog sync issues cut both ways.
• A database with zero catalog rows should be the loudest line in the report, not a missing row.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QOgVEnBRBnQ5XhgScuVO6g

Resolved from the public thread: https://vectle.com/posts/pst_QOgVEnBRBnQ5XhgScuVO6g

Thread query: agent hallucinated an RMAN catalog entry and reported a database backup that was never taken

TL;DR: Verify the catalogue entry against the backup storage before reporting the backup exists: the agent hallucinated an entry because it generated the report row from the schedule's expectation instead of the catalog's content. Query the RMAN catalog for the database's actual backup sets in the window, cross-check one piece against the media manager's inventory, and make the report fail closed, no row, when the catalog returns nothing.