ShareMaster V2 is in beta, a complete rebuild. See what is new and request access →
Features All features overview
Migration Tools Overview Structure and content OneDrive ↔ SharePoint Content only Structure only Move / Copy Upload from this computer Download to this computer Dropbox to SharePoint Resume and incremental runs
Recycling Bin Overview Browse a site's recycle bin Empty recycle bins in bulk Restore and purge history
Archive Overview Configure the tenant On Demand Archive Restore Archived Files Archive Savings Report Blob Viewer
Optimise Storage Tools Overview Delete all items in a list Delete all files and folders in a library Remove empty folders Remove duplicate files Reduce image sizes Delete sites and subsites
SharePoint Tools Overview Tenant Explorer SharePoint Explorer Easy Settings Fix renamed groups List Explorer Search the Preservation Hold Library
Replace Overview Replace in SharePoint Replace in local files Find password-protected files
Shared Links Overview Report shared links Report unique permissions Remove a person from sharing links Remove shared links Remove unique permissions
Version History Overview Version trimming Version trimming report Reset file version
Reports Overview Inventory report Folder inventory Site and subsite storage Security matrix Teams permissions Pre-migration analysis Compare items Dropbox to Microsoft 365 compare Duplicate file report Empty folder report Image size report Recycle bin report Unused licences Report history
V2 beta Pricing Demos Blog Guides Use cases Compare Tools Alerts FAQ Contact Sign in Start free trial
  1. Home
  2. Documentation
  3. Archive

How a file is archived without risking it

The order, and the line no failure crosses

Archiving replaces a document with a pointer. If the pointer were written before the bytes were known to be safe elsewhere, a failure at the wrong moment would destroy the only copy - and it would look exactly like a success. So the order is fixed, and it is checked rather than trusted to careful coding.

Reads only. Nothing in SharePoint is changed.

What it tells you

  • Everything up to and including VERIFY is reversible: the SharePoint file is untouched, and an orphaned copy in your storage costs pennies and can be swept up.
  • Verification reads the archived copy BACK and re-hashes it. 'The upload returned success' and 'the bytes are correct and retrievable' are different claims, and only the second one justifies replacing a file.
  • Only after that does anything in SharePoint change.
  • Each file is its own transaction. A failure on one file leaves that file whole and moves on; it does not abandon the run or half-convert anything.
  • The archived copy is named after a hash of its contents, so re-running after a failure reuses the copy already uploaded instead of making a second one.

How it runs

  1. 1. Read. The file's bytes and its hash are read from SharePoint. Nothing has changed.
  2. 2. Upload. The bytes go from this computer straight to your Azure storage account, on your own sign-in. No account key exists on an archive account, and nothing is routed through ShareMaster.
  3. 3. Verify - the line. The copy is read back and re-hashed. If it does not match, byte for byte, the run stops on that file and says so, and SharePoint is left exactly as it was.
  4. 4. Rename. Only now. The SharePoint file is renamed in place to the placeholder name, which keeps its identity, its history and its permissions.
  5. 5. Replace. Its contents become the placeholder - a pointer, and never a credential.
  6. 6. Re-stamp. Authorship is put back, so the file's Created By and Modified By still say who they said before. An archive that rewrote authorship would corrupt the record it was meant to preserve.

What it will not do

  • A file changed between the report and the archive is re-checked and skipped rather than overwritten.
  • Version history is not moved. A placeholder keeps the file's versions in SharePoint, so a file with a very large history reclaims less than its current size suggests.

See every feature