Privacy
Backup retention outlives every other setting
Backups exist to survive deletion, so an upload can persist in a backup rotation long after it is gone everywhere else.
Guides on Privacy: Who could see it, how, and what each path costs to close, Soft delete, backups, caches and logs, Sometimes, and the policy clause that says so is easy to miss
Deleting a file from a live database does not remove it from backups taken before the deletion, so a photo can outlive a deletion request for weeks. A backup's purpose is to survive changes to the live system, including the change where something gets deleted, which puts it structurally at odds with erasure.
Why backups resist deletion by design
A nightly or weekly backup snapshot captures the state of the storage system at that moment and keeps it, unaltered, for a set retention window - often thirty, sixty or ninety days, sometimes longer for compliance reasons. If your photo existed at the moment a snapshot was taken, it is in that snapshot, and it stays in that snapshot until the snapshot itself is retired on its own schedule. Reaching into a specific backup to remove one file is technically possible but operationally rare, because backups are built to be restored wholesale, not edited selectively, and most systems have no tooling for it at all.
What this means for a deletion request
A service can delete your photo from live storage the moment you ask and still be holding a copy in backup rotation for weeks afterward, entirely consistent with what it told you, because "deleted" in the product sense usually means "removed from the systems that serve it," not "purged from every historical snapshot." What a deletion request actually triggers covers this gap in more detail; the short version is that the honest promise is "gone from live systems now, gone from backups within the retention window," and a policy that states the backup window explicitly is doing better than most. The UK regulator accepts the gap but sets conditions: the ICO's right-to-erasure guidance says backup copies must be put "beyond use", even if they cannot be immediately overwritten, and must not be used "for any other purpose."
Why the number matters more than the promise
Backup retention windows are usually set for operational reasons - restoring service after an outage, recovering from a bad deployment - not chosen with a deletion request in mind at all. That means the window is often longer than a privacy-conscious default would pick, simply because nobody weighed the two goals against each other when the setting was configured. A shorter window is a real, checkable improvement a service can make without touching anything about how it processes photos in the first place, which is why it is worth asking about directly rather than assuming it tracks the product's own deletion promise.
What to look for
A specific number - "backups are retained for 90 days and then permanently overwritten" - is a real answer. "We take your privacy seriously" is not. The same specificity is what makes a retention clause worth reading closely rather than skimmed. Rate Cock states its backup retention window directly rather than only describing what happens to the live copy, which closes the gap this post is about. The same rotation exists behind a recorded measurement on Measure My Cock, behind a comparison saved on Penis Rater, and behind the records a human review on Rate Penis generates - anywhere a system is backed up at all, which is nearly everywhere, this same tail applies.