[Enhancement] fix Misleading Backup Description and Retention Policy for `gbctl`

[opbot-xd]

Description

The gbctl backup command introduces two critical gaps for long-term deployments:

1. No Actual Volume Backup: Despite the help menu stating "Backup database and volumes", cmd_backup only dumps PostgreSQL. Docker volumes (mlmodels, static_content, logs) are ignored; only their names are exported to a text file.
2. Missing Backup Retention: Running ./gbctl backup via cron creates a new .sql.gz dump every time, potentially filling up the host's disk space over time. There is currently no built-in cleanup or retention policy to prune old backups.

Proposed Solution

1. Either we can simply update print_help() function or should we implement backup of volumes (which I dont think we need).
2. Add Retention Flag: Introduce a --keep-days <N> flag to automatically prune old backups (e.g., find backups/ -type f -mtime +N -delete).

[Abhijeet17o]

HI @opbot-xd ! I saw the current implementation.

Currently:

• The cmd_backup() function only dumps the PostgreSQL database to .sql.gz
• Volumes info is just saved as a list of names in a .txt file, not actual volume data
• There's no retention or cleanup mechanism

I think your solution is the right approach cuz:

1. It currently says "Backup database and volumes" which is misleading. We should update it to "Backup database (PostgreSQL)" or "Backup database dump" to be accurate.

2. Adding --keep-days flag is essential for production deployments. The flag would auto-prune .sql.gz files older than N days using something like find backups/ -type f -name "*.sql.gz" -mtime +N -delete.

3. I feel volume backup may go out of scope for this (will have to see what @regulartim suggests) because:

   • Actual volume backups are complex (would need to stop containers, tar volume data, etc.)
   • The critical data is already protected via PostgreSQL dumps
   • Logs and static content can be regenerated
   • Users needing volume backups can use Docker's native backup solutions or orchestration tools

So here is the approach:

• Update help text for accuracy
• Add --keep-days flag with retention logic
• Add basic tests

@regulartim if it’s okay, I’d be glad to work on this. Could you assign it to me?

[regulartim]

Hey @opbot-xd ! Thanks for bringing this up! :)

Either we can simply update print_help() function or should we implement backup of volumes (which I dont think we need).

Updating the help text is better here, I think. Volume backups are not needed right now.

Add Retention Flag: Introduce a --keep-days flag to automatically prune old backups (e.g., find backups/ -type f -mtime +N -delete).

What do you think about a --keep <N> flag that prunes everything but the latest N backups? Would that be more flexible?

[Abhijeet17o]

Hi @regulartim , thanks. I agree that updating the help text is the right fix here, and I’d rather go with a --keep-days <N> flag than trying to back up Docker volumes.

The backups are already timestamped PostgreSQL dumps, so the main issue is old files piling up over time. Age-based cleanup feels simpler and more useful here.

[regulartim]

Alright, @Abhijeet17o , I'll assign you!