How does the DB_DUMP_RETENTION option work?

[francescotau]

Maybe I'm wrong, but I expected that setting DB_DUMP_RETENTION="2c" would keep at most two backup files. Instead, a new file is created at each iteration and the previous ones are not deleted. What am I missing? Thanks.

[deitch]

Correct, that is what it should do. There was an issue a while back where it was missing it, but it was fixed (cannot recall the PR offhand). If you are having an issue, please:

1. Post your entire config (be careful to remove sensitive data like passwords)
2. Enable debug (DB_DEBUG=true or --debug=true) and post the messages (again, be careful to remove sensitive data)

[francescotau]

compose.yaml

version: "3"

services:
  database:
    image: mysql:8.3
    restart: unless-stopped
    env_file:
      - path: ./.env
    ports:
      - "3306:3306"
    volumes:
      - ./volumes:/var/lib/mysql
    networks:
      - db-net

  backup:
    image: databack/mysql-backup
    restart: unless-stopped
    env_file:
      - path: ./.env
    depends_on:
      - database
    volumes:
      - ./backup:/backup
    networks:
      - db-net

networks:
  db-net:
    driver: bridge

.env

# database
MYSQL_ROOT_PASSWORD="secret"

# backup
DB_SERVER="database"
DB_PORT="3306"
DB_USER="root"
DB_PASS="secret"
DB_DUMP_FREQ="1"
DB_DUMP_BEGIN="+1"
DB_DUMP_TARGET="/backup"
DB_DUMP_SAFECHARS="true"
DB_DUMP_RETENTION="2c"

[deitch]

database
MYSQL_ROOT_PASSWORD="secret"

May I suggest a harder-to-guess root password than "secret"? 😆

[deitch]

I ran some tests, and I see it working.

$ DB_DUMP_RETENTION=2c go run . dump -v 2 --target file:///tmp/backup --user user --pass pass --server localhost --port 3306 --frequency 1
DEBU[0000] starting dump
INFO[0000] beginning dump 2025-07-04T14:02:49Z           run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] uploading via protocol file from db_backup_2025-07-04T14:02:49Z.tgz to db_backup_2025-07-04T14:02:49Z.tgz  run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] completed copying 1344 bytes                  run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
INFO[0000] beginning prune                               run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] pruning target file:///tmp/backup             run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] checking filename that is standard backup pattern: db_backup_2025-07-04T14:01:27Z.tgz  run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] checking filename that is standard backup pattern: db_backup_2025-07-04T14:02:27Z.tgz  run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] checking filename that is standard backup pattern: db_backup_2025-07-04T14:02:49Z.tgz  run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] Adding candidate file db_backup_2025-07-04T14:01:27Z.tgz:  run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
DEBU[0000] pruning 1 files from target file:///tmp/backup  run=ffed86fd-0f60-4f2f-bdb4-c5e0ae4499e8
INFO[0060] beginning dump 2025-07-04T14:03:49Z           run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] uploading via protocol file from db_backup_2025-07-04T14:03:49Z.tgz to db_backup_2025-07-04T14:03:49Z.tgz  run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] completed copying 1344 bytes                  run=f241e097-269f-4058-8510-d4d2458e7a4a
INFO[0060] beginning prune                               run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] pruning target file:///tmp/backup             run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] checking filename that is standard backup pattern: db_backup_2025-07-04T14:02:27Z.tgz  run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] checking filename that is standard backup pattern: db_backup_2025-07-04T14:02:49Z.tgz  run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] checking filename that is standard backup pattern: db_backup_2025-07-04T14:03:49Z.tgz  run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] Adding candidate file db_backup_2025-07-04T14:02:27Z.tgz:  run=f241e097-269f-4058-8510-d4d2458e7a4a
DEBU[0060] pruning 1 files from target file:///tmp/backup  run=f241e097-269f-4058-8510-d4d2458e7a4a

(Don't worry about the credentials, this is a local test database in a container)

Do you see where it scans the various files and checks the pattern?

Let's see what you get if you run it with debug. Try setting DB_DEBUG=true and run it, let's see the outcome. In the meantime, you are using just databack/mysql-backup, which implies the latest tag. I have disliked that since the beginning of docker, but it is there and people use it. In this case, it implies the most recent semver, which is v1.2.2. I will check out that particular commit and run it, see if there are any discrepancies.

[deitch]

Nope, I checked it out, no issue. There were issues in the past, but those are from well before v1.2.2.

Try running with debug, let's see what the log messages say?

[francescotau]

database
MYSQL_ROOT_PASSWORD="secret"

May I suggest a harder-to-guess root password than "secret"? 😆

It's just a sample value 🤣 No production database is running with that password

[github-actions]

This issue has been automatically marked as stale due to inactivity.