In-Place Restore: SharePoint & OneDrive

What in-place restore does

An in-place restore takes a single backed-up file and uploads it back into the drive it came from, at the folder path it originally lived in.

You start the restore from BYOVault’s dashboard by picking the file and the version you want. BYOVault confirms the file belongs to your tenant and that it’s a SharePoint or OneDrive item, then queues the restore and hands you back a job you can track.

The dashboard updates as the job progresses rather than making you wait on a single request, since downloading, decrypting, and re-uploading a large file can take longer than a typical web request allows.

Restoring to the original path

Every backed-up file remembers which drive and folder it came from. Because that information travels with the backup itself, an in-place restore doesn’t require you to tell BYOVault where the file should go — it derives the destination drive and folder automatically, then resolves that folder path against the live drive one folder at a time.

• Folder missing: if a folder along the way can’t be found — because the original folder was renamed, moved, or deleted since the file was backed up — BYOVault creates it and continues. A restore never fails merely because the destination folder no longer exists; the folder structure is recreated as needed, down to the exact original path.
• Name conflict: if a restore lands on a file name that already exists in the destination folder, the restored file overwrites it rather than creating a duplicate alongside it.

Restoring a specific version, not just the latest

BYOVault keeps every backed-up version of a file, so restoring an older version is just a matter of picking that version instead of the most recent one when you start the restore. There is no special “latest” behavior — every version is restored the same way.

The version to restore is chosen in the version browser described in Version History, which lists every stored version of an item.

Decryption and integrity

Before upload, BYOVault downloads the backed-up file, decrypts it, and verifies the decrypted content against the checksum recorded at backup time.

• Checksum mismatch: the restore fails rather than uploading corrupted or tampered content.
• Locked retention storage: a file that has moved into locked retention storage is restored from there automatically — you don’t need to do anything differently.
• Customer-managed keys: a tenant using a customer-managed key has that specific file’s key unwrapped correctly even if the tenant’s key configuration has changed since the file was backed up. See Customer-Managed Keys (BYOK) for how key wrapping works.

Strictly per-file

There is no bulk or whole-drive restore operation. Each restore request covers exactly one file. Restoring many files means submitting many individual restore requests.

See Restore Limitations for what this means in practice for a large-scale recovery.

Permissions required

In-place restore requires the Files.ReadWrite.All Microsoft Graph application permission, granted in the customer’s tenant at connection time alongside every other permission BYOVault will ever use.

Nothing is requested separately or for the first time when a restore actually runs. See Restore Permissions & Scopes for the full permission table and what the grant does and does not cover.

Job outcome

• A completed restore records the name, location, and a link to the restored file, along with the folder it was restored into — shown as the drive root when the file lived there.
• A failed restore records the error message directly, rather than leaving the job stuck in a running state, and triggers the same restore-completion notification as a success, marked as failed.
• Every restore request — whether it goes on to succeed or fail — is written to the audit log at submission time, capturing which file was restored and the email address of whoever started it.