SaaS backup retention is often assumed to be the provider's job. The application is hosted, the provider keeps it available, and deleted items go to a recycle bin from which they can be restored. For everyday mistakes caught quickly, that is enough. For anything discovered late, removed deliberately or needed years afterwards, it is not, and the gap between the two is where data is lost.
This post explains what the built-in retention features of SaaS applications are designed for, where they stop and what a separate backup adds.
A recycle bin is a convenience feature. It gives users a short window to undo a deletion without calling the service desk. It lives inside the same service as the data, is governed by the same administrator accounts and follows a fixed schedule set by the provider. When the window closes, the item is purged.
In Microsoft 365, for example, deleted SharePoint and OneDrive items are kept for 93 days across the two recycle bin stages by default, and deleted mailbox items remain recoverable for 14 days by default, extendable to 30. Other SaaS platforms use different periods, but the pattern is the same: weeks or a few months, not years.
| Question | Recycle bin and version history | Separate backup |
|---|---|---|
| How long is deleted data kept? | A fixed period set by the provider | As long as the organization's policy requires |
| Where is the copy held? | Inside the same service | In a repository outside the service |
| Who can purge it early? | Users and administrators of the service | Only backup administrators, or nobody if immutable |
| Can a whole site or mailbox be rolled back to a date? | Limited, and only within the window | Yes, to any retained restore point |
| Does it survive account deletion? | For a short grace period | Yes, for the full retention period |
| Does it help if the tenant itself is compromised? | No | Yes, if the repository is independent |
Four situations account for most SaaS data loss that the provider's features do not cover. The first is late discovery: a folder deleted in January and missed in June is past every default window. The second is deliberate purging, where a departing employee or an attacker with a stolen account empties the recycle bin as well. The third is corruption that spreads quietly, such as a sync client overwriting good files with encrypted ones, which fills version history with bad copies. The fourth is account removal, where a leaver's mailbox and files are deleted along with the license and nobody asks for them until the grace period has passed.
SaaS providers are clear about the division of duties in their service terms. The provider is responsible for keeping the service running and for the durability of its own infrastructure. The customer is responsible for the data: who can access it, how long it is kept and whether it can be recovered after a mistake or an attack. Retention policies and litigation holds offered by the provider are compliance tools. They preserve content for legal discovery, but they are not designed to restore a working mailbox or site to a point in time.
A backup that closes the gap has four properties. It keeps data for the period the organization chooses, independent of the provider's schedule. It stores that data outside the SaaS tenant, under different credentials, so that a compromise of the tenant does not reach it. It can restore at several levels, from a single message or file to a whole mailbox or site. And it protects its own copies against deletion, which is where immutability comes in. What immutable backups protect covers that last point in more detail.
Retention itself should be set from real requirements, not habit. Matching retention to recovery needs gives a method for deciding how many restore points to keep and for how long.
Some SaaS backup services store data in the vendor's own cloud. Others let the customer choose the repository, including S3-compatible object storage on-premises. The second option gives the organization direct control over location, retention and cost, and keeps the copy physically separate from both the SaaS provider and the backup vendor's hosted service. It also means the repository must be sized and run like any other backup target. Planning an object storage repository covers what that involves.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. SaaS backup products that write to S3-compatible storage can use it as their repository, which places the copy outside the SaaS tenant and under separate administrative accounts. Immutability is provided by S3 Object Lock on each object where the backup product supports it, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
One question shows whether the gap exists in a given organization: if a shared mailbox or a project site had been deleted six months ago, could it be brought back today? If the answer depends on the recycle bin, the retention gap is real, and the next step is deciding how long deleted data needs to stay recoverable.