Undoing Changes in S3 Files

Amazon S3 Files provides provides fast, direct access to all of your S3 data as files with full file system semantics and low-latency performance, without your data ever leaving S3. A key property of how S3 Files synchronizes changes back to your S3 bucket is that no operation permanently deletes data. Every change S3 Files makes to your bucket is reversible using S3 Versioning, which means most mistakes can be undone in minutes using The Rollback Tool for Amazon S3 - an AWS open source sample.

Important note: If a noncurrent version expiration lifecycle rule, or any other action, has permanently removed the versions you need then recovery is not possible. See S3 Lifecycle and the Recovery Window, below.

S3 Files changes are reversible

S3 Files requires S3 Versioning to be enabled on the linked bucket. When changes happen on the file system, S3 Files translates them into S3 operations that preserve all previous data:

• File deletion → S3 Files places a delete marker on the corresponding object. The previous version remains intact.
• File modification → S3 Files writes a new object version via a PUT request. The previous version remains intact.
• File rename or move → S3 Files copies each object to a new key (with the updated prefix) and places a delete marker on the original. Both the original version and the copy are retained.
• Directory rename → Same as file rename, applied to every object sharing the directory prefix. Each object gets a copy at the new key and a delete marker at the old key.
• Directory deletion → S3 Files places a delete marker on every object under the directory prefix. All previous versions remain intact.
• Permission changes (chmod, chown, chgrp) → S3 Files writes a new object version with updated user metadata. The previous version remains intact.

S3 Files never calls DeleteObject with a VersionId — it only places delete markers — and overwrites create new versions. This means the Rollback Tool can reverse any combination of these operations by manipulating delete markers and copying previous versions back to the top of the version stack.

The Rollback Tool for Amazon S3

The The Rollback Tool for Amazon S3 is an open-source AWS sample that reverts changes to S3 datasets at scale. It deploys as a CloudFormation stack, uses Athena to analyze your bucket inventory, and creates S3 Batch Operations jobs to perform the minimum operations needed to restore your bucket to a specific point in time.

Key characteristics:

• Reverts 10 million changes in under 1 hour, even in billion-object buckets
• Never permanently deletes data — only adds/removes delete markers and copies versions
• Supports S3 Metadata live inventory tables for near-instant inventory availability
• Three modes: Bucket Rollback (full revert), Delete Marker Removal (undelete only), and Copy to Bucket (point-in-time copy to a separate bucket)
• Creates S3 Batch Operations jobs for review before execution — you control which operations run

Read more about the rollback tool at Rapid and scalable data recovery using Amazon S3 Versioning, with the Rollback Tool for Amazon S3.

Prerequisites

To use the Rollback Tool with S3 Files:

1. S3 Versioning must be enabled on the linked bucket (S3 Files requires this).
2. A current inventory of the bucket. S3 buckets with S3 Metadata live inventory enabled provide the fastest path — the tool can start in under 15 minutes. Without S3 Metadata, you can use S3 Inventory (adds up to 48 hours) or create a real-time inventory via ListObjectVersions for smaller buckets.
3. Desired versions must still exist. If a noncurrent version expiration lifecycle rule has permanently removed the versions you need, recovery is not possible. See S3 Lifecycle and the Recovery Window, below.

Example: Recovering from a directory rename

Suppose you have a directory /mnt/s3files/projects/alpha/ containing 500 files, mapped to the S3 prefix projects/alpha/. At 2:00 PM UTC, a user renames it:

mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta

The rename completes instantly on the file system. Over the next few minutes, S3 Files synchronizes the change to S3 by copying each object to its new key under projects/beta/ and placing a delete marker on the original key under projects/alpha/. After synchronization completes, the bucket contains:

Key	Current version
projects/beta/report.csv	New copy (PUT)
projects/beta/data.parquet	New copy (PUT)
projects/beta/... (498 more)	New copies (PUT)
projects/alpha/report.csv	Delete marker
projects/alpha/data.parquet	Delete marker
projects/alpha/... (498 more)	Delete markers

Every original version under projects/alpha/ still exists — it's just hidden behind a delete marker.

