Item Lifecycle & Tier States
Every backed-up item BYOVault catalogs carries its own tier state — a record of where its bytes actually live right now. An item moves through exactly three states: Active, Move in progress, and Vaulted.
The three states
Every catalog entry starts as Active: the file is backed up and its bytes sit in the tenant’s primary storage account or container. This is the default and normal state for every item, for as long as its source content stays within your configured age threshold.
When an item ages past that threshold, it becomes eligible for the vault-move sweep. The sweep marks it Move in progress before it attempts to copy a single byte — that way, if the move is interrupted partway through, the item is left in a visible, trackable state rather than silently claiming to still be Active while a copy may already be in flight.
Once the copy into the vault account has been verified readable and the original has been removed from primary storage, the item is marked Vaulted — the terminal state.
Only a Vaulted item is ever eligible for the tenant’s storage-provider lock (AWS Object Lock Compliance mode, or Azure’s locked immutability policy) to actually apply to it. See Retention Policy for what that lock guarantees once an item reaches this state.
| State | What it means | What triggers it |
|---|---|---|
| Active | Bytes live in primary storage. The default state for every newly backed-up item. | Item is first cataloged, or a prior vault-move attempt failed and was reverted. |
| Move in progress | A vault-move copy is in flight, or was interrupted before it could complete or revert. | The archiving sweep selected this item as eligible and marked it before starting the copy. |
| Vaulted | Bytes are verified present in the tenant’s separate vault account and removed from primary. Terminal. | The copy was verified readable and the original was successfully deleted from primary. |
What triggers Active → Move in progress
A scheduled sweep, run on a per-tenant cadence, checks every Active item against two conditions:
- The item’s real source-side last-modified date (not the date BYOVault backed it up) is older than that item’s workload’s configured threshold.
- The item has not been placed under Preserve.
Each of the four workloads — SharePoint, OneDrive, Exchange, file server — has its own configurable threshold in days, evaluated independently rather than against one tenant-wide number.
The sweep also requires the tenant’s retention vault to already be in its locked state. If the vault is not yet provisioned, still provisioning, or failed, no item is moved.
A matching item is marked Move in progress immediately, before the sweep attempts the real cross-account copy. This ordering is what makes the move safe to resume: an interruption between this step and the completed copy leaves the item visibly in-flight rather than wrongly still appearing Active.
What triggers Move in progress → Vaulted
The move itself follows a fixed order:
- The original is read from primary storage.
- It is written into the tenant’s vault account.
- The vault copy is verified before the original is deleted from primary.
The item is marked Vaulted only after both the copy and the deletion have completed.
Restore resolves the correct vault account for each item automatically, rather than assuming every item lives in the tenant’s primary account.
A failure at any point before the original is deleted leaves primary storage untouched, and the item is reverted to Active to be retried on a future sweep — one failed item never blocks the rest of the batch.