> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cove Data Protection Alerts

> Work N-able Cove Data Protection backup tickets: classify the failure family, verify recoverability, and keep archive and retention sessions straight.

<Info>
  **Category:** Vendor Runbooks · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/vendor-runbooks/cove-data-protection/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="agent"><span className="thread-chip thread-chip-tier-agent">Agent</span><span className="thread-chip thread-chip-beta">Beta</span></span> — a Flow can run it unattended on a matching ticket event — or you can run it yourself in Super Magic while you prove it out.

**Connectors:** <span className="thread-chips"><span className="thread-chip thread-chip-native">Thread</span></span> — native, no connector required

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Always-On Coverage, Risk & Compliance

**When to use:** A Cove backup failure, "backup did not run", or session-error alert lands as a ticket; someone asks whether a device or data set is actually recoverable from Cove; or a retention/archive question or storage/LocalSpeedVault issue needs a decision.

**Run it:** on the alert ticket · or as a Flow (triggered when a matching Cove backup alert ticket is created).

## Prompt

```
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.
```


## Related topics

- [AV/EDR Agent Offline Alert](/skill-library/alert-runbooks/av-edr-agent-offline.md)
- [Acronis Cyber Protect](/skill-library/vendor-runbooks/acronis-cyber-protect.md)
- [Synology NAS Alerts](/skill-library/vendor-runbooks/synology-nas-alerts.md)