Datto BCDR Verification

Work a Datto BCDR ticket (SIRIS/ALTO appliances plus cloud replication) — the vendor
specialization of backup-failure-triage, which owns the classify-recur-decide loop. Keep
three states separate: taken locally, replicated off-site, verified bootable — the client is
only as protected as the weakest. Appliance checks and test virtualizations are technician
actions you direct and record; verify feature names against Datto's docs.

1. Establish the recovery position first: last successful local point, last off-site sync,
   last passed screenshot verification.

2. Screenshot-verification failure → "won't boot" or "couldn't check"? A hung boot screen,
   blue screen, or OS error in the screenshot points at bootability: pending updates
   mid-boot, boot-volume driver changes, corrupt system state. A timeout or resource failure
   on the appliance points at the check, not the backup. Corroborate with recent patches or
   disk changes (RMM activity timeline) and prior alert history. Boot-level
   evidence → "restore in doubt": escalate for a manual test virtualization in an isolated
   network, not the next automatic check; never close a server on a later
   automatic pass alone. A one-off appliance timeout with a successful next run is
   note-and-monitor.

3. Local versus cloud lag is the site-loss question: only synced off-site points survive
   fire, theft, or ransomware reaching the appliance. Never say the client can recover from
   site loss without checking the off-site position. Quantify the lag ("cloud is N hours
   behind local") and classify the cause per backup-failure-triage: bandwidth saturation,
   large change rate, appliance storage pressure, or a service-side issue. Persistent lag
   growth is a design problem — problem ticket, not serial closes.

4. Screenshot checks are shallow. Check the client's documented DR expectations and the last
   full test virtualization; nothing within the expected cadence → flag it with
   dates to service leadership and account management. Never schedule a client-facing DR
   test unilaterally.

5. End every note with those three dates, explicitly. "Backup succeeded" never implies
   "backup boots" — bootability needs a passed verification or a manual test, and the note
   says which. Plain text, no markdown or emojis (apply the PSA Note Discipline base skill).
   As a Flow, apply that note and priority directly and flag boot-failure or DR-cadence
   findings for a human.

Handle here or escalate per backup-failure-triage; the Datto support package is appliance
serial and model, agent and OS versions, the screenshot or error, sync statistics, and what
was ruled out. Never recommend deleting recovery points as cleanup; retention changes
follow the client's documented design. Generic guardrails hold: no data-safety claims,
alerts are the evidence trail, recurring failures get problem tickets.