software:squirrel:version_history []

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== 📚 Version History (Archived and Restored Files) =====

This page explains how **version history is handled by Squirrel** when files are archived and later restored back into SharePoint.

It is intended to explain how historical versions, authorship, and timestamps behave during the archive and rehydration lifecycle.

----

==== 🎯 Overview ====

When Squirrel archives a file, the file and its available SharePoint versions are stored securely in Azure Blob Storage. When a file is restored, Squirrel rebuilds the version chain in SharePoint so that the file can continue to function as a normal SharePoint document.

The restore process is designed to preserve version history and associated metadata as closely as possible, while operating within the constraints of Microsoft 365 and SharePoint’s versioning model.

----

==== ⚙️ How Version History Is Restored ====

During a restore, Squirrel performs the following high-level actions related to versions:

  * Archived versions are retrieved from Azure Blob Storage.
  * SharePoint version entries are recreated.
  * File content is written back into SharePoint.
  * Version-level metadata such as author and modified timestamps are applied where supported.

----

==== 🗂️ Metadata and Authorship ====

Version history in SharePoint is metadata stamped onto each version of a file.

During restore, Squirrel attempts to apply:

  * Version authors
  * Modified timestamps
  * Version ordering
  * File-level metadata

Where the original user account exists in Microsoft Entra ID and can be resolved, SharePoint will normally display the original author information. If SharePoint cannot resolve the account, it may automatically fall back to a system identity.

Because this behaviour is ultimately controlled by Microsoft 365, exact stamping results may vary in some environments.

----

==== 🕒 Timestamps, Dates, and Timezones ====

During restore, Squirrel attempts to apply original created and modified timestamps back onto files and versions where supported.

Because SharePoint and Microsoft 365 store and display timestamps using internal UTC values and tenant or user locale settings, administrators may observe minor differences in how dates and times appear before and after a restore.

These differences can include:

  * Time values appearing shifted due to timezone or regional settings.
  * Display formatting differences in SharePoint views or version history.
  * System-generated timestamps associated with the restore operation itself.

The restore process does not rewrite historical events, but timestamp presentation and final write operations remain subject to Microsoft 365 platform behaviour.

----

==== 🏷️ SharePoint Metadata Capture ====

In addition to version history, Squirrel is designed to capture and restore SharePoint file metadata where supported by the platform.

This includes both standard and custom library columns. During archive and restore, Squirrel attempts to preserve values for commonly used SharePoint field types, including:

  * Single line of text  
  * Multiple lines of text  
  * Choice  
  * Number  
  * Date and Time  
  * Person or Group  
  * Currency  

Because SharePoint allows a wide variety of custom column types and configurations, not all field types are technically supported for full fidelity capture and restore. Certain complex or special-purpose fields (for example images, maps, or some highly customized field types) may not be fully captured or rehydrated.

The objective of the Squirrel metadata process is to preserve business-relevant metadata wherever technically possible, while operating within Microsoft 365 and SharePoint platform constraints.

----

==== 🧩 Minor Versions and Why History May Appear to Shift ====

SharePoint supports both **major** and **minor** versions. Minor versions are often hidden in the user interface, but they still exist internally.

The following occurs during restore:

  * SharePoint rebuilds the historical version chain.
  * The previously hidden final minor version becomes visible.
  * SharePoint writes the restored file back as a new current version on top.

This results in:

  * A new visible top version representing the restored file.
  * The previously hidden minor version appearing directly below it.

This can make it look as though version numbers or authors have shifted, when in fact the historical change already existed and has simply become visible.

The underlying history is not rewritten. The restore process exposes the previously hidden version and adds a new current version above it.

----

==== 🔍 Following a restore ====

After a restore, the following may be observed:

  * A newly created top version representing the restored file.
  * Older versions reconstructed beneath it.
  * Previously hidden minor versions becoming visible.
  * Version timestamps and authors populated where supported by SharePoint.

----

==== ⚖️ Compliance and eDiscovery Considerations ====

Version information is applied as SharePoint metadata on each restored version.

As a result:

  * Files and versions remain part of the SharePoint content store.
  * Author and modified fields remain available where applied.
  * Content remains discoverable using Microsoft Purview eDiscovery tools, subject to Microsoft platform capabilities.

The restore process is designed so that archived content can be returned to SharePoint and continue participating in standard Microsoft 365 governance, compliance, and discovery workflows.

----

If you require assistance validating restored version history, or need support for compliance testing scenarios, contact support@smikar.com.