If you're not happy with using FTP as remote backup method and would like to use something more advanced, such as Borg which allows incremental backups, you may setup CLI backup strategy for incremental backup. The setup could be similar to:

step1: Go to "Admin Backup/Transfer" feature, "Schedule" a backup to be ran as often as you'd like to (once a day might be enough), de-select "Domains Directory" and "E-mail data", place your backups to /home/admin/admin_backups for example. More information may be found in the GUI method mentioned above.

step2: Install borg, commands for CentOS:

yum -y install epel-release
yum -y install borgbackup
1
2

Debian:

apt install borgbackup
1

step3: initialize a local OR remote repository:

  • local:
borg init --encryption=none /backups
1
  • remote:
REPOSITORY=borgbackup@YOUR_SERVER_IP:/backups/`hostname -f`
1

In the example above, we're using the 'borgbackup' SSH user on a remote server having privileges to /backups/hostname.

Adding ssh keys from root to that remote server would be needed if you wanted it configured so that it could connect without password.

step4: Create /usr/local/directadmin/scripts/custom/all_backups_post.sh script, which would automatically sync with borg backup server after every backup done, content:

#!/bin/sh
REPOSITORY=borgbackup@YOUR_SERVER_IP:/backups/`hostname -f`


# Backup all of /home and /var/www except a few
# excluded directories
borg create -v --stats                          \
    $REPOSITORY::'{hostname}-{now:%Y-%m-%d_%H:%M}'    \
    /home                    \
    /var/www/html                    \
    /etc                    \
    /usr/local/directadmin > /tmp/borg-stat.tmp 2>&1


if [ "$?" -le 1 ]; then
borg prune -v $REPOSITORY --prefix '{hostname}-' \
    --keep-daily=7 --keep-weekly=4 --keep-monthly=6
else
    date >> /tmp/borg-stat.tmp
        mail -s "backup failed on server `hostname -f`" your@email.com < /tmp/borg-stat.tmp
fi


# Use the `prune` subcommand to maintain 7 daily, 4 weekly and 6 monthly
# archives of THIS machine. The '{hostname}-' prefix is very important to
# limit prune's operation to this machine's archives and not apply to
# other machine's archives also.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

And set the appropriate permissions:

chmod 700 /usr/local/directadmin/scripts/custom/all_backups_post.sh
1

On any failure it should mail you (your@email.com in script) about problems with it. Retention can be also specified/changed in the script.

This article is just to show alternative (free) ways to set up incremental backups until this functionality is fully integrated into DirectAdmin.

Restore from Borg

You may find the Borg configuration in the /usr/local/directadmin/scripts/custom/all_backups_post.sh file.

In this example, the repository will be:

REPOSITORY=ssh://rbackup@192.168.1.1:2200/home/rbackup/`hostname -f`
1

You may list all borg backups via the "borg list" command. For example:

borg list ssh://rbackup@192.168.1.1:2200/home/rbackup/`hostname -f`​
1

From there you will see all backups with their dates. Borg does not restore files directly, but allows you to mount a specific date's backup. For example, let's say we want to mount the most current backup. First let's list all complete backups:

# borg list ssh://rbackup@192.168.1.1:2200/home/rbackup/`hostname -f`
server.mycompany.tld-2019-11-12_11:20 Tue, 2019-11-12 11:20:42
server.mycompany.tld-2019-11-13_05:06 Wed, 2019-11-13 05:06:05
1
2
3

We see that the latest backup is dated '2019-11-13 05:06:05', so let's mount it to our temporary folder /mnt/mybackup. First let's create the temporary mount folder:

mkdir /mnt/mybackup
1

Now we may mount the current backup to /mnt/mybackup with the command "borg mount":

borg mount ssh://rbackup@192.168.1.1:2200/home/rbackup/`hostname -f`::server.mycompany.tld-2019-11-13_05:06 /mnt/mybackup
1

The syntax is:
borg mount REPOSITORY::BACKUPDATENAME /mount/point

It takes a few seconds to mount. When command finishes, we will have all backup files mounted on /mnt/mybackup. So, let's look at what we have:

/mnt/mybackup# ls -l
total 0
drwxr-xr-x 1 root root 0 Nov 13 05:05 etc
drwxr-xr-x 1 root root 0 Oct 11 15:33 home
drwxr-xr-x 1 root root 0 Nov 13 08:14 usr
1
2
3
4
5

For example, let's say we've mounted to the '2019-11-13_05:06' backup, because the admin user said that this morning, they accidentally removed the index.php file from the clientdomain.com website's wp-admin folder. We may simply navigate to the folder with the cd command:

cd /mnt/mybackup/home/admin/domains/clientdomain.com/public_html/wp-admin
1

And copy over the index.php file to the /home/admin/ folder:

cp -a index.php /home/admin/
1

Since we do not need /mnt/mybackup anymore, we may simply umount it:

umount /mnt/mybackup
1

The folder is empty again, so we may remove it:

/mnt/mybackup# ls -l
total 0
​rmdir /mnt/mybackup/
1
2
3

Databases are stored in user backups under /home/admin/admin_backups/ (see CLI backup strategy for incremental backup: step1), so you may copy over desired user backup from /home/admin/admin_backups/, extract the archive, and restore required database.

Last Updated: 6/23/2021, 9:36:08 PM