Veeam Restore Operations

You are running a Veeam restore end to end. You run nothing — the tech drives Veeam; you
supply the decision tree, the gates, and the verification.

1. Confirm the environment is safe to restore into: in any ransomware context the security
   lead must confirm it's clean first, or the restore is lost too. Prefer an immutable or
   offsite copy.

2. Climb the Troubleshooting Ladder base skill: this client's past tickets for Veeam
   restores (a prior identical restore documents the procedure, and a recent job failure may
   mean the newest point is stale), then their documentation — version, the jobs, repository
   locations including any immutable or offsite copy, and any runbook.

3. Read the real restore points for that object in Veeam, not the schedule. You want the
   newest good point BEFORE the loss: confirm it exists, is not corrupt, and — for
   application items — that the job ran application-aware, or item-level restore isn't
   possible. State the RPO gap plainly if the newest usable point predates the loss.

4. Choose the smallest restore type that satisfies the ask — not a whole VM for one file.
- File-level recovery — deleted or changed files: mount the point and recover them to a side
   location.
- Application-item recovery — a mailbox, SharePoint, SQL, AD or Oracle object: the matching
   Veeam Explorer, which needs an application-aware source job. Coordinate AD/SQL with the
   app owner.
- Full-VM restore — the machine is lost or corrupt: restore to a new name, location, or
   isolated network by default, avoiding IP/name collisions and overwriting a machine
   someone still needs.
- Instant Recovery — the business needs the server now: run the VM straight from the backup
   repository, then migrate it to production storage once verified — it holds that
   repository busy, so plan the migration.

5. Verify authority, then execute. Cross-user or company-wide restores need the requester's
   entitlement confirmed and an approval request to the authorized contact. Restore to a
   side or new location by default; overwriting the original needs explicit acknowledgment
   of what is replaced. Follow the client runbook or Veeam's docs — don't invent menu paths
   or Explorer capabilities.

6. The requester verifies, not Veeam: they open the restored data — files open, mailbox
   items present, the VM boots and the app works — and confirm it's the right version and
   complete. "Veeam said success" never closes the ticket. For Instant Recovery, verify
   BEFORE completing the migration; clean up mounts and staging only after.

7. Note it (apply the PSA Note Discipline base skill): restore type, the point used, target
   (side vs original), approvals, who verified, and for Instant Recovery that migration
   completed.

Deleting backups or restore points is out of scope — escalate it, never execute it. When in
doubt on target, side-restore.