[Bug]: Dump silently fails on MySQL < 5.7 (`--default-character-set=utf8mb4` forced regardless of server version)

[edmc73]

DBackup Version

v3.3.0

Installation Method

Docker (docker-compose)

Bug Description

The dump job for this source fails every run with:

Dump failed: Dump file for MyDatabase is empty. Check logs/permissions.

The message points at permissions/logs, but the real cause is unrelated to either.

Root cause

Looking at the MySQL dialect selection logic (compiled bundle, so exact source location may differ, but the logic is clear):

getDialect(engine, version) {
  if (engine === "mariadb") return new MariaDbDialect
  if (version.includes("mariadb")) return new MariaDbDialect
  if (version.includes("5.7.")) return new Mysql57Dialect
  return new Mysql8Dialect   // <-- default fallback
}

class Mysql8Dialect extends BaseMysqlDialect {
  getDumpArgs(config, tables, extra) {
    const args = super.getDumpArgs(config, tables, extra)
    args.push("--default-character-set=utf8mb4")
    return args
  }
}

Any MySQL version that isn't literally MariaDB or doesn't contain "5.7." falls through to the MySQL 8.0 dialect, which unconditionally appends --default-character-set=utf8mb4. That includes 5.0, 5.1, 5.5 and 5.6.

utf8mb4 was only introduced in MySQL 5.5.3. Against a 5.1.66 server, the dump command fails outright because the server rejects the charset — mariadb-dump exits without producing output, which then surfaces as the generic "empty dump file" error instead of the actual charset incompatibility.

Steps to Reproduce

Connection mode ssh
Source DB engine: MySQL 5.1.66
Run a job database backup

Expected Behavior

I understand from the docs (docs.dbackup.app) that MySQL 5.7 is the documented minimum, so I'm not expecting full support for 5.1 out of the box. But two things would help a lot:

1. Surface the real problem. When the server version is below the supported floor (or below 5.5.3, if you want to be precise about the utf8mb4 boundary), it'd be great to fail fast with something like "MySQL 5.1.66 detected — minimum supported version is 5.7, dump arguments may be incompatible" instead of the generic "empty dump file / check permissions" message. That alone would have saved me a fair amount of debugging.

2. A low-effort escape hatch for people stuck on old MySQL (I know I'm not the only one running a legacy box that just can't be upgraded). The per-source "Dump options" field already exists and is appended into the command — but since --default-character-set=utf8mb4 is pushed after those custom options, it always wins even if someone tries to override it there. A tiny, low-risk change would fix that:

getDumpArgs(config, tables, extra) {
  const args = super.getDumpArgs(config, tables, extra)
  if (!config.options || !config.options.includes('--default-character-set')) {
    args.push("--default-character-set=utf8mb4")
  }
  return args
}

That's a one-condition change, doesn't touch dialect detection or add new UI, and it would let anyone on an old MySQL just add --default-character-set=utf8 (or nothing at all) in the existing "options" field to make dumps work again — without you having to officially support or test against 5.1/5.5/5.6.

Thanks for the great tool otherwise!

Logs / Error Output

08:37:35  INFO     Dumping database: MyDatabase
  [DETAILS]
  /usr/bin/mysqldump -h localhost -P 3306 -u root --net-buffer-length=16384 --single-transaction --quick --lock-tables=false --databases MyDatabase --default-character-set=utf8mb4
08:37:35  INFO     �mysqldump: Character set 'utf8mb4' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file
08:37:35  ERROR    Error: Dump file for MyDatabase is empty. Check logs/permissions.
08:37:35  ERROR    Dump failed: Dump file for MyDatabase is empty. Check logs/permissions.

Screenshots

No response

Environment

No response