docs: Issue on page Backup: make it clearer backup bucket should not use life cycle

[tzach]

I would like to report an issue on page https://manager.docs.scylladb.com/stable/backup/index.html#backup-location

Problem

ScyllaDB Manager manages the backup SSTable's life cycle, including which sstable belong to which backup (one file can be part of more than one backup). Enabling bucket lifecycle may result in backup files deleted by the cloud provider (e.g. S3) while still belonging to an active backup

Suggest a fix

Add a clear warning:

Do not enable lifecycle for a backup bucket.
Scylla Manager own the backup files, and manage the retention base on the backup policy.

[regevran]

As I suggested, we may want to enjoy both SM management and S3 life-cycle management to be on the safe side.
For this we need to touch the objects that were not re-uploaded.
The way to touch an S3 object is to either update its metadata or copy it to itself (costs?). In either ways the timestamp is updated and the file will not be deleted as part of life-cycle management.
The regular SM cycle then is to "touch" all files that are part of a backup - either newly uploaded or those that already exist (and therefore de-duplicated).

In this way if SM misbehaves by "loosing" files, i.e. there are S3-objects that are not mapped to any backup - S3 itself will eventually remove them.

[karol-kokoszka]

@regevran
As far as I know, in S3, the default object lifecycle policy bases on LastModified timestamp.
There is no simple "touch" functionality that I'm aware of, allowing to reset the expiry counter.
The only option is to modify the object (upload it again for example).

[tzach]

@regevran the suggestion make sense, but please open a new issue for it.
Let's start with improve the docs of current functionality.

[regevran]

Created: #4337