Client Support Retainer Accidental Data Loss & Backup Restore Pack (With AI)

When a retainer client reports missing files, an empty folder, or “we deleted the wrong thing,” you are not running a security breach playbook—you are running a backup restore playbook. The goal is to verify what was lost, pick the right recovery point, restore the smallest safe scope, prove integrity, and keep written client updates while billable hours stay defensible.

This pack fits active support retainers where you already have channel rules, an hour bank, and escalation paths. It complements urgent P1 and credential-compromise guides: here the service may still be up, but data is wrong or gone.

When to use this pack

Use it when the client believes data was accidentally deleted, overwritten, or corrupted—not when you suspect stolen credentials or active attacker access. If phishing or rogue sessions are in play, switch to your security-incident pack first, then return here only after access is clean.

Typical triggers:

• “Someone emptied the Recycle Bin / Trash.”
• “We migrated folders and the old path is gone.”
• “The spreadsheet from Tuesday is blank.”
• “Restore from backup” is mentioned without a written scope.

What you need before you start

Gather facts before touching production backups:

• System of record (Microsoft 365, Google Workspace, NAS, SaaS export, database backup vendor).
• Last known good time (meeting, email, file version history screenshot).
• Scope (one user, one shared drive, one database, whole tenant—push back on “restore everything” until scoped).
• Retention policy (how far back backups go; legal hold if any).
• Change freeze agreement (no migrations while restore is in flight).

If no backup exists, say so in writing early. This pack does not invent backups—it documents options and next steps.

End-to-end flow

Step 1 — FACT/ASSUMPTION snapshot (ChatGPT)

Paste a redacted ticket thread into ChatGPT. Ask for labeled facts vs assumptions and a restore-risk note.

Prompt (copy-ready):

You are an MSP-style support lead. Read the ticket below.

Output:
1) FACTS (only what is explicitly stated)
2) ASSUMPTIONS (label each; mark what to verify)
3) Likely data loss type: deletion / overwrite / corruption / unknown
4) Questions to ask the client before any restore (max 8)
5) Risk if we restore too wide a scope (1 short paragraph)

Do not invent backup product names. Do not claim restore success.

Ticket:
[PASTE REDACTED THREAD]

Save the output into your working notes. You will reuse FACTS in the client-facing brief.

Step 2 — One-page Data Restore Brief (Google Docs)

Create a Google Doc titled Data Restore Brief — [Client] — [YYYY-MM-DD]. Share view-only with the client contact when you send the first status email.

Sections (keep to one page):

1. Summary — what the client reported, in plain language.
2. Scope table — paths, sites, mailboxes, DB names, user count affected.
3. Recovery point target — date/time timezone + why (last known good).
4. Backup source — product, job name, retention, who can run restore.
5. Restore method — granular (file/version) vs full snapshot; expected duration band.
6. Change freeze — what pauses until verification passes.
7. Hour policy — retainer burn vs change request if scope expands.
8. Verification checklist — see Step 6 (copy into doc).
9. Approvals — name + date line for “proceed with scoped restore.”

Step 3 — Verify backup before promising recovery

Checklist you execute (or assign) before the client gets a time estimate:

• Confirm backup job succeeded for the recovery window.
• Confirm retention covers the target date.
• Identify granular restore option (version history, recycle bin, SaaS point-in-time).
• Identify blast radius if full snapshot restore is required.
• Capture screenshot or export of backup console status (internal only).

If verification fails, update the brief with Options A/B/C (partial manual rebuild, vendor ticket, paid CR for re-architecture). Do not leave the client on “we’re working on it” without a written branch.

Step 4 — Scoped restore execution

Rules that protect you and the client:

• Restore the smallest unit that fixes the reported loss (single library, mailbox, table, bucket prefix).
• Prefer non-destructive paths: restore to a _RESTORE_[date] folder or staging site first when the platform allows.
• Document exact commands or console clicks in the brief appendix (internal section).
• If overwrite is unavoidable, get written approval referencing the brief section 9.

When restore completes, do not close the ticket—move to verification.

Step 5 — Gmail status sequence (three emails)

Use the same subject stem: [Client] Data restore — [date].

Email 1 — Acknowledge + scope lock

• Restate FACTS from the brief summary.
• List what you are verifying (backups, scope).
• Ask for missing items: last known good time, exact paths, approver name.
• Link or attach the Google Doc brief (view access).

Email 2 — Plan or blocker

• If verified: recovery point, method, change freeze, ETA band.
• If blocked: which option A/B/C you recommend and hour impact.
• Explicit ask: reply “Approved” on section 9 to proceed.

Email 3 — Outcome

• What was restored, where it lives (paths), what was not restored.
• Verification results (sample files, row counts, checksum spot-check).
• Residual risks (sync delays, partial data).
• Next step: client sign-off or follow-up CR for gaps.

Keep tone factual. This sequence mirrors your P1 updates but avoids outage language when systems are online.

Step 6 — Post-restore verification checklist

Client-visible checklist in the brief; you tick each item:

• Sample files open and match expected modified dates.
• Row/record counts within agreed tolerance (if database).
• Permissions correct on restored objects (no accidental public share).
• Sync clients re-indexed (OneDrive/Drive/desktop agents).
• No duplicate naming collision broke automations.
• Client contact confirms business-critical items present.

Attach evidence sparingly (screenshots with redaction). Store internals in your PSA, not in the client email body.

Step 7 — Log a row in the monthly retainer review

Add one line to your retainer review export:

Month	Theme	Data restore?	Root cause class	Preventive action
YYYY-MM	Accidental deletion	Y	user error / migration / vendor	training, backup test, versioning policy

This connects restore work to recurring review cadence so the same client does not hit the same gap every quarter.

Related playbooks on DoAIWork

Browse more step-by-step guides in the Guides category. If the incident involved credentials or phishing, use the security-incident retainer pack instead of this restore pack. For live outages, use the urgent P1 pack first, then RCA after stability.

Bottom line

Accidental data loss on a retainer is a scope, backup, and proof problem—not a heroics problem. ChatGPT separates facts from guesses, Google Docs holds the written scope and approvals, and Gmail carries the status cadence clients can forward internally. Verify backups before you promise recovery, restore the smallest safe slice, prove integrity, and log the lesson in the monthly review.