For many years DirectAdmin servers had a system-level backup script called sysbk that archived /etc, the panel’s configuration and a few other directories to a local path or remote host. In 1.709 it was retired and replaced by a system backup built into the panel, configured from /usr/local/directadmin/data/admin/sysbk.conf and the Evolution interface. The change is welcome because sysbk was a shell script with a long list of hard-coded paths, but the new backup has a narrower scope than some administrators expect, and a server that relies on it alone is not recoverable.
Applies to DirectAdmin 1.709 and later
Table of Contents
Short answer: The 1.709 system backup archives panel, CustomBuild, mail, DNS, web-server, TLS, CSF and cron configuration according to the include list in /usr/local/directadmin/data/admin/sysbk.conf, but not user homes, mailboxes or databases, which remain the job of the admin-level backups. Review the destination and schedule in that file, add any paths the old sysbk had been customised to include, and keep both backup types off-server with a tested restore procedure.
What the new system backup covers
The built-in backup captures what you need to rebuild the server’s configuration on a fresh install: /usr/local/directadmin/conf/ and data/ (including all admin, reseller and user configuration, templates and custom templates), the CustomBuild options.conf and custom/ directory, Exim, Dovecot, Rspamd or SpamAssassin, named and web-server configuration under /etc and /usr/local/lsws/conf as appropriate, TLS certificates and ACME account data, CSF configuration, and the cron tables. The exact list is in sysbk.conf, and it is intentionally editable so you can add paths.
What it does not include is the substance: user home directories, mailboxes and databases. These are covered by the admin-level backups described in Admin, reseller and user backups. The system backup is the complement to those, not a replacement, and the two together are the minimum for a full restore.
Configuring it
The settings file is plain key-value. Open it and review at least the destination and schedule:
cat /usr/local/directadmin/data/admin/sysbk.confSet a local path with enough space, or a remote FTP/S3 destination using the same fields as the admin backup schedules, and pick a time that does not collide with the admin backup run, because both compress heavily and running them together doubles the I/O spike. The backup is executed by the task queue, so it inherits the same logging: successes and failures appear in Admin Level → Message System and in /var/log/directadmin/system.log.
If you had customised the old sysbk to include extra directories — a custom scripts folder, an application deployed outside /home, a Redis dump directory — those additions did not carry across. Add each path to the include list in sysbk.conf. Anything not listed is not backed up, and there is no warning.
To run it immediately rather than waiting for the schedule, trigger it from the admin interface or queue the task:
echo "action=backup&type=system" >> /usr/local/directadmin/data/task.queue
tail -f /var/log/directadmin/system.logCheck the changelog for your build if the queue syntax differs; the action name was documented with 1.709.
What you must add yourself
The system backup and the admin backups together still leave gaps that a serious hosting operation closes separately.
- Operating system packages and kernel state. Neither backup records the installed package list. Dump it daily so a rebuild can reinstall the same packages:
rpm -qa --qf '%{NAME}\n' | sort > /root/pkglist.txton AlmaLinux, ordpkg --get-selectionson Debian, and include the file insysbk.conf. - Database server configuration and binary logs.
/etc/my.cnfand/etc/my.cnf.d/should be in the system backup include list. If you use binary logs for point-in-time recovery, they need their own copy job; the admin backup takes a logical dump per account, not the binlogs. - Off-server copies. A backup on the same disk is a convenience, not protection. Push both backup types to a remote target, and keep at least one copy that the server cannot delete or overwrite (object-lock on S3, or a pull-based rsync from the backup host).
- A restore procedure. Write down the order: install the OS, install DirectAdmin with the same license, restore the system backup, run
./build all dor the targeted rebuilds to regenerate service configuration, then restore the admin backups. Test it on a throwaway VM once so the notes reflect reality. - Secrets that live outside the panel. API keys in
/root/, SSH host keys if you want clients not to see a changed fingerprint, and any application.envfiles outside user homes.
Common pitfall: trusting the message system alone
The message system tells you a backup ran, not that it is usable. A backup that succeeds while silently excluding a path you forgot to add reports success every night. Once a quarter, unpack the latest system backup on a test machine and diff the file list against the live server’s /etc:
tar tzf system-backup.tar.gz | sed 's#^./##' | sort > /tmp/inbackup.txt
find /etc /usr/local/directadmin/conf /usr/local/directadmin/data -type f | sed 's#^/##' | sort > /tmp/live.txt
comm -13 /tmp/inbackup.txt /tmp/live.txt | head -n 50Anything in the third column is on the server and not in the backup. Some of it will be noise, and some of it will be the file you would have needed.
Keep it running
Schedule the system backup nightly and the admin backup nightly or weekly according to how much data you can afford to lose, and confirm both offsite. Run our backup verify script on the receiving host so a missing or truncated archive raises an alert the same day. After every DirectAdmin update, glance at sysbk.conf — the include list is not overwritten by updates, but new configuration directories introduced by a release (the ACME account store from 1.706 is a recent example) are only picked up if the default list in that release adds them or you do.
DirectAdmin system backup at a glance
Official documentation: DirectAdmin documentation, Linux man pages.
Related guides: Admin, reseller and user backups in DirectAdmin: remote FTP/S3 targets and restores · Certificate not renewing on DirectAdmin: reading the Provisioning History page and lego output · Consolidate snapshots when ESXi reports “Virtual machine disks consolidation is needed”.
Frequently asked questions
Does the DirectAdmin system backup include user websites and databases?
No. It captures configuration only; home directories, mailboxes and MySQL or MariaDB databases are covered by the admin, reseller and user backups, and a full restore needs both types.
How long does the system backup take to run?
Usually a few minutes, because it archives configuration directories measured in megabytes rather than user data; the time grows with the number of custom paths added to sysbk.conf and with a slow remote destination.
Can I undo this?
There is nothing to reverse in the backup itself, but the retired sysbk script is not restored by any update; a server that needs the old behaviour must reproduce its extra paths in sysbk.conf, and a mis-set destination or schedule is simply corrected in the same file.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- DirectAdmin 1.709 and later
- Last full review
- Next review
- Sources
- docs.directadmin.com