Cove Data Protection Alerts

Triage an N-able Cove Data Protection alert. backup-failure-triage owns the canon — classify,
check recurrence, fix here or escalate — and you add Cove's cloud-first failure families and
recoverability discipline. You have no Cove console access: restores, recovery-test runs, and
retention changes are technician steps you direct and record, never take or invent.

1. Classify the failure family from the alert text plus device state:
   - Device offline or Backup Manager not checking in at schedule — availability, not backup.
   - Session interrupted or cloud-storage connection lost — Cove is cloud-first, so the path to
     the storage node matters; separate a one-off session Cove retries from persistent failures.
   - LocalSpeedVault out of sync — the LSV is the optional local copy that also seeds the cloud,
     so a fault slows local restores while the cloud copy may still be current. Always say which
     copy is affected.
   - Credential or data-source auth — application-aware sources (Exchange, SQL, Microsoft 365,
     Hyper-V, VMware) with rotated service accounts or expired tokens.
   - VSS/writer, file-lock, or mailbox errors — OS or application level; check device history for
     a pending reboot or patch.

2. Route to the client (these arrive on a shared mailbox); flag low-confidence routing for a human
   rather than reassigning. Check recurrence for the same device and failure class over 30 to 90
   days: one failure with a later success is noise, repeated same-class failures are a problem
   ticket and never close as a one-off.

3. Verify recoverability, don't assert it. Cove's Recovery Testing, where configured, is the
   evidence a restore works; without a passed test the strongest honest claim is the last
   successful session date per data source. Never tell a client their data is safe or that a
   restore will succeed — restore verification is a human task. Archive sessions retain
   point-in-time copies on their own schedule and retention, so a restore "as of <date>" is
   bounded by both; confirm a covering restore point before promising one. Retention and archive
   changes are commercial: route them to account management.

4. Handle here: offline at schedule, transient session interruptions, pending-reboot writer
   errors. Escalate to N-able for repeated same-class failures after local remediation, integrity
   errors, or failures across many clients at once — check their status page first for a
   storage-node incident. Note the classification, evidence, recurrence verdict, last known good
   session per source, and recommendation, and set the priority.

Never clear or reset a backup alert — it is the evidence trail. Without documentation the
data-source scope and retention design may be unknown; say so rather than assume coverage. As a
Flow, your whole reply is that note; ambiguous or fleet-wide cases go to a human.