Which approach should I use to bulk-restore R2 object versions while excluding intentionally deleted objects?

Question

I have an R2 bucket with object versioning enabled, and I need to recover a large number of objects after an accidental mass overwrite and deletion event. From the documentation, restoring a prior version means copying that version forward or removing delete markers via the S3-compatible API — there is no single "restore bucket to a timestamp" operation, so this has to be scripted.

The part I cannot resolve is how to distinguish objects that were intentionally deleted weeks ago from objects deleted during the incident. Listing versions and blindly removing every delete marker would resurrect data that was supposed to stay gone. I have object metadata (ETag, size, last-modified per version) available, but no application-level audit log of deletions.

I also understand that ETags from multipart uploads are not plain MD5 hashes of the content, so checksum verification against a pre-incident manifest needs to account for that.

My questions:

Is there a documented way to filter delete markers by creation time so a bulk restore only targets a specific incident window?
For multipart-uploaded objects, what is the recommended method to verify integrity of a restored version against a pre-recorded manifest?
Does suspending versioning during the restore script affect how new "restored" versions are written?

Assume current R2 behavior as of late 2026; I will verify against the latest docs before running anything in production.

Tasadduq Burney · Answer

Answer

To recover only the data lost in the accidental overwrite, keep versioning enabled and use ListObjectVersions with a time‑window filter. This returns every version and delete marker with a LastModified timestamp, so you can exclude delete markers that were created before the incident.

Step 1 – Identify the incident window

Determine the exact UTC timestamps of the first and last accidental writes.
Use those timestamps as StartAfter and EndAfter (or the equivalent query parameters) when calling ListObjectVersions.
- Example SDK call (Python):

Step 2 – Filter delete markers

From the returned list, keep only delete markers whose LastModified falls inside the incident window. Delete markers created earlier remain untouched, preserving intentional deletions.

Step 3 – Restore the desired versions

For each object that has a non‑delete‑marker version inside the window, copy that version to the current key:
- REST API: PUT /{bucket}/{key}?versionId={oldVersionId} (this creates a new current version).
Because versioning is enabled, each restore writes a new version; the original content is preserved, and the delete markers you skipped stay deleted.

Multipart‑upload integrity

Multipart uploads produce ETags in the form <md5>-<partCount>. Compare the full string directly to your pre‑incident manifest. If you only have the part MD5s, recombine them as the service does: compute the MD5 of the concatenated part MD5s and append ".partCount".

Do not suspend versioning

Suspending versioning would convert delete markers into hard deletes, erasing the intentional deletions you want to keep. Keep versioning enabled throughout the script; the restore operations will simply create new versions.

Dry‑run and verification

List the objects you plan to restore and the delete markers you will ignore. Export this list to a file.
Run a small subset of copy commands against a test bucket or a dry‑run mode (if supported).
After the full restore, list all delete markers older than the incident window to confirm they are still absent.
Verify a sample restored object’s ETag matches the pre‑incident manifest entry.

Permissions required

s3:ListObjectVersions
s3:GetObject
s3:PutObject

Missing Diagnostic Detail

Do you have a separate record of keys that were intentionally deleted before the incident? If so, we can cross‑reference that list to skip them even if their delete markers fall within the incident window.

Conclusion

By filtering delete markers by LastModified, preserving versioning, and verifying ETags for multipart uploads, you can bulk‑restore only the unintended data loss while keeping intentional deletions intact.