DICE users have long had the ability to add their own cron jobs, to schedule repeating tasks or to launch services on reboot¹ using the standard crontab command.

The Research and Teaching unit recently noted that users’ crontabs (sometimes required, for example, on research servers to start or check on custom services) are not routinely backed up. They are of course necessarily minimal and easy to recreate, but their fate following a disaster (or even a reinstallation) is not obvious. Even if users are aware of this limitation, it prevents us from performing a completely automated recovery where users’ crontabs are involved.

It is possible to back up crontabs on demand or routinely, but we’ve no procedure to do this on machines that typically have no other data to back up. So the purpose of this post is simply to draw attention to the above, and ask a few general questions:

• Is it well-known that crontabs are “at risk”? Does anyone care?
• Should crontabs be backed up routinely? on all servers? desktops? at all?
• Is there anything else we should be doing about this?

Comments are encouraged, below or by email.

1. crontab is the setuid executable which manages /var/spool/cron/ for this purpose. The location is notable: on DICE, the /var directory (or filesystem) consists of data which is either transient or generated and managed automatically. With the exception of some database files, this data is not typically backed up since its value is only to the running system. Indeed most cron entries on a machine are not created by users; they are configured by LCFG and (re)created automatically.
2. Note that using cron on DICE requires a few steps to work with (or around) AFS.