As part of the ticket K8SPXC-1118 we are monitoring binlog gaps and then marking the full backups (kubernetes object) as not appropriate for PITR restore. But for PITR restore we can use backupSource functionality to not restore from the backup object and just by looking at S3 bucket it will not be clear that some backup is not good for PITR restore.
So the idea is that when we mark a full backup with "PITRReady: False" we also push an empty file to S3 bucket for the same backup with name something like <backup_name>-gap-detected or something like that. That has two benefits:
just by looking at S3 bucket I could check which backup is not PITR ready
when we try to do PITR restore with backupSource we could check for existence of this file (just like we check if the full backup is PITR ready) and issue error/warning if file exists
As part of the ticket K8SPXC-1118 we are monitoring binlog gaps and then marking the full backups (kubernetes object) as not appropriate for PITR restore.
But for PITR restore we can use backupSource functionality to not restore from the backup object and just by looking at S3 bucket it will not be clear that some backup is not good for PITR restore.
So the idea is that when we mark a full backup with "PITRReady: False" we also push an empty file to S3 bucket for the same backup with name something like <backup_name>-gap-detected or something like that.
That has two benefits:
just by looking at S3 bucket I could check which backup is not PITR ready
when we try to do PITR restore with backupSource we could check for existence of this file (just like we check if the full backup is PITR ready) and issue error/warning if file exists