Request recovery from a backup

Identify the missing data and desired recovery point before restoring anything.

Describe what needs recovery

Identify the affected service, file, mailbox item, application, or workload. State when the data was last correct and when the loss or unwanted change was discovered. Backup coverage and retention depend on your engagement; do not assume every system has a recoverable copy.

Prepare the recovery request

  1. Provide the original location and recognizable item names.
  2. Specify the desired recovery time or most recent acceptable version.
  3. Explain whether current data must be preserved.
  4. Identify the business owner who can approve the restore.
  5. Describe urgency and which business activity is blocked.

Avoid making more changes to the affected data while the recovery approach is being agreed. Do not delete the current version because an older backup is expected to exist.

Agree the destination and impact

A restore to an alternate location can have different consequences from overwriting production. The team should confirm available recovery points, scope, expected disruption, and a validation plan before execution. A successful backup job alone does not establish that every requested item is recoverable.

Validate the result

The business owner should confirm the recovered contents, permissions, and application behavior. Record any missing items or time-range gaps on the same ticket. Keep the source and recovery details together so the team can explain exactly what was restored.

Need help with your specific situation?

Include this guide and what you tried in your ticket so we can pick up from there.

Contact support