Clarify a Client Restore Request Before a Technician Starts Recovering Data

“Please restore yesterday's backup” is one of the most dangerous vague requests a managed service provider can receive. A client may be missing a spreadsheet, need a mailbox message, require an application record recovered, or want an entire server rolled back to an earlier point. Those interventions have different privacy, timing and disruption consequences. Starting a broad recovery because a technician has access to the backup console may overwrite legitimate current work without even retrieving the information the user meant. Controlled intake establishes the exact business outcome, authorised requester, available recovery point and safe destination before any restore starts.

A small MSP does not need to turn every initial conversation into a formal disaster-recovery exercise. It does need a repeatable boundary between service-desk clarification and privileged technical action. The process below covers file, mailbox, application and larger system restores, but the correct implementation depends on the client's contractual arrangements and the actual backup product. It distinguishes restoring historic data from investigating whether a backup job completed; a green backup dashboard is not proof that any particular item can be retrieved intact.

Translate the request into one recoverable business object

Ask what the client cannot currently do and identify the affected file, folder, mailbox, database record or service. A request for a deleted spreadsheet is not necessarily a request to restore the file server. Capture exact location, application, relevant user and stable references where available. Avoid using a common display name as the only identifier, since similar documents can exist in different client tenants or shared locations.

Describe what successful recovery would allow the user to do. They might need to compare two previous versions, retrieve one attachment or reopen an archived business transaction. This helps a technician choose the least disruptive supported route and prevents an unnecessary whole-system rollback.

Establish the desired point in time honestly

Ask when the information was last correct and when the unwanted change was first noticed. The user may provide a range rather than a precise timestamp. Record that uncertainty; do not turn “last Tuesday afternoon” into an invented exact recovery point. Consider timezones, application schedules and overnight jobs where relevant. A backup taken after the mistake may already contain the unwanted change.

The engineer must check actual available versions or snapshots and explain what each represents. Backup retention is often based on configured policies, not a promise that every minute of earlier data remains recoverable. If the requested point is unavailable, report the limitation and explore approved alternatives instead of declaring a successful restore from a different point without consent.

Check entitlement and authorisation separately

A user who can report a deleted document is not automatically entitled to receive another employee's mailbox or confidential historical records. Verify requester identity and the authority of the client data owner under the service agreement. Where sensitive information or an overwrite is involved, obtain the appropriate explicit approval. For former employee data, legal hold or privacy rules may also apply; the MSP should not infer permission from a helpdesk ticket alone.

Record who approved the source, destination and disclosure. Avoid including recovered private content or administrative credentials in widely accessible ticket comments. Use restricted evidence references and the client's established data-access process.

Distinguish the available recovery mechanisms

Version history, recycle bins, snapshot recovery, backup restoration and application-specific repair may all serve different purposes. Use a supported low-impact recovery when it can meet the objective. For example, a previous document version may be retrievable without replacing an entire shared folder. Conversely, some enterprise databases need coordinated application-consistent recovery, not a simple file copy.

Microsoft's published OneDrive and SharePoint versioning guidance explains a particular provider's historic file-version options, while NCSC backup guidance emphasises testing recoverability. These references are useful examples, not evidence the client uses those products or that every record has a retained version.

Verify the backup really contains the required data

Review actual job history, backup scope, retention policy and restore catalogue. A last successful backup status may refer to a different volume, site or dataset. Confirm that the intended object and point are included and that the backup can be read through the authorised method. If encryption keys or specialist supplier access are required, identify that dependency before promising an outcome.

Where the evidence remains incomplete, mark the request as awaiting confirmation rather than estimating recovery from an attractive dashboard. If a backup is corrupted or inaccessible, escalate through the appropriate incident and recovery procedures instead of trying unsafe shortcuts.

Assess what current work could be lost

Restoring older data into a live destination can overwrite genuine later edits or disrupt dependent application records. Ask which employees and integrations have changed the affected information since the requested recovery point. Compare the consequences of a replacement with a side-by-side restore for review. Where supported, an alternate destination can preserve the latest production copy while the user examines historical content.

For transactional databases, a point-in-time state may depend on external payments, queue events or other systems that have progressed. A restore of one component can create an inconsistent business position. Require a competent owner to assess these dependencies before any broad or destructive action.

Select a safe destination and handling model

Identify whether recovered information should go back to its original location, a restricted temporary review area or an approved separate environment. Confirm storage and access rights for the recipient. A technician should not send an entire recovered archive by personal email to satisfy a request for one report. If staging data includes personal information, observe the client's authorised data-processing controls.

Keep the destination and disposal plan in the ticket. Temporary recovery copies can become a forgotten source of sensitive information when nobody is assigned to remove them. Where an isolated test environment is needed, confirm it has appropriate safeguards before uploading production data.

Check ongoing operations before execution

Determine whether other restores, sync processes, user edits or system incidents are in progress. A concurrent recovery may change the target while a technician is working. Coordinate maintenance windows and business notifications where the operation may affect a shared service. The existence of a restore button is not authority to interrupt current processing.

Document the actual source and target identifiers, backup point, expected overwrite behaviour and verification criteria before submitting the job. For material changes, follow the client's technical review and recovery plan. A broad rollback may not be fully reversible once new transactions have occurred, so avoid promises that undo will be effortless.

Implement through an authorised and observable route

Use approved backup tooling and named operator permissions. Record whether the restore job was requested, accepted, running, finished or failed. Do not equate a queue acknowledgement with recovered data that is already usable. Preserve the audit reference and errors without copying confidential payloads into ordinary support tickets.

If a job times out, inspect the backup system before retrying. It may still be running or may have completed after losing the client connection. Repeated submissions can cause conflicting restores or unnecessary service disruption.

Verify content and user access after recovery

Check the recovered object or application state through a safe, permitted method. Confirm it opens or functions, that required related records are present and that its permissions suit the authorised recipient. An engineer can establish technical completion while a business owner must often decide whether the recovered version is actually correct for the intended task.

Record which tests occurred and which were not possible. A successful restore log is not proof that an attachment contains the expected data, a database is transactionally consistent or the user can resume their work. Keep unresolved exceptions assigned rather than marking the entire business outcome complete.

Protect recovered content and preserve traceability

Link the approval, source backup, point in time, target, operator and verified outcome in the controlled service record. Do not paste private documents into tickets to demonstrate success. Follow retention requirements for temporary recovered copies, access rights and relevant audit information. Where a legal or security hold applies, use its proper process before deletion.

Keep the original failed request and decision history understandable. If the user decides not to apply the recovered version, record the no-change outcome rather than rewriting the ticket as a completed production overwrite.

Keep prevention and backup assurance separate

A data loss might originate from accidental deletion, broken synchronisation, ransomware or a software defect. Assign root-cause and prevention work under the appropriate incident or problem process. One successful restore does not prove all backups will work next time, just as a backup alert does not prove the requested object was recoverable. Review recurring requests for training gaps, insufficient version history or inappropriate restore granularity.

Close the support case when the authorised requester receives the needed usable information, or when the actual limitations and alternative decisions are explicitly documented. A precise intake reduces avoidable overwrites, makes escalation easier and helps the MSP prove what was recovered without overstating the capability of its backup platform.

Relevant primary guidance: UK NCSC ransomware and recovery guidance (backup recovery and validation context) and Microsoft Support, restore previous OneDrive file versions (product-specific recovery scope). The client's actual contract and backup evidence govern the action.