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

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:

1. Is there a documented way to filter delete markers by creation time so a bulk restore only targets a specific incident window?
2. For multipart-uploaded objects, what is the recommended method to verify integrity of a restored version against a pre-recorded manifest?
3. 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.