Why a mirror needs versioning, and a backup doesn't

When you copy a bucket to another bucket in BucketPilot, the form asks one thing before anything else: *if someone deletes a file by mistake, should it disappear from the copy too?*

Answer no and you get a backup: a job that runs on a schedule, copies what changed, and never deletes at the destination. Answer yes and you get a mirror: Amazon S3 replicating the bucket itself, within seconds, deletes included. Both are useful. They are not the same thing, and they need different things from the destination.

A backup's safety comes from not deleting. A file removed at the source stays in the copy until you remove it yourself. An overwritten file is replaced in the copy on the next run — so versioning at the destination is what saves the previous content, and BucketPilot turns it on for any bucket it creates for a backup. But even without versioning, a backup protects you from the most common loss, the delete.

A mirror's value is that the copy is identical *now*. So a delete at the source is a delete at the copy, seconds later, by design. The only thing standing between a mistaken delete and an empty mirror is versioning on both buckets: with it on, S3 replicates a delete as a delete marker and the previous version stays, restorable. Without it, the mirror is a faithful copy of your mistake.

That is why AWS requires versioning on both ends of a replication rule, why BucketPilot checks both buckets before it lets you create a mirror, and why a bucket created from inside the form for a mirror is versioned from the start and cannot be otherwise.

Most teams want a backup: nightly, cheap, never deletes, restorable. A mirror is for the case where seconds matter — a second region that must be able to serve traffic the moment the first one cannot. Many buckets deserve both: a mirror for availability, a backup for the day someone runs the wrong script against both.