How to efficiently back up and restore crontab

Posted in: Oracle

When a database environment is being patched, entries from crontab are commented and then removed when patching is completed.

The process works well when there are only a few entries from crontab, but it does not scale when crontab has dozens of entries and when some entries are commented and some are not.

I believe a more efficient method is to backup and restore the existing crontab.

Here’s a demo:

Crontab entries.

[oracle@racnode-dc1-1 ~]$ crontab -l
*/05 * * * *   /bin/date > /tmp/date.out 2>&1
*/15 * * * *   /bin/date > /tmp/date.out 2>&1
#*/25 * * * *   /bin/date > /tmp/date.out 2>&1
*/35 * * * *   /bin/date > /tmp/date.out 2>&1
*/45 * * * *   /bin/date > /tmp/date.out 2>&1
*/55 * * * *   /bin/date > /tmp/date.out 2>&1

Backup crontab and display contents. Extra precaution in case crontab.save.dinh is removed.

[oracle@racnode-dc1-1 ~]$ crontab -l > crontab.save.dinh; cat crontab.save.dinh
*/05 * * * *   /bin/date > /tmp/date.out 2>&1
*/15 * * * *   /bin/date > /tmp/date.out 2>&1
#*/25 * * * *   /bin/date > /tmp/date.out 2>&1
*/35 * * * *   /bin/date > /tmp/date.out 2>&1
*/45 * * * *   /bin/date > /tmp/date.out 2>&1
*/55 * * * *   /bin/date > /tmp/date.out 2>&1

Remove crontab.

[oracle@racnode-dc1-1 ~]$ crontab -r; crontab -l
no crontab for oracle

Restore crontab.

[oracle@racnode-dc1-1 ~]$ crontab crontab.save.dinh; crontab -l
*/05 * * * *   /bin/date > /tmp/date.out 2>&1
*/15 * * * *   /bin/date > /tmp/date.out 2>&1
#*/25 * * * *   /bin/date > /tmp/date.out 2>&1
*/35 * * * *   /bin/date > /tmp/date.out 2>&1
*/45 * * * *   /bin/date > /tmp/date.out 2>&1
*/55 * * * *   /bin/date > /tmp/date.out 2>&1

If you are lazy like me, then backup can be done in one command.

[oracle@racnode-dc1-1 ~]$ crontab -l > crontab.save.dinh; cat crontab.save.dinh; crontab -r; crontab -l
*/05 * * * *   /bin/date > /tmp/date.out 2>&1
*/15 * * * *   /bin/date > /tmp/date.out 2>&1
#*/25 * * * *   /bin/date > /tmp/date.out 2>&1
*/35 * * * *   /bin/date > /tmp/date.out 2>&1
*/45 * * * *   /bin/date > /tmp/date.out 2>&1
*/55 * * * *   /bin/date > /tmp/date.out 2>&1
no crontab for oracle
[oracle@racnode-dc1-1 ~]$

email

Author

Interested in working with Michael? Schedule a tech call.

4 Comments. Leave new

Worth noting it!!!
I remember an incident when a DBA just typed crontab -r instead of crontab -l, not to blame him completely as ‘R’ and ‘L’ keys are just besides each other.. scheduled jobs were wiped off without any warning..

Regards
Maaz

Reply
Michael Dinh
May 24, 2019 10:44 am

Base on current event, this is better
crontab -l > crontab.save.dinh; cat crontab.save.dinh; chmod 600 crontab.save.dinh

This will prevent accidents such as shown below:
crontab -l > crontab.save.dinh; cat crontab.save.dinh
crontab -r; crontab -l

Got distracted and if this is run again the crontab will be really bad.
crontab -l > crontab.save.dinh; cat crontab.save.dinh

This will prevent accident due to distractions.

Reply

Noted Michael,

Also, a monthly backup with root user can be really helpful just in case if these entries are messed up –
/var/spool/cron contains files for all users that have cron scheduled jobs.

Reply
Michael Dinh
May 28, 2019 9:08 am

Thanks for sharing Maaz.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *