Testing backup.name

Problem Description

I have placed the rysnc link to my new mythic beasts backup space in a file /etc/sympl/dns.d/backup.name, but now wondering if this is supported in sympl (the post-backup.d folder is empty, which is where I see the symbiosis backup script)


Any Error Messages



  • Sympl Version [9.0]:
  • Debian Version [Stretch]:
  • Hardware Type? [Virtual]
  • Sympl Testing Version? [No]

Hi @aye_philip.

No, this isn’t currently supported in Sympl, as the functionality was somewhat broken in Symbiosis, and actually used to sync to a long-since-retired service from Bytemark which relied on a lot of moving parts.

Alternatively, you can simply set up an rsync job yourself (which is really all it did) in /etc/sympl/pre-backup.d and /etc/sympl/post-backup.d.

Note that you’ll want to exclude /var/backups/localhost/*.lock from any syncs, just in case.

Proper functionality for this will come at a later date, but in the meantime you can also simply mount the backup space at /var/backups/, and save yourself some disk space.

1 Like

Thanks. The last option should be good for now. But I have some questions. The steps below are what I have kicked off with, though something interferes with /etc/cron.hourly/sympl-filesystem-security see below

a) move the existing backups over

rsync -a --numeric-ids --rsh="ssh -T -a -oPasswordAuthentication=no -i/root/.ssh/id_mythic_backup_rsa" --rsync-path="rsync --fake-super --numeric-ids" /var/backups sympltest@backup-mer-b.mythic-beasts.com:/backups

b) mount the backup space, but leave the original files for now

sshfs -o nonempty,allow_other,IdentityFile=~/.ssh/id_mythic_backup_rsa sympltest@backup-mer-b.mythic-beasts.com:/backups/sympltest/backups /var/backups

c) add to fstab (I haven’t yet)

sshfs#sympltest@backup-mer-b.mythic-beasts.com:/backups/sympltest/backups /var/backups fuse defaults,allow_other 0 0

d) let backup2l run automatically

e) unmount /var/backups temporarily to delete the original files


  1. Is that fstab above correctly formed? and

  2. When I ran backup2l -b manually it did give some permission errors

chown: changing ownership of '/var/backups/mysql/.': Permission denied etc

and seeing similar errors when ‘/etc/cron.hourly/sympl-filesystem-security’ runs

chown: changing ownership of '/var/backups': Permission denied chown: changing ownership of '/var/backups/dpkg.diversions.3.gz': Permission denied


Hope that makes sense


and the automatic backup starts:

/etc/cron.daily/dpkg: cp: failed to preserve ownership for 'dpkg.status': Permission denied cp: failed to preserve ownership for 'dpkg.diversions': Permission denied cp: failed to preserve ownership for 'dpkg.statoverride': Permission denied run-parts: /etc/cron.daily/sympl-ssl exited with return code 1 /etc/cron.daily/zz-backup2l:

as well as
chown: changing ownership of '/var/backups/mysql/.': Permission denied chown: changing ownership of '/var/backups/mysql/mariadb_10.1--eco--20190911_070527_BST_Wednesday.sql.gz': Permission denied c

which is emailed hourly too!

This is likely due to the /var/backups directory being a mount which simply doesn’t support the same permissions as the local filesystem.

I’ll look into skipping the sympl-filesystem-security updates in /var/backups if it’s mounted, or just provide an option to disable that alone.

In the meantime if you sudo touch /etc/sympl/do-not-secure, that will just disable sympl-filesystem-security, but you may want to temporarily remove it and run it periodically just to be sure things in the /srv directories get permissions set if there are any manual changes.

1 Like

That is pretty much what I thought … thanks.

Thanks for pointing out how to disable the sympl file system security, and note the advice about re-enabling it every so often or after manual changes to /srv.

Alternatively, you can simply set up an rsync job yourself (which is really all it did) in /etc/sympl/pre-backup.d and /etc/sympl/post-backup.d .

Can you elaborate on this a little for me :slight_smile:
I wish to rsync to my NAS drive at home. I’ve already sorted out the authorization keys so it does not need a password.

Do I just need to create a file such as “02-pre-rsync” in /etc/sympl/backup.d/pre-backup.d/ containing

rsync -azP --delete username@server:/path/ /var/backups/localhost

This will make sure the local backup matches the remote backup. (although I’m not quite sure why this is necessary?)

and a file such as “02-post-rsync” in /etc/sympl/backup.d/post-backup.d/ containing

rsync -azP --exclude '*.lock' --delete /var/backups/ username@server:/path

This will sync the latest backup to the remote server

Thats it, although you probably want to exclude any files named *.lock, as backup2l generates a lock file when it starts and will complain if you run it a second time if it’s still there.

Generally, you only really need the post-rsync one typically - the ‘pre-sync’ was used with the old Bytemark backup space to ensure you have a full local copy of everything from the backup space before starting a new backup, so it didn’t replace any existing backups if you removed the local contents for some reason.

Sorry - you did say about the *.lock exclusion and I forgot to add that.

I’ve updated my post above to reflect your comments.

Thanks - I will test it out on tonight’s backup!

For other people’s interest on my previous Symbiosis server, and now also my Sympl server I setup an rsync job in /srv/default_domain/config/crontab to rsync the entire srv folder to my NAS drive as well. Just in case (also useful for keeping an eye on what files get changed each day).

The line I’m using on Sympl is:
0 3 * * * rsync -azP --exclude 'logs' --exclude 'cache' --exclude 'Maildir' --exclude 'php_sessions' --exclude 'php_tmp' --exclude '.well-known' --delete /srv/ username@server:/path/srv

Humm… 02-post-rsync this does not seem to work.

Testing manually “sudo backup2l -b” does not trigger the rsync to remote server. Manually running the rsync works ok. I tried adding “#!/bin/bash” to the start of the script, but that has not helped.

Can you give some guidance on how I can debug this…?


Actually… I do see an error related to this in the email report from the overnight backup.

run-parts: failed to exec /etc/sympl/backup.d/post-backup.d//02-post-rsync: No such file or directory
run-parts: /etc/sympl/backup.d/post-backup.d//02-post-rsync exited with return code 1

I now have something to go on. But I’ve not had chance to investigate yet…

Make sure the script is executable - it’s using run-parts, which expects a few things like the executable bit set (chmod +x /etc/sympl/backup.d/post-backup.d/02-post-rsync) before it will attempt to run things.

Permissions were set correctly, however it still didn’t work. However this thread suggested a “unix style script error”.

Therefore I copied /etc/sympl/backup.d/pre-backup.d/00-check-root into /etc/sympl/backup.d/post-backup.d renamed it and changed the contents and now it works absolutely fine. It looks no different to me, however it seems the original file I created via WinSCP was somehow “wrong”!

Ah, it’s likely the file you created was DOS formatted (Carriage-Return Line-Feed terminated) rather than Unix terminated (just a Line Feed), which will cause problems with the extra control code there.

It’s a common gotcha as the extra control codes don’t always show in editors in Linux, and are usually invisible in Windows unless you specifically load the file as DOS formatted.

Glad to hear you got it working though!

1 Like