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)
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.
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 firstname.lastname@example.org:/backups
b) mount the backup space, but leave the original files for now
/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
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.
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.
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
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.