Backup always starts immediately instead of given time V5.0.4

[DjoeC]

I am trying to run dbb daily @ 03:00, a "quiet" time for backups.

Environment: Docker, Raspberry Pi, SSD, daily offload of completed backups through Windows to offline storage.

Relevant Docker compose parameters:

      - BACKUP_JOB_CONCURRENCY=1     # Only run one job at a time
      - DEFAULT_CHECKSUM=NONE        # Don't create checksums
      - DEFAULT_COMPRESSION=zstd       # Compress all with ZSTD
      - DEFAULT_COMPRESSION_LEVEL=15   # Compress all with ZSTD
      - DEFAULT_BACKUP_INTERVAL=1440   # Backup every 1440 minutes
      - DEFAULT_BACKUP_BEGIN=0300      # Start backing up at 03:00
      - DEFAULT_CLEANUP_TIME=8640      # Cleanup backups after a week
      - DEFAULT_FILESYSTEM_PATH_PERMISSION=755
      - DEFAULT_FILESYSTEM_PERMISSION=655
      - DEFAULT_PARALLEL_COMPRESSION_THREADS=3

      - DB01_TYPE=mariadb
      - DB01_HOST=<mariadbhost>
      - DB01_NAME=ALL
      - DB01_USER=<dbbackupuser>
      - DB01_PASS=<dbbackuppass>
      - DB01_EXTRA_OPTS=--quick

      - DB02_TYPE=postgres
      - DB02_HOST=<postgreshost>
      - DB02_NAME=ALL
      - DB02_USER=<dbbackupuser>
      - DB02_PASS=<dbbackuppass>

I expect dbb to run daily @ 03:00. With V4 this was the case, now with V5 it runs once on starting the container - unexpected and not wanted but "survivable". Next run will not be at 03:00 next morning but 24 hours after the initial run.

HOW do I configure dbb properly to run each and every day at 03:00 and NOT automatically at startup? I must be overlooking something.....

[wmorin]

Set the begin time per job instead of through DEFAULT_. In 5.0.4 DEFAULT_BACKUP_BEGIN is never read, so every job falls back to +0 (start now) and then repeats every 1440 minutes from that moment:

      - DEFAULT_BACKUP_INTERVAL=1440
      - DB01_BACKUP_BEGIN=0300
      - DB02_BACKUP_BEGIN=0300

Or use a cron expression, which doesn't need the interval at all:

      - DB01_BACKUP_BEGIN=0 3 * * *
      - DB02_BACKUP_BEGIN=0 3 * * *

The cause is in container/rootfs/container/functions/10-dbbackup (line 621): the interval gets ${DEFAULT_BACKUP_INTERVAL} as fallback, but the begin value is hardcoded:

local begin="$(_dbbackup_getv "${inst}" BACKUP_BEGIN "+0")"

It only looks at DBxx_BACKUP_BEGIN (and DB_BACKUP_BEGIN / BACKUP_BEGIN for job 01), so your DEFAULT_BACKUP_BEGIN=0300 is silently dropped. Looks like a bug worth an issue.

I checked it with the 5.0.4 image and throwaway MariaDB and Postgres containers. With your settings the log shows schedule="start +0" msg="first run at 2026-09-28 11:31:38 (in 0s)", then next run in 24h0m0s. With DB01_BACKUP_BEGIN=0300 and DB02_BACKUP_BEGIN=0300 both jobs log schedule="at 03:00 then every 1440m" msg="first run at 2026-09-29 03:00:00 (in 15h29m24s)" and nothing runs at startup. The 0 3 * * * line gives the same first run at 03:00. I also set the begin a few minutes ahead (HHMM and cron) and it waited, fired on time, and scheduled the next run exactly 24h later.

One thing to check: the time is container local time, so set TZ or TIMEZONE (e.g. TZ=Europe/Amsterdam) if you haven't already, otherwise 0300 means 03:00 UTC.

Does that give you the 03:00 run again?

[DjoeC]

@wmorin
Thanks for your reply! Strange though as the docs explicitly say
**Every DB##* parameter above has a DEFAULT_* twin that applies to every job unless a job overrides it.**_
which would either indicate a bug in the software OR incorrect documentation......

Also, thanks for the remark about TZ. All my servers and my main workstation run UTC. Personal quirk ;)

I did add the cron version to both jobs which solved my problem:

[INFO] session=9dbeb1 action=scheduler msg="starting 2 jobs (concurrency=1)"
[INFO] session=9dbeb1 run_id=af9fe9c0 action=scheduler job=db02 status=starting schedule="cron 0 3 * * *" msg="first run at 2026-09-29 03:00:00 (in 14h33m8s)"
[INFO] session=9dbeb1 run_id=dcfbcfe3 action=scheduler job=db01 status=starting schedule="cron 0 3 * * *" msg="first run at 2026-09-29 03:00:00 (in 14h33m8s)"
2026-09-28.12:26:51 [STARTING] ** [scheduling] Starting cron

Now fix the other instances.....

[tiredofit]

#582 - I've turned this into an issue - this is indeed a bug in config generation on the the container. Fix details are there!