✅ How to Fix ISPConfig Manual SQL Backup Not Working (While Auto Backup Works)

Problem Overview

In ISPConfig 3.3 multi‑server setups, you may encounter the following issue:

  • ✅ Scheduled (Automatic) SQL backups work normally
  • ❌ Manual SQL backup does nothing
  • ❌ No error message appears
  • ❌ No backup folder is created
  • ✅ Some websites may work, others do not

This behavior can be confusing because everything seems healthy — but manual backups simply don’t trigger.

This article explains the root cause and provides the permanent fix.


Why This Happens

ISPConfig handles backups differently:

✅ Automatic Backup

Runs locally on the SQL server via cron and does not rely on datalog synchronization.

❌ Manual Backup

Uses this flow:

  1. The ISPConfig UI writes a task into sys_datalog (on the Master server)
  2. The SQL server reads the datalog entry
  3. server.sh processes the task
  4. Backup runs

If the datalog entry cannot be properly written or transmitted, the manual backup will silently fail.


The Real Cause: max_allowed_packet Too Small

In most cases, the issue is caused by a MariaDB configuration problem:

max_allowed_packet

On Debian 12/13 and many CentOS installs, the default is:

16M

In some cases, even:

1M

That is too small for ISPConfig 3.3 multi‑server environments.

Why?

Because sys_datalog may contain:

  • SSL certificate blobs
  • Large JSON configuration data
  • Backup metadata
  • Website configuration structures

If a datalog record exceeds max_allowed_packet, MariaDB silently rejects the transfer.

Result:

  • Small websites → manual backup works
  • Larger websites → manual backup does nothing
  • Auto backup still works

How to Check Your Current Value

Run on BOTH Master and SQL server:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

If you see:

16777216  (16M)

or smaller → this is your problem.


✅ The Permanent Fix (Debian 13 / MariaDB 10.11+)

Step 1 — Edit MariaDB Configuration

On Debian 13, edit:

/etc/mysql/mariadb.conf.d/50-server.cnf

Find the [mysqld] section and set:

max_allowed_packet = 256M
wait_timeout = 300
interactive_timeout = 300

Save the file.


Step 2 — Restart MariaDB

systemctl restart mariadb

Verify:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

You should now see:

268435456

Step 3 — Reset Stuck Datalog Entries

On the Master server:

mysql -u root -p dbispconfig

Run:

UPDATE sys_datalog SET processing = 0;

Then on the SQL server:

/usr/local/ispconfig/server/server.sh

After Fixing

Manual SQL backups should now:

  • ✅ Work for all websites
  • ✅ Create backup folders immediately
  • ✅ No longer silently fail

Why 256M Is Recommended

For ISPConfig multi‑server setups:

SettingRecommended Value
max_allowed_packet256M
wait_timeout300
interactive_timeout300

256M ensures large SSL or configuration payloads do not break datalog synchronization.


Important Notes

✅ You must update BOTH Master and SQL servers
✅ Restart MariaDB after changes
✅ Clear stuck datalog entries

If you only update one server, the problem may persist.


Final Thoughts

If you see:

  • Manual SQL backup does nothing
  • No error in UI
  • Auto backup works
  • Some sites succeed, others fail

The issue is almost certainly MariaDB’s max_allowed_packet.

Increasing it to 256M resolves the problem permanently in almost all ISPConfig 3.3 multi‑server environments.