You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Also you can use the storages..s3.prefix option to specify the path (a sub-folder) to the backups inside the S3 bucket. If prefix is not set, backups are stored in the root directory.
Supporting a prefix for all backups makes sense. Sometimes, backup buckets are shared between various systems, as they are provided with specific replication, access and restrictions. It makes no sense to start creating a bucket for each and every database backup, duplicating this for even every PITR and normal backup which is configured. It would even make sense to also add the prefix at the pitr and schedule definition, which would allow structures like bucketname-here/storage-prefix-here-could-be-db-name/backup-or-pitr-prefix-here/object to exist.
Access to certain folders within the backup location can easily be handled with policies (and should) by the infra/ops/sre/...
Use-Case
More efficient re-use and handling of buckets and backups contained within.
Is this a feature you are interested in implementing yourself?
No
Anything else?
No response
The text was updated successfully, but these errors were encountered:
the prefix doesn't exist but you can specify bucketname-here/storage-prefix-here-could-be-db-name/backup-or-pitr-prefix-here in the backup.storages.NAME.s3.bucket and it will store your backups in the folder you want.
We are using it.
Proposal
Documentation states the following (at https://docs.percona.com/percona-operator-for-mysql/pxc/backup-tutorial.html#configure-backup-storage):
However, looking at the CRD definition, there is no
prefix
underbackup.storages.NAME.s3
. (see https://docs.percona.com/percona-operator-for-mysql/pxc/operator.html#backupstoragesstorage-names3credentialssecret and below)Supporting a prefix for all backups makes sense. Sometimes, backup buckets are shared between various systems, as they are provided with specific replication, access and restrictions. It makes no sense to start creating a bucket for each and every database backup, duplicating this for even every PITR and normal backup which is configured. It would even make sense to also add the prefix at the
pitr
andschedule
definition, which would allow structures likebucketname-here/storage-prefix-here-could-be-db-name/backup-or-pitr-prefix-here/object
to exist.Access to certain folders within the backup location can easily be handled with policies (and should) by the infra/ops/sre/...
Use-Case
More efficient re-use and handling of buckets and backups contained within.
Is this a feature you are interested in implementing yourself?
No
Anything else?
No response
The text was updated successfully, but these errors were encountered: