99

I entered crontab -r instead of crontab -e and all my cron jobs have been removed.

What is the best way (or is there one) to recover those jobs?

hellodanylo
  • 2,393
  • 1
  • 17
  • 19
Teerath Kumar
  • 1,095
  • 1
  • 7
  • 8
  • 58
    Is it just me or wouldn't it make more sense for crontab -r to ask yes/no by default?? – user1446688 Feb 16 '15 at 22:54
  • 14
    I think having a yes/no prompt would be a great idea. especially since e & r are right next to each other.. and `crontab -e` is a really common cron command. – JustinP May 11 '15 at 15:52
  • To futureproof, instead of `crontab -e` consider using a variation of this process (assuming `$HOME` directory): `crontab -l >.crontab ; vi .crontab ; sleep 2 && crontab .crontab` and thereafter `vi .crontab ; sleep 2 && crontab .crontab`. I have an extension to `vi` that returns status indicating whether or not the file contents changed during the edit. I can then `ifvi .crontab && crontab .crontab`. (But that extension is out of scope for a comment.) – roaima Jun 23 '15 at 13:10
  • 9
    In 7 or so years of admin work I have never had this happen to me. Now I am scared. Time to start backing up the crontabs regularly. – Caja Jun 23 '15 at 13:35
  • If you have vim set to keep an undo file, you may be able to dig through those manually to rescue some text. Running `ls *crontab*` in your `undodir` should pull up a list of files you can parse (lots of gibberish, but lines I cared about were in plaintext). – SnoringFrog Sep 04 '15 at 18:42
  • 12
    This has happened to me twice already. It's the worst idea ever to have `e` for edit and `r` for remove with absolutely no prompt whatsoever!! – DaniG2k Sep 07 '15 at 14:17
  • 17
    First thing to do, `alias crontab=crontab -i`. But crontab should have made that default, given that e & r are next to each other... – anishsane Dec 08 '15 at 06:57
  • 1
    This could be a nearest hack... `0 0 * * * /usr/bin/crontab -l > ~/.crontab.bak` – anishsane Dec 08 '15 at 06:59
  • 1
    I didn't even give -r. I just entered "crontab" and it nuked everything. That's insane. – Adrian May Apr 16 '16 at 19:30
  • Mac OS does't support the -i flag on crontab, unfortunately. – mwfearnley Jul 05 '16 at 09:26
  • Manage your `crontabs` locally or always follow `crontab -e` with `crontab -l >$HOME/etc/crontabs/crontab.$(tshhmmss)`. `tshhmmss` is a `date` alias producing `2016-Nov-29-124124` unique to-the-second timestamps. – waltinator Nov 29 '16 at 17:42
  • 4
    ok someone didn't look at the fucking keyboard when he was designing crontab – Toolkit Feb 15 '19 at 12:12
  • Might be worth considering having a git repository containing the crontabs. Crontabs are stored /var/spool/cron. Not sure if it is a good idea to create the git repo here. Otherwise, just use a soft link to the location in an external git repo. Add a crontab (irony) to commit changes. Create a separate user (cronbak) or pick one that will never modify it's crontab. Might need to give the users elevated privileges as sudoer. – Erik Lievaart Sep 27 '19 at 10:08
  • I would add `alias crontab='crontab -i'` to `nano ~/.bashrc`. At least this is the login script for Debian. – Mint Dec 03 '22 at 03:49
  • Something tells me crontab guys are in DVORAK team – user1079505 Jul 17 '23 at 15:34

5 Answers5

80

crontab -r removes the only file containing the cron jobs.

So if you did not make a backup, your only recovery options are:

  • On RedHat/CentOS, if your jobs have been triggered before, you can find the cron log in /var/log/cron. The file will help you rewrite the jobs again.
  • Another option is to recover the file using a file recovery tool. This is less likely to be successful though, since the system partition is usually a busy one and corresponding sectors probably have already been overwritten.
  • On Ubuntu/Debian, if your task has run before, try grep CRON /var/log/syslog
jarhill0
  • 103
  • 3
hellodanylo
  • 2,393
  • 1
  • 17
  • 19
27

If you have no /var/log/cron file you can recover the commands (but not the timings) from the syslog.

grep 'CRON.*(yourusername)' /var/log/syslog

you can then figure out most timings by looking at the datestamps.

Meow
  • 456
  • 4
  • 7
5

It sucks, but if you run crontab -r your crontab is gone forever. And unless you have a backup of it somewhere, you must grep through syslog files to get an idea of what/when jobs were being run, and recreate.

A good trick to avoid such problem is to add the following line to your crontab:

@daily          crontab -l > $HOME/.crontab

This way your crontab is backed up every day to $HOME/.crontab, so if you delete it by accident, a relatively recent copy is available and can be installed by:

crontab < $HOME/.crontab
flaviovs
  • 161
  • 1
  • 2
1

As an additional preventative measure in addition to backing up data, as mentioned by @anishsane, the -i flag will "prompt before deleting user's crontab". So, if you run crontab -i -r, it will give a nice

crontab: really delete <user>'s crontab? (y/n)

At which point you can select y or n. Of course, you don't want to type that out every time, so put this in your bash config and forget about it:

alias crontab="crontab -i"

As the -i flag doesn't affect any other command

MANA624
  • 151
  • 5
-7

vi /var/spool/cron/*user* or if you're the root user then vi /var/spool/cron/root

roaima
  • 107,089
  • 14
  • 139
  • 261
user120610
  • 5
  • 5
    This is worse. It edits the spool files without notifying `cron` that the file has been edited. It also won't work when the user has accidentally deleted their `crontab` because there is no file to edit. – roaima Jun 23 '15 at 13:06
  • Upvote from me for actually stating the location of the crontab. I had an entire system backup and could easily retrieve my cronjobs. Thanks! – Cookie Dec 18 '15 at 14:24