Feature Request: Backup Schedules Support for vtctldclient #767
Description
Summary
VitessBackupSchedule currently only supports vtbackup. This feature request proposes adding support for vtctldclient as an alternative backup method, giving users the ability to choose which backend takes the backup.
Motivation
Both vtbackup and vtctldclient have distinct trade-offs. Neither is universally better — the right choice depends on cluster state, backup age, and workload characteristics.
vtbackup
| Pros | Cons |
|---|---|
| Shifts backup I/O off serving replicas | Requires a valid existing backup to bootstrap from |
| Avoids Online DDL table-lock failures during backup | If the primary purges binlogs aggressively, the existing backup may become invalid |
| If the last backup is stale and many binlogs have accumulated, vtbackup must fully catch up on replication lag before it can backup. During vttablet eviction (where the pod and PVC are deleted together), this blocks eviction indefinitely — and the backup itself may time out or become stale before it finishes |
vtctldclient
| Pros | Cons |
|---|---|
| Does not require an existing valid backup | Locks tables, which can cause Online DDL failures |
| Incremental backups only archive binlogs — no replication lag catch-up required | Runs on a serving replica, which may degrade read capacity during the backup |
Proposed Change
Add a backupMethod field to VitessBackupSchedule that allows users to select either vtbackup or vtctldclient per schedule. This gives operators the flexibility to:
- Use vtbackup for full backups on healthy clusters with recent backups
- Fall back to vtctldclient when the last backup is stale or replication lag catch-up would be prohibitively slow
Acceptance Criteria
- VitessBackupSchedule accepts a backupMethod field with values vtbackup and vtctldclient
- Both methods are fully functional end-to-end when triggered by a schedule
- Documentation updated to describe when to prefer each method