You deleted objects from a DigitalOcean Space. Maybe it was a script that ran too broadly, a wrong prefix in an aws s3 rm command, or a UI click you can't take back. You're here because you want to know if recovery is possible.
The answer depends entirely on one setting: whether versioning was enabled on that Space before the deletion happened. This article walks you through what to check, what you can recover, and what to do so this can't happen again.
The short answer: it depends on versioning
DigitalOcean Spaces is S3-compatible, which means it supports object versioning. When versioning is on, deleting an object doesn't erase it. Instead, Spaces places a "delete marker" at the top of the object's version stack, hiding it from normal listings. The actual content sits underneath, accessible via the API.
When versioning is off, deletion is immediate and permanent. The object is gone. There is no trash folder, no soft-delete window, no internal snapshot. Gone means gone.
The critical fact: versioning is off by default on DigitalOcean Spaces. Most people learn this at the worst possible moment.
Start here. Check whether versioning was enabled on your bucket before the deletion:
aws s3api get-bucket-versioning
--bucket your-space-name
--endpoint-url https://nyc3.digitaloceanspaces.com
Replace nyc3 with your Space's region (e.g., ams3, sgp1, sfo3). If versioning was active, the response looks like this:
{
"Status": "Enabled"
}
If the response is empty, or you see "Status": "Suspended", versioning was not protecting your objects at the time of deletion.
Versioning is off by default on DigitalOcean Spaces. If you haven't explicitly enabled it, it's off. Enable it now, before you need it.
If versioning was on: how to recover
If the command above returned "Status": "Enabled", your deleted objects are still there. You need to list the versions of the object to find the version ID you want to restore, then copy that specific version back into place.
Step one: list all versions of the deleted object (or all objects under a prefix):
aws s3api list-object-versions
--bucket your-space-name
--prefix path/to/your/object.ext
--endpoint-url https://nyc3.digitaloceanspaces.com
The output shows Versions (the actual content) and DeleteMarkers (the tombstones created by each delete operation). The version you want is the most recent Version entry before the DeleteMarker at the top.
Step two: restore that version by copying it back to the same key:
aws s3api copy-object
--bucket your-space-name
--copy-source "your-space-name/path/to/your/object.ext?versionId=PASTE_VERSION_ID_HERE"
--key path/to/your/object.ext
--endpoint-url https://nyc3.digitaloceanspaces.com
This creates a new current version of the object using the old content. The delete marker remains in the version history but is no longer the current version, so the object is visible again in normal listings.
For a bulk delete (many objects under one prefix), the same pattern applies at scale: list all delete markers under the prefix, then delete each delete marker by version ID. Deleting a delete marker promotes the previous version back to current. The full restore workflow for Spaces covers the scripted approach for recovering hundreds or thousands of objects at once.
Important caveat
Versioning protects against accidental deletion of individual objects. It does not protect against someone deleting the entire bucket, or against account-level compromise where an attacker has your credentials. For those scenarios, you need an off-site copy, not just versioning.
If versioning was off: what's actually gone
If versioning was not enabled, the deleted objects are unrecoverable through any self-service means. DigitalOcean does not maintain shadow copies of unversioned objects after deletion. There is no administrative restore path you can trigger from the DigitalOcean control panel.
This is not a DigitalOcean limitation so much as how S3-compatible object storage works at the infrastructure level. When a write comes in to delete an unversioned object, the content is removed from the backing store. There is no staging area.
What this means practically:
| Scenario | Versioning on | Versioning off |
|---|---|---|
| Single object deleted | Recoverable via delete marker removal | Gone permanently |
| Bulk delete (prefix) | Recoverable via delete marker removal | Gone permanently |
| Object overwritten | Previous version recoverable | Gone permanently |
| Bucket-level deletion | Not recoverable | Not recoverable |
| Account compromise | Not recoverable | Not recoverable |
The bucket-level and account-level rows are the same regardless of versioning status. Versioning operates at the object layer, not the bucket layer. A DeleteBucket operation removes the bucket and everything in it, including the version history.
If you are recovering from an accidental bulk delete with versioning off, your options are:
- Restore from a backup you made to a separate destination (another storage provider, a local server, another cloud account).
- Accept the data loss and rebuild from source.
That is a painful place to be. The how DigitalOcean native backup works article covers what Spaces does and doesn't include natively, and what native backup doesn't cover goes into why Spaces is the product most commonly left unprotected.
Can DigitalOcean support recover deleted objects?
No. This is one of the most common questions we see, and the answer is consistent: DigitalOcean support cannot recover objects deleted from a Space without versioning.
When you open a ticket, support will ask for the bucket name, the object keys, and an approximate deletion timestamp. They will verify this internally. The response will confirm that without versioning, the data is not recoverable from their side.
This is not a policy limitation. DigitalOcean does not retain deleted unversioned objects in a recoverable form at the infrastructure layer. There is nothing for support to restore from.
The only exception we've seen flagged in support threads is if DigitalOcean itself experienced a platform-level incident that caused unintended deletion. In that case, they investigate on their own and may have internal recovery paths. Accidental deletion triggered by your account's API calls or UI actions falls entirely outside that path.
Designing around this failure mode
The time to fix this is before it happens. Two layers of protection, in order of how quickly you should add them.
Layer 1: Enable versioning on every Space that holds important data.
You can enable versioning with a single API call:
aws s3api put-bucket-versioning
--bucket your-space-name
--versioning-configuration Status=Enabled
--endpoint-url https://nyc3.digitaloceanspaces.com
Versioning applies to new writes from that point forward. It does not retroactively version existing objects, but it ensures that from the moment you enable it, nothing you write can be silently deleted.
The cost consideration: versioning accumulates multiple copies of each object. For Spaces buckets that receive frequent overwrites (logs, processed output, rotating files), you should pair versioning with a lifecycle rule that expires old versions after a set number of days to avoid unbounded storage growth.
Layer 2: Maintain an off-site mirror.
Versioning protects against accidental deletes. It does not protect against account compromise or bucket-level deletion. An off-site mirror is the only full protection.
If an attacker gets your DigitalOcean credentials and deletes your Space, versioning is gone with it. If DigitalOcean suspends your account over a billing dispute, your versioned Space is inaccessible until resolution. The backup for a Space is a copy of that Space's contents sitting in a different cloud account, ideally under a different provider.
For how to set that up, the off-site compliance for DigitalOcean article covers the architecture. Backing up DigitalOcean Spaces covers the practical steps for establishing a continuous backup of a Space to external storage.
What to do tonight:
Run the versioning check command from §1 against every Space in your account. For any Space that returns empty or Suspended, decide whether the data matters. If it does, enable versioning immediately. Then schedule the off-site mirror work for this week, not next quarter.
If you've read this far, you probably already know whether native versioning is enough for your project. If it isn't, SimpleBackups gives you cross-region off-site backup for Spaces, automated verification, and a restore you can actually test.
Keep learning
- Backing up DigitalOcean Spaces
- Restoring from a DigitalOcean Spaces backup
- What DigitalOcean native backup doesn't cover
- How to create a storage replication with SimpleBackups
- DigitalOcean backups explained
FAQ
Is versioning on by default for DigitalOcean Spaces?
No. Versioning is off by default on all DigitalOcean Spaces. You must explicitly enable it using the S3-compatible API or the DigitalOcean control panel. If you haven't done this, your objects are not protected against deletion.
Can DigitalOcean recover deleted Spaces objects?
No. DigitalOcean support cannot recover objects deleted from a Space where versioning was not enabled. The data is removed at the infrastructure level and there is no recoverable copy on DigitalOcean's side. If versioning was on, you can recover the objects yourself without involving support.
How do I enable versioning on a Space?
Run aws s3api put-bucket-versioning --bucket your-space-name --versioning-configuration Status=Enabled --endpoint-url https://nyc3.digitaloceanspaces.com (adjust the endpoint URL to match your Space's region). Versioning takes effect immediately for new writes but does not retroactively protect existing objects.
Does versioning protect against bucket deletion?
No. Versioning protects individual objects within a bucket from accidental deletion or overwriting. It does not protect against the bucket itself being deleted. A DeleteBucket operation removes the bucket and its entire version history. Protecting against bucket-level deletion requires an off-site copy of the bucket's contents.
How do I back up a Space if versioning isn't enough?
You need a continuous copy of your Space's contents in a separate cloud account, ideally under a different provider. SimpleBackups automates this: it syncs your Space to an external storage destination on a schedule and alerts you if a sync fails. That off-site copy is what lets you recover from account-level events that versioning cannot protect against.
This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.