Description
When DB0X_SPLIT_DB=FALSE (the default, used for combined "ALL databases" dumps),
the MySQL/MariaDB backup command silently produces an empty output file instead
of a real dump.
Root cause
In rootfs/container/functions/10-dbbackup, the dump command differs between
the two DB0X_SPLIT_DB code paths:
SPLIT_DB=TRUE (per-database dump, line ~620):
${_mysql_prefix}${_mysqldump_bin} ... — correct.
SPLIT_DB=FALSE (combined "ALL" dump, line ~641):
${_mysql_prefix}${mysqldump_bin} ... — missing the leading underscore.
_mysqldump_bin (with underscore) is the variable actually set earlier in the
client-selection block (mariadb-dump or mysqldump, depending on
DB0X_MYSQL_CLIENT). mysqldump_bin (without underscore) is never assigned
anywhere in the image. In the SPLIT_DB=FALSE branch it therefore expands to
an empty string, so the command that actually runs is just
${_mysql_prefix} (e.g. /usr/bin/ or /opt/mysql/bin/) with all the dump
flags as arguments - which fails immediately and produces zero stdout. That
gets piped into the compression step regardless, so the job "succeeds" and
writes a tiny (e.g. 13-byte) file that looks like a valid but empty backup -
no error is surfaced at the top level.
Steps to reproduce
- Run the container against any MySQL or MariaDB server with:
DB01_TYPE=mysql (or mariadb)
DB01_NAME=ALL
DB01_SPLIT_DB=FALSE (or unset, since FALSE is the default)
- valid
DB01_HOST/DB01_USER/DB01_PASS
- Let the backup job run (
MODE=MANUAL, backup-now, or the scheduler).
- Inspect the resulting
.sql.zst/.sql.gz file in the backup location.
Expected
A real SQL dump of all databases.
Actual
A near-empty file (just the compression format's empty-stream header, e.g.
13 bytes for zstd) - mysqldump/mariadb-dump was never actually invoked.
Suggested fix
In the SPLIT_DB=FALSE branch, change:
${_mysql_prefix}${mysqldump_bin}
to:
${_mysql_prefix}${_mysqldump_bin}
matching the SPLIT_DB=TRUE branch above it.
Environment
- Image: docker.io/nfrastack/db-backup
- Confirmed via source inspection against the current default branch.
Description
When
DB0X_SPLIT_DB=FALSE(the default, used for combined "ALL databases" dumps),the MySQL/MariaDB backup command silently produces an empty output file instead
of a real dump.
Root cause
In
rootfs/container/functions/10-dbbackup, the dump command differs betweenthe two
DB0X_SPLIT_DBcode paths:SPLIT_DB=TRUE(per-database dump, line ~620):${_mysql_prefix}${_mysqldump_bin} ...— correct.SPLIT_DB=FALSE(combined "ALL" dump, line ~641):${_mysql_prefix}${mysqldump_bin} ...— missing the leading underscore._mysqldump_bin(with underscore) is the variable actually set earlier in theclient-selection block (
mariadb-dumpormysqldump, depending onDB0X_MYSQL_CLIENT).mysqldump_bin(without underscore) is never assignedanywhere in the image. In the SPLIT_DB=FALSE branch it therefore expands to
an empty string, so the command that actually runs is just
${_mysql_prefix}(e.g./usr/bin/or/opt/mysql/bin/) with all the dumpflags as arguments - which fails immediately and produces zero stdout. That
gets piped into the compression step regardless, so the job "succeeds" and
writes a tiny (e.g. 13-byte) file that looks like a valid but empty backup -
no error is surfaced at the top level.
Steps to reproduce
DB01_TYPE=mysql(ormariadb)DB01_NAME=ALLDB01_SPLIT_DB=FALSE(or unset, since FALSE is the default)DB01_HOST/DB01_USER/DB01_PASSMODE=MANUAL,backup-now, or the scheduler)..sql.zst/.sql.gzfile in the backup location.Expected
A real SQL dump of all databases.
Actual
A near-empty file (just the compression format's empty-stream header, e.g.
13 bytes for zstd) -
mysqldump/mariadb-dumpwas never actually invoked.Suggested fix
In the
SPLIT_DB=FALSEbranch, change:to:
matching the
SPLIT_DB=TRUEbranch above it.Environment