A legal hold on backups is an instruction to keep specific data beyond its normal retention because it may be needed for litigation, an investigation or a regulatory inquiry. Backup systems are built to expire data on schedule. A hold asks them to do the opposite for a defined set of restore points, for an unknown length of time, without disturbing everything else. Handling that well depends on knowing which mechanism the hold uses and what it does to capacity.
This post explains how legal holds apply to backup data, how they differ from retention and what to prepare before the first request arrives.
When an organization reasonably anticipates litigation or receives a preservation notice, it has a duty to keep relevant information intact. Legal counsel defines the scope: which people, systems and date ranges are covered. For IT, the hold translates into a simple requirement with awkward consequences. Nothing in scope may be deleted or altered until counsel releases the hold, and that includes copies in backup if they are the only place the data still exists.
Whether backups fall within a given hold is a legal decision, not a technical one. Many organizations take the position that live systems and archives are the primary sources and backups are covered only when they hold something unavailable elsewhere. IT's job is to be able to preserve the relevant restore points when asked.
| Mechanism | What sets the duration | Who can end it early | Typical use |
|---|---|---|---|
| Retention policy | A schedule in the backup software | Backup administrators | Routine expiry of old restore points |
| Object Lock retention, governance mode | A retain-until date on each object | Accounts with a specific permission | Protection against mistakes and most attacks |
| Object Lock retention, compliance mode | A retain-until date on each object | Nobody, until the date passes | Ransomware protection, regulated retention |
| Legal hold | No date. Stays until explicitly removed | Accounts with a specific permission | Preservation for litigation or investigation |
The key difference is that a legal hold has no expiry. In the S3 Object Lock model it is a separate flag on an object version, independent of any retention period. An object can carry both, and it stays protected until the retention date has passed and the hold has been removed. Object Lock governance and compliance modes covers the retention side.
There are three common ways to preserve backup data for a hold. The first is in the backup software: marking selected restore points so that retention processing skips them, or exporting them as standalone backups with no expiry. The second is at the storage layer, by placing an Object Lock legal hold on the objects that make up those restore points, where the backup software and the storage both support it. The third is to copy the relevant restore points to a separate repository or bucket reserved for held data, with its own access controls.
The export and copy approaches are the most widely available and the easiest to explain to counsel, because the held data is plainly separated from routine backups. They use additional capacity for the duration of the hold.
Backups are organized by machine and date, while holds are defined by people and subject matter. A hold covering one employee's email from March to June may map onto every nightly backup of the mail system for four months. Preserving all of it keeps far more than is needed, and extracting only the relevant mailboxes requires restoring and exporting. Agreeing the approach with counsel in advance, for the systems most likely to be involved, avoids improvising under a deadline.
Incremental chains add a further complication. A single restore point may depend on earlier ones, so holding one date can mean holding the full backup it derives from and every increment in between. How backup chains behave on object storage explains those dependencies.
Held data does not expire, so it accumulates. One hold covering a few systems for a few months is negligible. Several open-ended holds on large systems can occupy a meaningful share of the repository for years, because litigation moves slowly and releases are easily forgotten. Held capacity should be tracked as its own line in capacity reporting, with the matter it relates to and the date it was applied. What happens when retention locks expire describes the normal lifecycle that held data steps outside of.
A hold ends when counsel says so in writing. At that point the held restore points return to normal retention, which usually means they are immediately eligible for deletion, since their original retention expired long ago. The release should be recorded, and the deletion confirmed. Data kept past the end of a hold with no other reason is a liability under privacy rules that limit how long personal data may be stored.
A quarterly review of open holds with the legal team keeps the list current. It takes little time and prevents the slow build-up of forgotten preservation copies.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires. Restore points preserved for a hold can be kept in a separate bucket with its own access keys, apart from routine backups.
ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB, which helps when open-ended holds add capacity that was not in the original plan. It is used as a target for Veeam and other backup software.
A short procedure, agreed with legal counsel, covers most cases: who may request a hold, how scope is translated into systems and dates, which mechanism is used to preserve the data, where held copies live, how they are tracked and how they are released. Written in advance, it turns an urgent and unfamiliar request into a routine task.