Mythic backup script

Support
1

On the topic of backups:

I have 10Gb of backup space allocated to a Sympl 12 vm.
I’ve installed the Mythic Backup Script and seemingly configured the necessary steps.
But whilst I’m able to login to the backup space the Mythic Script doesn’t appear to be sending backups to the backup account.

Beyond installation of the scipt, adding the keys and setting CUSTOMER=username and SERVER=server in /etc/mythic/backup.conf is there anything else to configure?

My /etc/mythic/backup.conf reflects the following:

SERVER=example.mythic-beasts.com
CUSTOMER=12345_example
MYSQL=no
POSTGRES=no

2

I can’t offer a fix, but I can offer an alternative. Although sympl does back locally each day. I don’t use separate backup space. Too expensive!
Instead, I run Borg Backup, running through borgmatic, backing up to off-site storage on Borgbase.com. This gets me a backup every three hours with space to store several years of backup on a 3hr/7day/4week/1year cycle.

3

Mythic backup script failing to take nightly system snapshots

I’ve posted the following fault finding process to assist others - hope it helps. .

Issue - Installation of the Mythic Backup Script went smoothly, however the script was failing to process daily snapshots of the vm. Noteworthy, installation of the script should automatically add a nightly cron task that writes logs to /var/log/mythic-backup

During the investigations, Mythic support assisted with the following fault-finding process.

Check cron is installed on the system. You can check with “dpkg -l | grep cron” (the package is usually just called “cron”, but the grep should pick up some other possibilities).

Check the Cron entry which should look something like this (with a different random time):

$ cat /etc/cron.d/mythic-backup

37 06 * * * root if [ -x /usr/sbin/mythic-backup ]; then /usr/sbin/mythic-backup; fi

Check which version of the backup package is installed? “dpkg -l mythic-backup” should tell you.

Were there any error messages while “apt-get install” was running? You can check in /var/log/apt/term.log* if necessary.

Run the backup script: mythic-backup -v and check output

Check /var/log/mythic-backup for files? If present, what’s inside them? The files on my machine were showing something similar to the following output:

2025-02-15T22:35:07 ERROR: ssh -T -a -oVerifyHostKeyDNS=yes -oPasswordAuthentication=no -i/root/.ssh/id_backup_rsa 10992_example@backup-example.com /bin/true bad exit status: 255

2025-02-15T22:35:07 FATAL: Cannot connect to backup server, check configuration and retry

Mythic Beasts Ltd: Apparently, the reason it didn’t work initially (that is, didn’t trust host keys from DNS without confirmation) is, I believe, that you don’t have “option trust-ad” in /etc/resolv.conf. This is documented in the resolv.conf manpage, and if you’re using Mythic Beasts resolvers, you can turn it on if you want to.
…

It’s not specific to the mythic-backup script. It’s something you increasingly need to get working DNS resolution in the presence of DNSSEC on machines with sufficiently recent versions of glibc. I’m not entirely sure why it’s not the default in all Linux distributions as it is in many, but I suspect Debian’s hyper-security-conscious attitude is partly the cause.

We’re not talking about the authoritative namservers for your domain: we’re talking about the recursive resolvers used by your VM. These are the servers listed with ‘nameserver’ directives in /etc/resolv.conf.

It should be a line that just says:

options trust-ad

It’s normal to put it at the end of the file, but I don’t think it actually matters.

Depending how your server is installed, /etc/resolv.conf may be automatically generated (in which case it’ll contain a line saying that it’s generated). If that’s the case, local changes to /etc/resolv.conf will get overwritten, and you’ll need to make them in the configuration for whichever program is generating it.

–

Mythic Beasts Ltd