To undo this rename, deploy the S3 Rollback Tool in Bucket Rollback mode with a timestamp of 2026-04-13T14:00:00 (just before the rename) and prefix projects/. The tool analyzes the inventory and creates three S3 Batch Operations jobs:

1. Scenario 1 (revert non-overwrite PUTs): Places delete markers on the 500 new objects under projects/beta/ — these didn't exist before the rename.
2. Scenario 2 (revert DELETEs): Removes the 500 delete markers from projects/alpha/ — restoring the original objects as current versions.
3. Scenario 3 (revert overwrite PUTs): No objects in this case, since the rename created new keys rather than overwriting existing ones.

After running jobs 1 and 2, the bucket is back to its pre-rename state: projects/alpha/ contains all 500 files, and projects/beta/ is soft-deleted. The file system reflects the change on the next synchronization cycle.

Alternatively, you can undo a rename by simply renaming back (mv projects/beta projects/alpha). However, if the original rename has already synchronized to S3, renaming back will create an additional copy of every object rather than restoring the original versions. For 500 files, that means 500 extra PUT requests and 500 additional noncurrent versions in your bucket. The rollback tool avoids this by removing delete markers instead of creating new versions (and soft-deleting the copies).

Example: Recovering from a directory deletion

Suppose you have /mnt/s3files/logs/2026-q1/ containing 10,000 log files. At 3:30 PM UTC, a user deletes the directory:

rm -rf /mnt/s3files/logs/2026-q1

S3 Files places a delete marker on every object under the logs/2026-q1/ prefix. The files disappear from the file system and from the default S3 console view. But every previous version is still in the bucket.

To recover, deploy the S3 Rollback Tool in Delete Marker Removal mode with timestamp 2026-04-13T15:30:00 and prefix logs/2026-q1/. The tool creates a single S3 Batch Operations job:

• Scenario 4: Removes all 10,000 delete markers placed after the timestamp. The previous object versions become current again.

After the job completes, all 10,000 log files are restored as current versions in S3. S3 Files detects the changes via event notifications and reflects them in the file system — the logs/2026-q1/ directory reappears with all its contents.

S3 Lifecycle and the recovery window

Typically, S3 buckets should have a noncurrent version expiration lifecycle rule to control storage costs. This rule permanently deletes noncurrent versions (including the previous versions behind delete markers) after a configured number of days. Once a version is permanently deleted, it cannot be recovered by any means.

The number of days you set on this rule defines your recovery window. For example, with a 30-day noncurrent version expiration rule, you can roll back any change made in the last 30 days. After that, the old versions are gone.

Recommendations:

• Set the noncurrent version expiration period to match your organization's recovery time requirements. Common values range from 7 to 90 days.

• Deny DeleteObjectVersion, PutBucketVersioning and PutLifecycleConfiguration for roles that don't need them, using bucket policies or RCPs. This prevents permanent deletion of versions outside of your predefined lifecycle rules.

• For critical data, consider S3 Object Lock in compliance mode to prevent any permanent deletion — including by lifecycle rules — during the retention period.

• If an incident occurs, temporarily disable any lifecycle expiration rules on the bucket before starting recovery, to prevent versions from expiring while the rollback is in progress.

Preparation reduces recovery time

The Rollback Tool is deployed on demand via CloudFormation and removed after use. Pre-incident preparation significantly reduces recovery time:

• Enable S3 Metadata on buckets with more than a million objects — this eliminates the S3 Inventory or ListObjectVersions wait.
• Deploy and test the tool against a non-production bucket to validate the workflow.
• Document the recovery procedure and get organizational approval in advance.

When an incident occurs, a prepared team can go from detection to recovery in minutes rather than hours.

Summary

S3 Files' synchronization model — delete markers for deletions, new versions for modifications, copy-and-delete-marker for renames — means your S3 bucket retains a complete, versioned history of every change. The Rollback Tool for Amazon S3 leverages this history to reverse any combination of changes at scale, with one-second precision. Whether you need to undo an accidental rm -rf, revert a misguided directory rename, or roll back an entire prefix to yesterday's state, the data is there and the tooling exists to restore it.

For more information:

• The Rollback Tool for Amazon S3 on GitHub
• S3 Files documentation
• S3 Files synchronization
• S3 Versioning