DirectAdmin backup configuration tutorial (2026): Automated backups to S3/SSH with retention and restore verification

A backup that only lives on the same server isn’t a real backup. On a VPS or dedicated box, you need three things: automation you can trust, storage that lives somewhere else, and a restore routine you can run without improvising.

This DirectAdmin backup configuration tutorial shows how to schedule reliable backups (accounts plus a small system snapshot). You’ll copy them off-server, enforce retention, and confirm restores actually work.

The steps assume DirectAdmin on AlmaLinux/Rocky Linux 9/10 or Debian/Ubuntu. You’ll need root access, plus a working hostname and DNS.

If you host client sites, treat this as baseline ops. It’s not a “nice to have.”

DirectAdmin backup configuration tutorial: what you’ll build

By the end, you’ll have:

Nightly automated backups (user accounts + databases + email + DNS) from DirectAdmin
Optional “system-level” coverage for config files that aren’t inside user backups
Remote copies to either an SSH backup box or S3-compatible object storage
Retention rules (daily/weekly) that don’t fill your disk
A restore verification workflow (single account + single database + file spot checks)

If you’re still choosing where to run DirectAdmin, backup speed depends mostly on disk I/O and network throughput.

A HostMyCode VPS gives predictable disk performance for compression and quicker uploads. That helps keep the backup window short.

Prerequisites and sizing: don’t start with a full disk

Before you touch any settings, check three things: free space, inodes, and where DirectAdmin stages archives.

Many setups build the backup locally first. Only then do they transfer it.

1) Quick disk and inode check

df -h

df -i

du -sh /home 2>/dev/null

Keep at least 20–30% free on the filesystem that holds /home (or wherever your user data lives).

If you’re already close to the line, expand storage first. Or move the staging directory to a larger volume.

2) Confirm DirectAdmin paths and backup directory

Common locations:

