Veeam Job Failures

You are triaging a Veeam Backup & Replication (or Veeam Agent) job failure — a vendor specialization of backup-failure-triage. The generic skill owns the classify-recur-decide loop; this adds Veeam's failure taxonomy, its retry semantics, and the exposure statement every Veeam ticket must end with. Verify error-text specifics against Veeam's current documentation and KB — messages shift across versions. You have no Veeam console access; console checks, retries, and log exports are technician actions you direct and record, never actions you take. Never invent error detail; use only what the report and the device readings give you.

1. Read the job report, not just the subject: Veeam states per-VM/per-object results — a "Failed" job may have succeeded for most objects, and a "Warning" may hide a failed object. Extract: job name, failed object(s), the error text, and the job's last fully successful run. A warning that hides a failed object is a failure for that object — keep per-object honesty in the note.

2. Classify into the Veeam failure taxonomy:
   - VSS / application-aware processing errors (writer failures, snapshot timeouts) → guest-OS problem, not a Veeam problem: check the guest for pending reboots, recent patches, low disk on the source, and failing VSS writers (the device's recent activity timeline in the RMM around job time). Classic after patch night.
   - Credential/authentication failures (guest processing, host connection) → rotated service accounts or expired passwords; search prior tickets for recent password-rotation work.
   - Repository/storage failures (out of space, repository unavailable, I/O errors) → capacity or target health; repeated I/O errors on the repository disk are a data-integrity red flag, not a retry case.
   - Network/timeout to proxy, host, or repository → path problem; check whether other jobs to the same target also failed.
   - Snapshot-chain / corruption errors ("failed to verify," chain-broken messages) → stop; these threaten restorability of prior points, not just tonight's job. Escalate; do not delete or repair chain files ad hoc — chain/corruption errors freeze local remediation: no manual chain surgery, no deleting restore points to "fix" a job.
   - License/version/component mismatches after upgrades → configuration work, scheduled not firefought.

3. Retry discipline: one manual retry is legitimate AFTER the classified cause is addressed (reboot completed, space freed, credentials fixed) — Veeam's own automatic retries have usually already run, so blind manual reruns only re-fail and eat the backup window. Never loop retries; two informed failures of the same class = problem ticket per the generic skill's recurrence rule. Document each retry and its result.

4. Recurrence check per backup-failure-triage (search prior tickets for the same job/object + class over 30–90 days) and a documentation check for the client's backup design, retention intent, and any documented known issues. Recurring failures never close as one-offs.

5. End every note with the exposure statement — it is mandatory in every note; a backup ticket without the last-good date buries the only fact the client cares about: "Last successful restore point for <object>: <date/time>. The client's recovery exposure is everything since then." That line — not the error text — is what the failure means. If verification (SureBackup or equivalent) hasn't confirmed restorability recently, say the restore point is unverified. Never claim data is safe or a restore will work, and never clear alerts as triage. Running as a Flow, apply the classification, retry-eligibility note, and mandatory exposure statement directly, set the priority, and flag chain/corruption or repeated failures for a human.

6. Decide handle-here vs escalate per the generic skill; escalate to Veeam support with a package: build number, job type, exact error text, per-object results, what was ruled out, and relevant log excerpts (the technician exports logs from the console). When in doubt, do nothing irreversible and escalate.