Restoring Offloaded Files
When Content Governance offloads a file, it moves the file’s actual content (the binary data) out to low-cost blob storage — either Azure Blob Storage or an AWS S3 bucket — and leaves a lightweight proxy (a stub) in its place. The proxy keeps the filename, the metadata, the full version history, and a pointer back to the binary in blob storage. The file still appears where users expect it, but it no longer occupies primary storage.
Restore is how you bring that content back — and it is important to understand that a Content Governance restore is not a traditional file restore.
Restore is a reconstruction, not a copy-back
A traditional backup tool simply copies an old file back to where it used to live. Content Governance does something different. On restore, Content Governance reads the binary content from blob storage and reconstructs the complete file from the proxy — rebuilding it with its full version history and all of its metadata intact. The result is a true, working file again, not a flattened copy.
Because the file is reconstructed rather than moved back, the restore target is simply a parameter. This makes two very different restore operations possible from exactly the same engine.
The two restore modes
| Mode | What happens |
|---|---|
| In place | The original proxy/stub is overwritten. The binary is pulled from blob storage and the file is fully reconstructed exactly where it was offloaded from. |
| To a different location | Content Governance reads the proxy to obtain the filename and metadata, then reconstructs the complete file — with version history and metadata — at a new destination of your choosing. |
Why restoring to a different location matters
Restoring a file straight back to where it was archived feels like the obvious choice. In practice it is the wrong choice in the large majority of cases.
Archives live for years. Over that time:
- Many of the people who originally had access to the files have left the organization or moved to other roles.
- The people who now need the content have completely different security profiles, and in most cases should not be granted access to old archives full of unrelated material.
Restoring in place re-establishes the file under its original — and now outdated — access model. Restoring to a different location avoids this entirely: the reconstructed file lands under the target location’s permission model, so the right people get access and stale permissions are never reinstated. You are not scrubbing old rights off a recovered file; you are recreating a clean file in the right place.
Summary
- Offload moves binary content to Azure Blob Storage or AWS S3 and leaves a lightweight proxy with filename, metadata, version history, and a blob pointer.
- Restore reconstructs the full file from blob storage — version history and metadata included — rather than copying a backup back.
- You can restore in place (overwrite the original proxy) or to a different location (recreate the file wherever you choose).
- Because restore is a reconstruction, the location is just a parameter — which is what makes redirect-restore native to Content Governance rather than an add-on.
The ability to reconstruct an offloaded file at a different location — under the correct, current permission model — is a core strength of SMART Migration, and is exactly what traditional archive and HSM tooling cannot match.