Desktop Backup Scripts and Config files

These consist of:

The Actual shell script is currently at 0.6.1 as of 16/11/22 and consists of nearly 500 lines of code, so I have put it on its own page Here. It uses a very small font so that the lines do not have artificial CR/LF inserted by the web page. This should allow anyone to cut/paste the script.

Please note that the shell script is under constant review, basically it gets fixed whenever it goes wrong. Normally this has nothing to do with the script, but follows from some other change I have made to the system.

The startup script is this:

#!/bin/bash

set -e
# first check the script file exists
if [[ ! -x /opt/Backup/dupbackup.sh ]]
	then exit 1
fi
# now check both log dir and files exist
if [[ ! -w /opt/Backup/Dupbackup.log ]]
	then touch /opt/Backup/Dupbackup.log
fi
if [[ ! -w /opt/Backup/Dupcleanup.log ]]
	then touch /opt/Backup/Dupcleanup.log
fi
# Run the DupBackup system 
systemd-inhibit --why="Backup in Progress" /opt/Backup/dupbackup.sh

The exclusions file on my machine, which is running Ubuntu 22.04, follows this. I have two data volumes mounted as DATA2 and MEDIA2 where I keep a lot of data. They are formatted NTFS so they are available under dual boot with Windows. The file is called simply “exclusions”

/cdrom
/dev
**/lost+found
/media
/proc
/run
/sys
/tmp
/mnt/DATA2/ApplicationData/Mozilla/Firefox/
/mnt/LaptopData
/mnt/BackupDesktop
/mnt/DATA2/$RECYCLE.BIN
/mnt/DATA2/RECYCLER
/mnt/DATA2/System Volume Information
/mnt/MEDIA2/$RECYCLE.BIN
/mnt/MEDIA2/RECYCLER
/mnt/MEDIA2/System Volume Information

There is a file called simply passwd that contains just the text of the password used by Duplicity to access the NFS share. It permission are, of course, 400:root:root

Finally there is a README file that contains this text:

This system is triggered by a symlink in /etc/cron.daily called desktopbackup that points at /opt/Backup/runbackup
I thought I had set it to trigger at 03:00 in the morning thus stopping a full backup from starting just after midnight.
But I can't find out how I did that, and on 4/8/21 it triggered at 00:05 as normal.

anacron itself is triggered every hour by a systemd timer called anacron.timer

The 03:00 logic was only a problem when calculating over-run days as a job running at 09:00 on  Thursday is less than one day after a backup scheduled for 14:00 on Wednesday.

All this was made irrelevent by calculating and saving the next scheduled backup date due, rather than saving the exact date the last successful backup was taken.
The next backup day time that is stored in a .tmp file is at 03:00 in the morning. And an over-run job won't run if the time is before that.
However, triggering a backup simply because it is a Wednesday overrides this check.  The problem is that anacron will not rerun the job later on Wednesday if it is cancelled before 03:00

FINISH