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:
- The ISPConfig UI writes a task into
sys_datalog(on the Master server) - The SQL server reads the datalog entry
server.shprocesses the task- 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:
| Setting | Recommended Value |
|---|---|
| max_allowed_packet | 256M |
| wait_timeout | 300 |
| interactive_timeout | 300 |
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.