# What changed in DirectAdmin system backups after sysbk was replaced (1.709) — and what you must add Source: https://srvscripts.com/guides/directadmin-system-backup-sysbk-1-709/ Updated: 2026-10-03 Publisher: srvScripts (https://srvscripts.com/) 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. In short: 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… **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](/guides/directadmin-backups-s3/). 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.conf ``` Set 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.log ``` Check 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.txt` on AlmaLinux, or `dpkg --get-selections` on Debian, and include the file in `sysbk.conf`. - **Database server configuration and binary logs.** `/etc/my.cnf` and `/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 d` or 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 `.env` files 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 50 ``` Anything 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](/scripts/backup-verify/) 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](https://docs.directadmin.com/), [Linux man pages](https://man7.org/linux/man-pages/). **Related guides:** [Admin, reseller and user backups in DirectAdmin: remote FTP/S3 targets and restores](https://srvscripts.com/guides/directadmin-backups-s3/) · [Certificate not renewing on DirectAdmin: reading the Provisioning History page and lego output](https://srvscripts.com/guides/directadmin-certificate-not-renewing/) · [Consolidate snapshots when ESXi reports “Virtual machine disks consolidation is needed”](https://srvscripts.com/guides/vm-disks-consolidation-needed-esxi/). ## 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.