I ran crontab -r instead of crontab -e and deleted my crontab file. I didn't have a backup and new to recover the deleted file.

Is this possible?



  • 7
    the options to edit and remove shouldn't be right next to each other on the keyboard. Too easy a mistake to make for a quick typer. – einstiien Feb 4 '10 at 18:42
  • that's exactly what happened to me. – Peter Feb 4 '10 at 18:46

Try looking at /var/log/cron to see what has been running and then try to recreate the crontab from that. Its messy but you should be able to restore everything that had previously run. Not so much luck for newer items though. Good luck!

  • Great approach! – Alex Apr 5 '12 at 23:27

First of all: Always make backups!

But, it is so easy to mix up crontab -r and crontab -e. I just did this myself.

That's what I did:

You can try to have a look at /var/log/cron and build your crontab again.

  1. Have a look at the logfile
  2. Take the first command and do grep commandname1 /var/log/cron
  3. Figure out the systematic behind the times the command was run
  4. Put that entry to your new crontab
  5. execute cat /var/log/cron | grep -v commandname1. This will exclude the command1 that you already covered.
  6. Take the next command and grep for it
  7. Figure out the systematic behind the times the second command was run
  8. put that entry to your new crontab
  9. execute cat /var/log/cron | grep -v commandname1 | grep -v commandname2
  10. Repeat until you covered all commands

Now you should also execute the grep on older cronlogs to find out jobs that might be run only once in a month.

  • 1
    On Ubuntu at least (not sure about other platforms using anacron/Vixie cron) the log is stored in /var/log/syslog/*. – Timothy Gu Apr 12 '15 at 15:23
  • 1
    Before you accidentally delete something, always create a backup! – Dávid Horváth Jun 7 '17 at 16:00

Script for full crontab recovery

I made a PHP script that does a full recovery of your crontab, based on the log.

It outputs a single instance of every cron command run by the user for the last week.

I put it here


Here is a sample output:

perl ~/sorttv/sorttv.pl


bash ~/scripts/sort_sports.sh

  • 1
    Why was this given -1? It's a direct answer to the question. – Dan Green-Leipciger Jul 16 '13 at 11:31
  • I have been using your script. Amazing, thank you so much! – MeV Jul 22 '15 at 14:27
  • The PHP script does not with properly for commands containing closing parenthesis. Fixed and ported to bash: zgrep -F "($USER) CMD (" /var/log/syslog* | cut -d\( -f3- | sort -u | while read cmd ; do echo ${cmd::-1} ; done – Splitlocked Nov 28 '18 at 15:54

Ugh can't post a comment on the original question, but a co-worker just showed me a great tool: make an alias in whatever .profile you use for crontab to be crontab -i. The -i flag asks for confirmation before deleting.

So, if you do crontab -e it will proceed to edit as usual, but if you accidentally do crontab -r you are greeted with a confirmation prompt.

  • That doesn't help with the immediate problem... – vonbrand Apr 10 '13 at 19:15
  • Thank you. This is a valuable action that may help prevent accidental delete of crontab in future. – Hoang Tran Oct 12 '20 at 8:14

You've got options, but none are particularly pretty. In case you haven't thought of it, if you've got a recent version on a development machine, you can copy it from there ... I only say that because I often forget about copies that may be on other machines, so I assume that you've already tried that.

If your file is too heavily customized to make simply rebuilding it practical, you can always try some low-level forensics. Try googling for tutorials based around sleuthkit and UFS Explorer. People using these tools find widely varying degrees in terms of ease of use and success rates, so as usual, YMMV.


I don't think so. It's time to start to backup this important file (with all others in /etc /var/spool /home...).