tiredofit / docker-db-backup

Backup multiple database types on a scheduled basis with many customizable options
MIT License
856 stars 125 forks source link

Can't schedule backup before 10:00 AM #373

Open williamwgant opened 1 week ago

williamwgant commented 1 week ago

Summary

When I set a DB_DUMP_BEGIN value without four digits (500), I get an error "_BACKUP_BEGIN is invalid - Unable to perform scheduling". If I set it to 0500, I get the same error. It doesn't seem to like the leading zero.

Steps to reproduce

  1. Do the normal setup for dbbackup configuration.
  2. Set the value for DB_DUMP_BEGIN to 0500 (or any other value before 10 AM)
  3. Start the container.

What is the expected correct behavior?

Should correctly schedule the backup and run the backup at the specified time.

Relevant logs and/or screenshots

Image:  tiredofit/db-backup | Version  4.1.4 Type 'image_changelog' for details
Repository/Documentation: https://github.com/tiredofit/docker-db-backup/
License: MIT | © 2024 Dave Conroy
If this image provides you value  - Consider sponsoring my work for continued 
development, timely updates, and feature requests. Commercial support available.
                    More Info:  https://www.tiredofit.ca
2024-09-27.13:22:27 [NOTICE] ** [monitoring] Container configured for monitoring with 'zabbix modern'
2024-09-27.13:22:28 [NOTICE] ** [scheduling] Container configured for scheduled tasks with 'cron'
2024-09-27.13:22:28 [NOTICE] ** [messaging] Container configured to route mail via SMTP to 'postfix-relay'
2024-09-27.13:22:29 [WARN] ** [db-backup01-scheduler] Deprecated and unsupported variable 'DB_DUMP_BEGIN' detected - Please upgrade your variables as they will be removed in version 4.3.0
2024-09-27.13:22:29 [WARN] ** [db-backup01-scheduler] Deprecated and unsupported variable 'DB_DUMP_FREQ' detected - Please upgrade your variables as they will be removed in version 4.3.0
2024-09-27.13:22:29 [STARTING] ** [monitoring] [1] Starting Zabbix Agent (modern) 7.0.2
2024-09-27.13:22:29 [WARN] ** [db-backup01-scheduler] Legacy unsupported variable 'CHECKSUM' detected - Please upgrade your variables as they will be removed in version 4.3.0
2024-09-27.13:22:29 [STARTING] ** [scheduling] [1] Starting cron
2024-09-27.13:22:29 [WARN] ** [db-backup01-scheduler] Legacy unsupported variable 'COMPRESSION' detected - Please upgrade your variables as they will be removed in version 4.3.0
2024-09-27.13:22:30 [WARN] ** [db-backup01-scheduler] Legacy unsupported variable 'SPLIT_DB' detected - Please upgrade your variables as they will be removed in version 4.3.0
2024-09-27.13:22:31 [ERROR] ** [01-db-gitea__gitea] _BACKUP_BEGIN is invalid - Unable to perform scheduling
        Valid Methods:
          +(number)             - Start in however many minutes
          HHMM                  - Start at hour (00-24) and minute (00-59)
          YYYY-MM-DD HH:mm:ss   - Start at a specific date and time
          0 23 * * *            - Cron expression
2024-09-27.13:22:31 [ERROR] ** [01-db-gitea__gitea] Stopping backup_scheduler 01 due to detected errors. Fix and restart container.

Environment

``` db-backup-gitea: container_name: db-backup-gitea hostname: db-backup-gitea image: tiredofit/db-backup links: - db-gitea depends_on: - db-gitea volumes: - /volume1/Backups/gitea:/backup labels: - "com.centurylinklabs.watchtower.enable=true" environment: TZ: America/Chicago DB_TYPE : mariadb DB_HOST : db-gitea DB_NAME : ${MYSQL_DATABASE} DB_USER : root DB_PASS : "${MYSQL_ROOT_PASSWORD}" DB_DUMP_FREQ : 1440 DB_DUMP_BEGIN : 345 DB_CLEANUP_TIME : 8640 CHECKSUM : SHA1 COMPRESSION : ZSTD SPLIT_DB : FALSE restart: unless-stopped networks: gitea: ```

Possible fixes

I suspect this is probably just a one-off parsing error. It may also be that I'm misunderstanding the error message.

rltas commented 19 hours ago

a) you may wanna update your legacy variables

b) time format is HHMM which is four digits

c) see https://github.com/tiredofit/docker-db-backup?tab=readme-ov-file#scheduling-options

You may need to wrap your DEFAULT_BACKUP_BEGIN value in quotes for it to properly parse. There have been reports of backups that start with a 0 get converted into a different format which will not allow the timer to start at the correct time.