Introduction
Hi, I'm miruky.
The ordinary Amazon S3 object list can make an object look absent even while an earlier version is still stored. In a versioning-enabled bucket, a delete without a version ID creates a delete marker instead of removing the existing version. Recovery means removing that marker so the previous version becomes current again.
This hands-on exercise builds that state in the AWS Console in us-east-1. It creates one private general purpose bucket, uploads a 27-byte text file, deletes the current object, reveals the retained version, removes only the delete marker, and verifies that the file returns.
Amazon S3 charges for retained versions, storage, and requests. Console browsing also produces metered requests, while DELETE requests are not charged. The temporary object in this run stays below 1 KiB, but check the current Amazon S3 pricing page before using larger files or an account with existing S3 activity.
The role used for this procedure needs permission to create a bucket, enable Versioning, upload and list objects, list object versions, delete the current object, and delete a specific object version. Recovery specifically requires s3:ListBucketVersions and s3:DeleteObjectVersion in addition to the ordinary object permissions.
1. Open Amazon S3 in the target Region
Open Amazon S3 and make sure that the Console is scoped to the N. Virginia Region before creating the bucket.
The page shows General purpose buckets (0) and No buckets, so this run begins without an existing bucket in the list. The Region selector shows United States (N. Virginia), which is the exact Console label captured for the target Region in this session.
2. Create a versioning-enabled bucket
Start a general purpose bucket form and enter the generated validation name shown in the next capture.
The form shows US East (N. Virginia) us-east-1, General purpose, and Global namespace. The bucket name is miruky-yexuizziolgnsbwi, which keeps this validation resource separate from anything the account already owns.
Continue down the same form without changing object ownership or public-access protection.
Block all public access remains selected, and Enable is selected under Bucket Versioning. This keeps the validation object private while retaining the versions needed for the recovery test.
Submit the form and wait for the bucket page to load.
The green notification states Successfully created bucket "miruky-yexuizziolgnsbwi". The same page shows Objects (0) and No objects, confirming that the bucket exists but does not yet contain the test file.
Open the bucket properties before uploading anything.
The Properties tab shows Bucket Versioning as Enabled. AWS recommends waiting 15 minutes after Versioning is first enabled before any object write or delete, so I kept the bucket untouched for the full interval before the next step.
3. Upload one small test object
Create a local file named recovery-note.txt with this single line:
Versioning recovery check.
I saved the file with one trailing line break, making its observed size 27 bytes. Return to the bucket's object list, start an upload, and add that file without changing the destination or optional settings.
The upload table shows 1 total, 27.0 B, the name recovery-note.txt, and the type text/plain. The destination remains s3://miruky-yexuizziolgnsbwi, so the write goes to the bucket whose Versioning state was verified in the previous step.
Submit the upload and wait for the status page.
The green notification reads Upload succeeded, while the summary reports 1 file, 27.0 B (100.00%) succeeded and zero files failed. The file row also carries a Succeeded status, which proves that S3 accepted the object before the deletion test begins.
Close the status page and return to the ordinary object list.
The bucket now shows Objects (1), and the row for recovery-note.txt shows 27.0 B. Show versions is still off, so this is the same current-object view that later makes the delete marker behavior visible.
4. Delete the current object
Select the test object and start a deletion. The confirmation page explains what the versioned delete will do before it changes the bucket.
The blue information panel states that deleting the specified object adds a delete marker and that previous versions remain retained. The specified-object table contains only recovery-note.txt, so the test does not affect another key.
Enter the displayed confirmation word and submit the operation.
The result banner says Successfully deleted objects and explicitly reports that a delete marker was added to the current version. The summary shows one successfully deleted 27-byte object and zero failures, while also noting that previous versions remain retained.
Close the result page and inspect the ordinary object list again.
The page now shows Objects (0) and No objects, even though the earlier 27-byte version has not been permanently removed. This is the failure state to diagnose: the current delete marker hides the retained version from the default list.
5. Reveal the delete marker and retained version
Turn on version display in the object list. S3 expands the single key into its current delete marker and its earlier object version.
The list shows two entries for recovery-note.txt. The newer entry has type Delete marker and size 0 B, while the earlier txt entry remains 27.0 B in the Standard storage class.
The two rows have different version IDs, which is why selecting the correct row matters. Recovery requires deleting only the delete marker; permanently deleting the 27-byte object version would remove the data that needs to return.
6. Remove only the delete marker
Select the delete-marker row, leave the text-object row unselected, and start deletion. Check the specified-object table before entering the confirmation phrase.
The table contains one specified object and identifies its type as Delete marker. The retained text-object version is absent from this confirmation page, which proves that it is outside the permanent-delete request.
Enter the displayed permanent-deletion phrase and submit the marker removal.
The result page reports Successfully deleted objects, with one object deleted and zero failures. Because the request targeted the marker's version ID, the retained text-object version can become current again.
Return to the ordinary list for the final check.
7. Verify that the object is current again
The ordinary list should show the object without requiring a version-specific view.
The bucket now shows Objects (1), and recovery-note.txt is visible again with size 27.0 B and storage class Standard. This is the recovery result: removing the current delete marker exposed the previous object version as the current version.
Wrap-up
This Console run separated two operations that can look similar in the default object list. Deleting the current object created a delete marker and hid the retained data; deleting only that marker made the 27-byte version current again.
The same recovery does not work after the required object version has been permanently deleted. The S3 Console also does not support this delete-marker procedure for undeleting folders, so inspect the exact key, type, and version row before submitting a permanent deletion.
Thanks for reading this far.
See you in the next one.
Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.
Top comments (0)