Recovery field note
Design the restore before you choose SaaS backup coverage.
Start with what the client needs back, where it must go and who may approve the restore. Use that recovery scenario to evaluate Microsoft 365 and Google Workspace protection.
Practical evaluation guidance. Check current Dayrook scope and evidence.
On this page9 sections
Illustrative decision map · not a product screenshot
Work backward from the recovery result you need.
The selected workload, provider boundary, target, approval, and verification path stay visible before protected data is changed.
- 01Define
- 02Bound
- 03Preflight
- 04Exercise
- 05Evidence
In brief
What to carry into the workflow
- Define recoverability by workload and provider capability instead of treating every SaaS object as equivalent.
- Preflight permissions, target, retention, legal hold, conflicts, and approval before a restore mutates provider data.
- Run drills that prove original, alternate, point-in-time, export, throttling, and denial paths—not only the happy path.
Start with the recovery decision
A backup schedule does not answer the question an MSP faces during an incident: which workload, snapshot, items, destination, and conflict behavior can be restored safely right now? A restore strategy starts with those decisions and works backward into discovery, protection, retention, indexing, and verification.
Dayrook defines workload-specific paths for Microsoft 365 and Google Workspace. Exchange, OneDrive, SharePoint, Teams, Groups, Gmail, Drive, Shared Drives, Calendar, Contacts, and related metadata each inherit the limits of their provider APIs. Those boundaries must remain visible during evaluation and execution.
Make coverage and limitations explicit
For Microsoft 365, protection begins with admin consent, least-privilege scope validation, tenant mapping, daily resource discovery, selection rules, incremental crawl, versioned storage, indexing, integrity verification, and promotion of a restore point only after verification passes.
For Google Workspace, the same operating chain applies to supported Gmail, Drive, Shared Drive, Calendar, Contacts, and Groups data. Modern Google Sites is a documented provider boundary: Dayrook records metadata and version evidence, but must not represent site content as restorable or create a fabricated replacement file.
Preflight every mutation
Before a restore starts, validate provider permissions, target existence, snapshot integrity, storage availability, retention and legal-hold state, billing and entitlement, region, role, and approval policy. High-risk restores should expose item counts, destination, conflicts, and permission changes in a dry run.
Alternate-user, domain, site, team, or shared-drive restores need explicit support from the provider contract. They also require approval, MFA where configured, and an audit record. If the provider cannot roll back a mutation, the product should say so before the operator approves it.
- Bind the job to one tenant, customer, region, source snapshot, actor, target, and idempotency key.
- Verify provider scopes and target availability before reading or writing restore content.
- Choose skip, overwrite, rename, or restore-to-folder only where the provider supports that conflict mode.
- Apply malware or ransomware warnings and isolation choices where the restore path requires them.
- Use short-lived signed downloads and automatic expiry for supported exports.
Design drills around real failure paths
A meaningful restore program includes one-item recovery, a folder or workload subset, an alternate target, a point before and after a deletion event, and a supported export. It also exercises throttling, permission denial, legal-hold blocks, provider limits, and recovery after a worker or network failure.
Drills should be scoped so they do not overwrite production data unintentionally. Use controlled test targets, approved conflict modes, clear abort conditions, and a review step that confirms the restored content and metadata match the selected snapshot.
Original-location restore
Prove a single item and a bounded subset can return to the original supported target with the chosen conflict behavior.
Alternate-target restore
Prove the provider, approval, MFA, destination, and audit path for an alternate supported user, site, drive, or domain.
Point-in-time and export
Select a real snapshot version, verify the result, and prove any signed export URL expires as designed.
Denial and retry
Exercise provider throttling, missing permission, invalid target, retention, and legal-hold outcomes without uncontrolled partial mutation.
Preserve evidence without exposing content
A restore record should include its job identity, actor, region, source snapshot, target, approval state, provider request IDs, restored and skipped counts, and redacted failure reasons. Operational traces can carry job and provider identifiers, but not protected item content, OAuth material, or unrestricted customer data.
The drill closes only after the operator records what was selected, what changed, what was verified, which exceptions remain, and whether the runbook or protection policy needs revision. A green backup job without this recovery evidence is not the same as proven recoverability.
Sources reviewed
Vendor pages can change after the review date above. Open the current source and confirm plan, contract, regional, and product details before purchasing.
Try this in your evaluation
A recovery drill with acceptance evidence
Illustrative scenario · use it to plan a test, not as proof of a result
Fictional drill: select a test restore point and an isolated destination. Obtain overwrite authorization, retrieve the data, check a known file and application behavior, then remove temporary access. An illustrative target of a 24-hour recovery point and a two-hour recovery window is a test objective, not a promise. Record an observed 23-hour-old point and 35-minute retrieval only if your drill actually measures them; a legal hold can preserve an object without making it eligible for a particular restore mode.
Define a successful result
Check these support boundaries
- Files, images, VM and bare-metal recovery
- SaaS content, metadata and excluded objects
- Export, original and alternate restore destinations
- Keys, overwrite approval, region and retrieval timing
Acceptance record
Record requested and observed RPO/RTO, start/end times, retrieval waits, key custody, failed objects, reviewer and cleanup sign-off. Integrity checks, boot tests and application checks are separate results.
Limits to resolve
No workload-by-mode production matrix is established by this illustration. Protected-user and retained-storage charges can apply; retrieval/egress treatment and archive timing need written confirmation.
Questions, answered
Questions to resolve before your next step.
Why test alternate restores?
The original identity or destination may be deleted, compromised, or unsuitable during an incident.
Should every workload use the same retention?
Not necessarily. Business, legal, regulatory, cost, and provider considerations can require different policies.
Does a backup replace provider retention features?
No single mechanism answers every recovery and preservation need; responsibilities should be evaluated by workload and scenario.