I have a duplicity backup script set to run once per day through the root cron tab.
I set it up like this:
sudo crontab -e -u root
and added the line:
00 03 * * * root /home/[myusername]/Scripts/Backups/DuplicityBackup.sh
the script has commands to write to a text file like this:
echo "Creating backup of data directory" PASSPHRASE='[mypassword]' duplicity /usr/share/nginx/data file:///dysonbackup/datadir &>> /home/[myusername]/Scripts/Backups/backup_logs/data_backup_log.txt echo "Done"
Running the script itself as root starts the backup and writes to the text file.
sudo crontab -l
shows it listed
grep DuplicityBackup.sh /var/log/syslog
May 28 03:00:01 [myservername] CRON: (root) CMD (root /home/[myusername]/Scripts/Backups/DuplicityBackup.sh)
so I am assuming it at least triggered to run, but there is no new information on the text file.
And it does not appear that the duplicity backup is running as there are no new files in the backup directory.
sudo crontab -e -u root edits crontab for the user root. This is different than the system-wide crontab (
/etc/crontab). The former uses entries in a form of
m h dom mon dow command
and the latter uses
m h dom mon dow user command
You used the latter syntax where you should have used the former. The tool tried to run
Solution: either move your job to
/etc/crontab as-is; or fix the syntax by removing
If it’s not enough then keep reading.
DuplicityBackup.sh contain a shebang that specifies Bash as the interpreter?
cron will run
sh. If there is no shebang the situation is complicated in general, but
sh should run it in
sh, regardless of who provides
sh (there are different implementations, compare this).
When you run the script from Bash, it gets run in Bash.
&>> you used is a bashism. In Bash
&>> file is equivalent to
>> file 2>&1 and this is what you want. In
sh it’s equivalent to
& >> file and this is not what you want.
Solution: use a shebang.
/home/myusername may not be available because:
/home/myusernameis automatically unmounted when
myusernamelogs out (especially possible if it’s encrypted);
/home/myusernameis mounted as FUSE without
allow_otherand therefore cron running as root cannot access it;
or cron is run by
systemdand the service (
InaccessiblePaths=to restrict access to
/home/myusername(not likely though).
Solution: do not use
/home/myusername with cron jobs run by root.