# DirectAdmin Backups S3: Reliable Admin, Reseller and User Backups

Source: https://srvscripts.com/guides/directadmin-backups-s3/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

DirectAdmin has three separate backup systems that produce the same `.tar.gz` account archive but differ in who runs them, what they cover and where they can be sent. Understanding the split matters because the admin-level backup is the only one that covers every account and can be scheduled to a remote target, and none of the three includes the operating system or the panel’s own configuration. That last part is handled by the system backup described in [What changed in DirectAdmin system backups after sysbk](/guides/directadmin-system-backup-sysbk-1-709/).

In short: Admin backups cover every account and are the only level that schedules to a remote FTP or S3 target, reseller backups cover a reseller’s own users, and user backups are on-demand self-service exports.

**Short answer:** Admin backups cover every account and are the only level that schedules to a remote FTP or S3 target, reseller backups cover a reseller’s own users, and user backups are on-demand self-service exports. Schedule admin backups in Admin Level → Admin Backup/Transfer, choose FTP/FTPS or an S3-compatible endpoint, enable the day-of-week suffix for rotation and watch the first run in `/var/log/directadmin/system.log`. Restore whole accounts from the same page, or extract a single SQL dump or directory from the archive by hand.

## The three levels

**Admin Level → Admin Backup/Transfer** backs up any set of users on the server, including resellers and their users, to a local path or a remote FTP or S3 destination, on a schedule. Archives land in `/home/admin/admin_backups/` by default and are named `user.admin.username.tar.gz`, with the reseller name embedded when the user belongs to one. This is the one to use for disaster recovery and migrations.

**Reseller Level → Manage Reseller Backups** does the same for a reseller’s own users only, writing to `/home/<reseller>/user_backups/`. Resellers can schedule it and use remote FTP, which is useful when a reseller wants their own copies, but it duplicates data if the admin backup already runs.

**User Level → Create/Restore Backups** lets an individual user create an archive of their own account on demand, saved to `/home/<user>/backups/`. It is unscheduled and consumes the user’s own disk quota, so it is a self-service export rather than a backup strategy.

Since 1.687 all three include custom document roots for subdomains, which older archives missed. Each archive contains the home directory, databases as SQL dumps, mail, DNS zone, cron entries and the account’s configuration files, so it restores cleanly onto a different server of the same or newer DirectAdmin version.

## Scheduling admin backups to a remote target

In **Admin Level → Admin Backup/Transfer**, create a new schedule. Choose the users (all, or by reseller), set the cron time, and pick the destination. For FTP, enter the host, port, path, credentials and whether to use FTPS; DirectAdmin uploads each archive as it completes and removes the local copy when the upload succeeds. For S3-compatible storage, enter the endpoint, bucket, region and access keys; any provider that speaks the S3 API works, not only the original one.

Two settings on the schedule deserve attention. **Append day of week** or a similar suffix option keeps seven rotating copies instead of overwriting one; without it a corrupt backup overwrites the previous good one. And the choice of what to include lets you exclude mail or databases for a fast daily home-directory-only run, with a full run weekly.

The schedule is stored under `/usr/local/directadmin/data/admin/backup_crons.list` and executed through the task queue. Run one manually the first time from the same page and watch it:

```
tail -f /var/log/directadmin/system.log
ls -la /home/admin/admin_backups/
```

Remote uploads use a script in `/usr/local/directadmin/scripts/`; if you need a destination the panel does not offer, such as rsync over SSH or a different object store, the `custom/` directory under scripts allows a replacement upload hook. Check the script names in your build before writing one, and keep a copy outside the server.

## Restoring

Restore from the same admin page. Point it at the directory or remote location holding the archives, select the files, and choose the IP assignment (the original IP, or a new one when restoring to a different server). For a restore onto a live server where the account still exists, the restore overwrites it; DirectAdmin does not merge. If you only need a single file or database from an archive, extract it manually instead:

```
mkdir /root/extract && cd /root/extract
tar xzf /home/admin/admin_backups/user.admin.example.tar.gz backup/example.sql
```

Databases sit inside the archive under `backup/` as plain SQL, and the home directory under `domains/` and `.php` settings under `backup/` as well. Importing one SQL file with `mariadb example_db < backup/example_db.sql` is far safer than restoring a whole account to retrieve one table.

Restores across DirectAdmin versions work forwards but not backwards: an archive from 1.711 may include configuration keys a 1.690 server does not understand. Match or exceed the source version on the destination.

## Common pitfall: quotas and space

A full admin backup temporarily needs roughly the size of the largest account in free space on `/home` while the archive is built, plus the archive itself if the remote upload fails and the file stays local. A server at 90 percent disk fails silently in the middle of the night and the failure is only visible in **Admin Level → Message System**. Keep an eye on free space, and check the message system or `/var/log/directadmin/errortaskq.log` after every scheduled run for at least the first week.

## Verify

A backup that has never been restored is a hope, not a backup. At least monthly, pull one archive from the remote target and restore it to a staging server or a spare account name:

```
tar tzf user.admin.example.tar.gz | head
tar tzf user.admin.example.tar.gz | grep -c '\.sql$'
```

Confirm the archive lists the expected domains and that the SQL dumps are non-empty. Our [backup verify script](/scripts/backup-verify/) automates the integrity part — listing, size sanity and a test extraction — and can run from cron on the backup server so a truncated upload is noticed the same day rather than on the day you need it.

## DirectAdmin backups S3 at a glance

**Official documentation:** [DirectAdmin documentation](https://docs.directadmin.com/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [What changed in DirectAdmin system backups after sysbk was replaced (1.709) — and what you must add](https://srvscripts.com/guides/directadmin-system-backup-sysbk-1-709/) · [Exim, Dovecot or DirectAdmin still serving the old certificate after renewal](https://srvscripts.com/guides/directadmin-old-certificate-exim-dovecot/) · [Routing mail to Google Workspace or Microsoft 365 for a DirectAdmin-hosted domain (and the 1.703 MX check)](https://srvscripts.com/guides/directadmin-external-mail-workspace-m365/).

## Frequently asked questions

### Does a DirectAdmin admin backup include the operating system or panel configuration?

No. All three levels produce per-account archives only; the OS, DirectAdmin’s own configuration and CustomBuild settings need the separate system backup.

### How long does a full admin backup to S3 take?

It depends on account sizes and upload bandwidth; each archive is built locally and uploaded as it completes, so budget the tar time for the largest account plus transfer, and check the Message System after the first week of runs.

### Can I restore a DirectAdmin backup onto a server running an older version?

Not reliably. Archives restore forwards onto the same or a newer DirectAdmin version, but an archive from a newer release may contain configuration keys an older server does not understand, so match or exceed the source version.