Skip to main content

VB365: Item-Level Retention & Backup Copies

  • January 21, 2026
  • 1 comment
  • 13 views

MicoolPaul
Forum|alt.badge.img+23

Hi all,

Just a quick blog post to summarise the findings from a question that was recently posed to me.

Background on VB365 Retention Modes:

When using Veeam Backup for Microsoft 365, there are two retention modes possible. These are called ‘snapshot-based’ retention and ‘item-level’ retention. I won’t repeat Veeam’s documentation and you can have a full deep dive into the topic here if you’d like, but to provide a brief summary:

  • Item-level retention leverages the creation date and last modified date to determine if an item is older than the retention period. If it is not, then it will backup the item.
  • Snapshot-based retention protects everything that currently exists within the container (mailbox/OneDrive/SharePoint/Teams) regardless of creation date or last modified date. Once the item no longer exists within the Microsoft 365 container, Veeam Backup for Microsoft 365 determines if how long ago it was last protected is older than the retention period, and if so, purges the item from the backup.

So, you can see, two quite different logical processes.

Today’s Question: Item-Level Retention on Backup vs Backup Copies:

Then we need to overlay how backups vs backup copies work. Whilst a backup will use Microsoft 365 as its source, a backup copy will use a backup as its source. But backup copies have their own retention independent to primary backups, this is because normally a backup copy is to cheaper, long-term purpose storage. When a backup copy is performed, only the latest retention point is copied. For snapshot-based retention, this seems straightforward, only the latest ‘snapshot’ is copied. But for item level retention, what happens to items that were deleted from M365 but still exist in the backup?

I spun up my test environment to validate this, and I can confirm that even though item-level retention has a different retention logic applied to it, the concept of a backup copy only copying the latest state still applies. Any items that exist within M365 at the point of the latest backup job run, will be copied, nothing prior to this, however.

This was validated by creating some dummy data, backing it up, and then deleting the data from M365 (all the way through the second stage recycle bin for good measure!) and then testing the explorer for the primary backup. I could see the dummy data when I navigated the earlier backup session, but not the latest session. If I then changed the latest backup session to include all deleted items, I could see the data.

After this was validated, I created a backup copy to a new object storage repository and ran the job. I then attempted to browse the backup copy, and I couldn’t see the deleted data. I attempted this again, including all deleted items, and the data still did not appear. I didn’t want to look at the object storage repository sizes to gather this information as VB365 stores the data in a different format between a primary backup and a backup copy, so this wouldn’t have been an apples-to-apples comparison.

And there we have it, VB365 will only copy the data within your latest backup to a backup copy, no matter which retention type you use.

1 comment

Chris.Childerhose
Forum|alt.badge.img+21

This is a great article as it gives clarity to each of the backup types and retention.  Thanks for sharing Michael.