User data: /home/*
DirectAdmin config: /usr/local/directadmin/
Backups: often under /home/admin/admin_backups/ or a directory you set

Log into DirectAdmin as admin (or reseller, depending on your role). Then locate the backup settings.

In most installs it’s under Admin Level → Admin Backup/Transfer. The label may vary slightly by theme.

3) Know what DirectAdmin backups include (and what they don’t)

DirectAdmin account backups usually include:

Website files under the user
Databases (MySQL/MariaDB dumps)
Email accounts and mailboxes
DNS zone files for the user’s domains
SSL certificates stored within the account context (varies by setup)

They usually do not cover critical system items like:

Custom Nginx/Apache templates or system vhost overrides
Firewall rules (nftables/iptables) and fail2ban jails
System crontabs, custom systemd units
DirectAdmin global config and license-related settings

That’s why you’ll add a small “system config snapshot” later. This is not a full image backup.

It captures the pieces you don’t want to rebuild from memory.

Configure DirectAdmin scheduled backups (accounts + services)

Keep the first schedule simple. Nightly is the default for shared hosting and WordPress.

If you run high-change apps (ecommerce, membership sites), add another run. Also consider app-level exports for data you can’t afford to lose.

Step 1: Choose backup mode and scope

In DirectAdmin’s backup interface:

Select all user accounts (or start with one to validate)
Include: Domains, Subdomains, Email, Databases, DNS, FTP, SSL (as available)
Choose compressed archives to reduce transfer size (CPU cost increases)

If backups spike CPU, move them to the quietest hours. Keep worker counts sane.

On WordPress-heavy nodes, PHP-FPM tuning often decides whether backups are “invisible” or painful.

See PHP-FPM performance tuning if your backup window overlaps with real traffic.

Step 2: Set a local staging directory

Choose a local directory that isn’t inside any user’s web root. This is a common, clean default:

mkdir -p /var/backups/directadmin
chmod 700 /var/backups/directadmin

Set DirectAdmin to write archives there (if your UI supports selecting a path).

If the UI doesn’t expose it, confirm the default location. Make sure it has headroom.

Step 3: Schedule automation

Use DirectAdmin’s scheduler if it’s available. It’s usually the least fragile option across upgrades.

If you prefer tighter control, you can trigger backups via cron using DirectAdmin’s tools. Commands vary by version and method.

Either way, aim for:

Nightly backups at a fixed time (e.g., 02:15 server time)
Limit concurrent jobs if the server is small (2 vCPU/4GB RAM class)

Remote storage option A: push backups to an SSH backup server (rsync)

An SSH backup box is straightforward. You get normal files, normal permissions, and easy auditing.

For large tarballs, it’s often faster than object storage. It’s also simpler to reason about.

Step 1: Create a restricted backup user on the remote server

On the backup server:

adduser --disabled-password --gecos "" da-backup
mkdir -p /srv/backups/directadmin
chown da-backup:da-backup /srv/backups/directadmin
chmod 750 /srv/backups/directadmin

Step 2: Generate an SSH key on the DirectAdmin server

ssh-keygen -t ed25519 -a 64 -f /root/.ssh/da_backup_key -C "directadmin-backup"

Copy the public key to the backup server:

ssh-copy-id -i /root/.ssh/da_backup_key.pub da-backup@BACKUP_SERVER_IP

If you’re tightening SSH at the same time, align this with your hardening rules.

Use key-only auth and allowlists where possible. This pairs well with SSH key login basics.

Step 3: Rsync backups off-server after each run

Create a script on the DirectAdmin server: /usr/local/sbin/da-backup-sync.sh

nano /usr/local/sbin/da-backup-sync.sh

#!/bin/sh
set -eu

LOCAL_DIR="/var/backups/directadmin"
REMOTE_USER="da-backup"
REMOTE_HOST="BACKUP_SERVER_IP"
REMOTE_DIR="/srv/backups/directadmin/$(hostname -s)"
SSH_KEY="/root/.ssh/da_backup_key"

# Create remote host folder
ssh -i "$SSH_KEY" -o BatchMode=yes -o StrictHostKeyChecking=accept-new \
  ${REMOTE_USER}@${REMOTE_HOST} "mkdir -p '$REMOTE_DIR'"

# Sync archives
rsync -a --delete --info=stats2 \
  -e "ssh -i $SSH_KEY -o BatchMode=yes" \
  "$LOCAL_DIR/" "${REMOTE_USER}@${REMOTE_HOST}:$REMOTE_DIR/"

chmod 700 /usr/local/sbin/da-backup-sync.sh

Add a cron entry that runs after the DirectAdmin backup job finishes (example: 03:30):

crontab -e

30 3 * * * /usr/local/sbin/da-backup-sync.sh >> /var/log/da-backup-sync.log 2>&1

Retention on SSH storage (simple and predictable)

Retention is easiest if you store backups in date-based folders.

If DirectAdmin drops everything into a single directory, you have two common options:

Copy each day into a dated folder before the --delete sync runs
Don’t delete in rsync, then prune on the backup server by age

Example pruning files older than 21 days (be careful):

find /srv/backups/directadmin -type f -name "*.tar.gz" -mtime +21 -delete

Remote storage option B: copy to S3-compatible storage (rclone)

If you want object storage (S3 or S3-compatible), rclone is the practical tool in 2026.

It handles retries, bandwidth caps, and integrity checks. You don’t need to babysit a custom script.

Step 1: Install rclone

curl -fsSL https://rclone.org/install.sh | bash
rclone version

Step 2: Configure an S3 remote

rclone config

Choose:

Storage: S3
Provider: AWS or other S3-compatible provider
Set access key and secret key
Pick a region and endpoint (if non-AWS)

Step 3: Encrypt before upload (recommended)

If you don’t fully control provider-side encryption policy, add rclone crypt.

That way the bucket only stores encrypted data. This still helps even if credentials leak later.

rclone config

Create a crypt remote pointing to s3:your-bucket/directadmin.

Step 4: Upload with retention-friendly structure

Use a date-based prefix. It makes pruning predictable.

It also keeps “daily vs weekly” organization sane.

Create /usr/local/sbin/da-backup-s3.sh:

nano /usr/local/sbin/da-backup-s3.sh

#!/bin/sh
set -eu

LOCAL_DIR="/var/backups/directadmin"
REMOTE="crypt:directadmin"
HOST="$(hostname -s)"
DATE="$(date +%F)"

# Upload today's set
rclone copy "$LOCAL_DIR" "$REMOTE/$HOST/daily/$DATE" \
  --checksum \
  --transfers 4 \
  --checkers 8 \
  --log-file /var/log/da-backup-s3.log \
  --log-level INFO

# Keep only 21 daily folders
rclone lsf "$REMOTE/$HOST/daily" --dirs-only | sort | head -n -21 | while read -r old; do
  [ -n "$old" ] && rclone purge "$REMOTE/$HOST/daily/$old"
done

chmod 700 /usr/local/sbin/da-backup-s3.sh

Schedule it after the backup run:

15 4 * * * /usr/local/sbin/da-backup-s3.sh

On smaller VPS plans, cap bandwidth so uploads don’t steal capacity from web traffic:

rclone copy ... --bwlimit 20M

Add a small “system config snapshot” (fills the coverage gaps)

Keep this small on purpose. You’re not trying to reproduce the entire machine.

You’re capturing the files that save hours during a rebuild.

What to include

/usr/local/directadmin/conf/
Web server configs: /etc/nginx/ and/or /etc/httpd/ (or /etc/apache2/)
TLS automation: Let’s Encrypt hooks or ACME client configs, if used
Firewall rules: /etc/nftables.conf or saved iptables rules
Cron definitions: /etc/cron.d/ and root crontab

Create a tarball and ship it with the rest

cat > /usr/local/sbin/da-system-snapshot.sh <<'EOF'
#!/bin/sh
set -eu
OUT_DIR="/var/backups/directadmin/system"
mkdir -p "$OUT_DIR"
FILE="$OUT_DIR/system-$(hostname -s)-$(date +%F).tar.gz"

tar -czf "$FILE" \
  /usr/local/directadmin/conf \
  /etc/nginx /etc/httpd /etc/apache2 \
  /etc/cron.d \
  /etc/nftables.conf \
  /var/spool/cron 2>/dev/null || true

# Keep 14 local snapshots
ls -1t "$OUT_DIR"/*.tar.gz 2>/dev/null | tail -n +15 | xargs -r rm -f
EOF

chmod 700 /usr/local/sbin/da-system-snapshot.sh

Schedule it to run before your remote sync/upload:

55 2 * * * /usr/local/sbin/da-system-snapshot.sh

Restore verification: do a controlled test (not a panic restore)

You don’t want your first restore attempt to happen during an outage.

Test monthly. Test again after major upgrades or migrations.

Step 1: Pick a test account and define success

Choose one real customer account with a typical WordPress site
Success means: site files restore, database imports cleanly, and wp-admin loads
Also verify at least one mailbox exists and can be accessed (IMAP login)

Step 2: Restore into a staging VPS (recommended)

Don’t run restore tests on your production node.

Spin up a small staging server, restore one account, then validate.

If you want a clean environment quickly, use a separate managed VPS hosting instance for staging. It keeps production out of the blast radius while you confirm the process end to end.

Step 3: Validate DNS and SSL expectations

For staging restores, you typically don’t want to change public DNS.

Map the domain to the staging IP in /etc/hosts on your workstation. Then browse the site as if it were live.

For real cutovers, plan TTL and rollback before you touch anything.

HostMyCode’s guide on DNS propagation planning is the right workflow to follow.

Step 4: Log the restore in a checklist

Write down what happened each time you test. You’ll thank yourself later.

Date, backup set used, restore duration
Errors (missing database dump, permission issues, mail restore gaps)
Action items (fix excludes, increase disk, adjust schedule)

Troubleshooting: the problems you’ll actually hit

Most backup failures come from mundane causes: no space, wrong path, permissions, or saturated CPU.

The upside is that these are usually quick fixes.

Problem: Backups fail mid-run or create tiny archives

Check disk and inodes again: df -h, df -i
Look for permission errors in DirectAdmin logs
Confirm the staging path is writable by the DirectAdmin backup process

Problem: Server slows down badly during compression

Move the schedule to a quieter hour
Lower concurrency (fewer parallel backups)
Upgrade CPU on your VPS if you’re compressing many accounts nightly

If the symptom is “everything is slow,” line it up with metrics during the backup window.

Netdata is a solid starting point. Follow server monitoring with Netdata and watch CPU steal, disk wait, and RAM pressure.

Problem: Remote sync succeeds, but restores are missing data

Make sure databases are included in the DirectAdmin backup set
Verify you’re not syncing the wrong directory (common after changing paths)
For rsync, avoid --delete until you confirm your upstream archive layout
Run checksums on a sample file before and after transfer

Problem: You can’t reach the backup server over SSH

Confirm outbound firewall allows TCP/22 (or your custom port)
Verify the key path and permissions: chmod 600 /root/.ssh/da_backup_key
Test interactive connection: ssh -i /root/.ssh/da_backup_key da-backup@BACKUP_SERVER_IP

If a firewall change locked you out of services, roll changes back methodically.

See firewall troubleshooting for a safe recovery approach.

Operational checklist: keep it reliable month after month

Daily: confirm backup job ran (check log file sizes and last-run timestamps)
Weekly: spot-check one account archive; confirm it contains a DB dump and files
Monthly: restore one account into staging and validate login + site load
Quarterly: review retention against storage cost and compliance needs
After big changes: re-test (PHP upgrades, DirectAdmin updates, web stack swaps)

Summary: a backup plan you can defend

You’ve now got automated DirectAdmin backups, an off-server target (SSH or S3), retention that won’t eat the disk, and a restore test you can repeat.

That’s the standard you want in 2026. Not “we have backups,” but “we can restore on demand, on a schedule, without surprises.”

If you want shorter backup windows and fewer restore headaches, start with stable infrastructure.

Use a HostMyCode VPS for DirectAdmin deployments, or move to dedicated servers when you’re hosting many accounts and need consistent CPU and disk throughput.

Running DirectAdmin for client sites means backups are part of the service you sell. HostMyCode offers managed VPS hosting if you want help with day-to-day server operations, plus flexible HostMyCode VPS plans when you’d rather manage everything in-house.

FAQ

How often should I run DirectAdmin backups for hosting accounts?

Nightly is the baseline for most shared hosting and WordPress sites. If you run WooCommerce or high-change apps, consider twice daily and add application-level exports for critical data.

Is remote storage required if I take “local” backups?

Yes. Local backups help with accidental deletes, but they won’t save you from disk failure, ransomware, or a bad OS-level incident. Always keep at least one off-server copy.

Should I use SSH storage or S3 for DirectAdmin backups?

SSH storage is simpler and often faster for large tarballs. S3 scales well and is convenient for geo redundancy. If you use S3, add encryption (like rclone crypt) and a date-based retention plan.

What’s the minimum restore test I should do?

Restore one account into a staging server and validate three things: the site loads, wp-admin works (or app login works), and a database import completes without errors.