Bug Report: VitessBackupSchedule silently ignores extraFlags when using vtbackup

[yydoow]

Summary

VitessBackupScheduleStrategy.extraFlags is documented as flags passed to vtctldclient, but VitessBackupSchedule only uses vtbackup under the hood.
As a result, any flags specified in extraFlags — including incremental-from-pos: auto — are silently ignored and never passed to the vtbackup container.
This causes a critical silent misconfiguration: users believe they are taking incremental backups, but full backups are being taken instead.

Steps to Reproduce

• Create a VitessBackupSchedule with an extraFlags entry:

strategies:
- extraFlags:
    incremental-from-pos: auto
  keyspace: unsharded
  name: unsharded-x-x
  shard: '-'

• Wait for the schedule to trigger a backup job.
• Inspect the created vtbackup pod's container args.

Expected Behavior

The extraFlags entry incremental-from-pos: auto should be passed to the vtbackup container as --incremental-from-pos=auto, resulting in an incremental backup.

Actual Behavior

The vtbackup container is launched without --incremental-from-pos. No error or warning is surfaced. A full backup is taken silently.

vtbackup pod args (relevant excerpt):

- --backup_engine_implementation=xtrabackup
- --initial_backup=false
...
# --incremental-from-pos is absent

Manually running vtbackup with --incremental-from-pos=auto confirms incremental backup works correctly, producing binlog-only output:

found 1 files to backup
Backing up file: vt-1805737721-bin.000001
Backup successful.

Root Cause

The extraFlags field on VitessBackupScheduleStrategy is documented as:

ExtraFlags is a map of flags that will be sent down to vtctldclient when taking the backup.

Since VitessBackupSchedule only provisions vtbackup pods (not vtctldclient), the flags are never applied. The documentation is misleading and the operator has no code path to forward extraFlags to the vtbackup container arguments.

Impact

Potential bigger backup/storage costs: Users configure incremental-from-pos: auto expecting incremental backups but receive full backups without any indication of failure.

The VitessBackupSchedule status shows successful jobs, giving a false sense of correctness.

Proposed Fix

Either:

• Pass extraFlags to the vtbackup container args when the schedule uses vtbackup (rename/clarify the field accordingly), or
• Emit a warning or validation error when extraFlags contains vtbackup-specific flags that cannot be forwarded, and
• Update the extraFlags documentation to accurately reflect which flags are supported and for which backend.

[nickvanw]

@yydoow I think extraFlags should probably have been removed when the operator went to using vtbackup-based flags, with #771 we now get them back, but they won't apply to the vtbackup path.

It looks like the intention is to apply this on the tablet with vtbackupExtraFlags which.. works? Though it's a bit convoluted.

With #771, I think we could get away with just adding validation that extraFlags is only meant to be used with that path, but I'd love your feedback.

[yydoow]

With different backup methods, either will have it's own Flags:

• extraFlags for vtctldclient backupshard
• vtbackupExtraFlags for vtbackup

I am not sure if there is any case we want to pass some parameters to vtbackup.

If I want to implement incremental backup through vtbackup, I need --incremental-from-pos under vtbackupExtraFlags, though I am able to do it via

  /vt/bin/vtctldclient --alsologtostderr \
  --server=$(kubectl get svc -l vitess_component=vtctld -ojson | jq -r '.items[].metadata | .annotations."external-dns.alpha.kubernetes.io/hostname"'):15999 \
  Backup --incremental-from-pos=auto --backup-engine=xtrabackup las-3964364658
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
unsharded/- (las-3964364658): time:{seconds:1774939272 nanoseconds:595810567} file:"backup.go" line:156 value:"Starting backup 2026-03-31.064112.las-3964364658"
unsharded/- (las-3964364658): time:{seconds:1774939272 nanoseconds:595835966} file:"backup.go" line:176 value:"Using backup engine \"builtin\""
unsharded/- (las-3964364658): time:{seconds:1774939272 nanoseconds:595849887} file:"builtinbackupengine.go" line:228 value:"Executing Backup at 2026-03-31 06:41:12.586154508 +0000 UTC m=+3966341.641097935 for keyspace/shard unsharded/- on tablet las-3964364658, concurrency: 4, compress: true, incrementalFromPos: auto"
unsharded/- (las-3964364658): time:{seconds:1774939272 nanoseconds:596217761} file:"builtinbackupengine.go" line:268 value:"auto evaluating incremental_from_pos"
unsharded/- (las-3964364658): time:{seconds:1774939272 nanoseconds:631295874} file:"builtinbackupengine.go" line:275 value:"auto evaluated incremental_from_pos: MySQL56/9c93a02f-08b9-11f1-a172-fe650f7ce9a4:1,c66ebebb-08b9-11f1-a145-2284636f0cc3:1-190711"
unsharded/- (las-3964364658): time:{seconds:1774939272 nanoseconds:634757440} file:"backup.go" line:187 value:"no new data to backup, skipping it"