Recover cron jobs accidently removed with crontab -r

Question

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?

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
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.) — Chris Davies, Jun 23 '15 at 13:10
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
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
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
This could be a nearest hack... 0 0 * * * /usr/bin/crontab -l > ~/.crontab.bak — anishsane, Dec 08 '15 at 06:59
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
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

score 83 · Accepted Answer · edited Aug 11 '19 at 21:03

83

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

edited Aug 11 '19 at 21:03

jarhill0

103
3

answered Jun 10 '14 at 07:20

hellodanylo

2,433

I could not voted you up but this answer was some how useful for me. thankx – Teerath Kumar Jun 10 '14 at 08:24
1

@RajaRassani You can mark the answer is a correct one with a tick mark, though. Thanks for feed back! – hellodanylo Jun 10 '14 at 08:31
this just happened to me :) total bummer.. I do use virtual servers and backup them up regularly..so I'm going to spin up a backup.. and get the deleted crontabs – JustinP May 11 '15 at 15:49
+1 for being straightforward :} – namezero Apr 13 '18 at 17:54
You can try your luck looking for a backup made by the editor in /tmp/crontab.wpMhKS (of course the name may change). It may not be the most recent version but in my case it helped a lot – Jong Bor Aug 03 '18 at 14:11
@JongBor dude, you saved my day. – Comrade Aug 07 '23 at 08:29

Meow · Answer 2 · 2016-12-16T05:41:48.370

28

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.

edited Dec 16 '16 at 05:41

answered Dec 04 '15 at 21:24

Meow

466
4
7

1

On ubuntu the file is /var/log/syslog. – Aurelijus Rozenas Nov 29 '16 at 13:02
@ Aurelijus Rozenas I accidentally added sys to the directory path it should be /var/log/syslog, I corrected my post. – Meow Nov 29 '16 at 17:32
2

grep 'CRON.*(yourusername)' /var/log/syslog – aidan Dec 15 '16 at 22:52
1

@Aidin you are my savior! Note to self: Never edit the crontab file while server space is full. – Shadoath Feb 06 '17 at 17:55
2

Phew that was close! I've now added a cron to backup my crontab everyday :) – SidJ Jul 05 '19 at 06:20
/var/log/syslog stores last day logs or less. In my case I needed sudo zgrep 'CRON.*(yourusername)' /var/log/syslog* – Kipras Kančys Nov 20 '20 at 09:02

score 6 · Answer 3 · answered Sep 14 '20 at 03:45

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

MANA624 · Answer 4 · 2022-03-21T20:37:09.707

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

edited Mar 21 '22 at 20:37

answered Dec 21 '21 at 20:08

MANA624

151

Good suggestion but this doesn't really work if you wanted execute -e but instead mistyped to -r – Toms Bugna Sep 30 '22 at 07:55

score -7 · Answer 5 · edited Jun 23 '15 at 13:06

-7

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

edited Jun 23 '15 at 13:06

Chris Davies

116,213
16
160
287

answered Jun 23 '15 at 12:39

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. – Chris Davies 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

Recover cron jobs accidently removed with crontab -r

5 Answers5

Linked

Related