Restore a crontab from a backup by giving the saved file to crontab. That replaces the selected user’s current schedule, so save what is installed before you make the change.
Know what the restore command changes
A user crontab is the schedule that cron runs for one account. The crontab program installs, lists, or removes that schedule, while system schedules such as /etc/crontab and files in /etc/cron.d follow a different path.
Use the crontab reference if you need to read the five time fields before restoring an unfamiliar file. Do not edit the spool file directly.
The screenshot shows the user schedule that a backup can restore only for the account you target.
Save the current schedule first
Create a dated backup before you overwrite anything. If the saved file is wrong, this copy gives you a direct way back.
mkdir -p "$HOME/cron-backups"
crontab -l > "$HOME/cron-backups/crontab.$(date +%F).bak"
A user with no installed crontab can make crontab -l exit with a nonzero status. That result means there was no user schedule to save, not that cron has recovered a deleted schedule.
Validate the backup file
Read the file before installing it and check that each job has the intended command and schedule. Keep secrets out of command lines when the backup will be copied or committed.
cat "$HOME/cron-backups/crontab.2026-08-27.bak"
Check crontab –help before you use the syntax-only -n option because not every implementation provides it. I validated a sample backup with Cronie’s -n option in this refresh, and it exited successfully.
crontab -n "$HOME/cron-backups/crontab.2026-08-27.bak"
Install the saved crontab
After you preserve the current schedule, give crontab the backup file to replace the current user’s installed jobs rather than adding to them.
crontab "$HOME/cron-backups/crontab.2026-08-27.bak"
The restore screen represents the replacement operation. Use the same account that owned the backup unless you intentionally administer another account.
Restore another user’s schedule
Only an administrator should target another account. Confirm the account name and review the file because this command replaces that account’s installed jobs.
sudo crontab -u alice "$HOME/cron-backups/alice-crontab.bak"
The user-selection screen matters because cron jobs run with the selected account’s permissions and environment. A root backup is not a substitute for a regular user’s schedule.
Confirm the installed jobs
Compare the installed listing with the intended backup immediately after the restore, then verify that any referenced script still exists with the expected permissions.
crontab -l
The listing is the first confirmation that cron accepted the file. For a job that matters, also inspect its command, logs, and environment before relying on its next scheduled run.
Keep a backup you can restore
Store the backup outside the machine or filesystem you are protecting. Rsync backups help you copy a backup to another location, while shell scripting and cron jobs helps you understand the jobs you are preserving.
If the restore follows an accidental deletion and no backup exists, reconstruct only what you can verify from deployment files, configuration management, and logs. Cron-based automatic updates and searching logs with grep are useful starting points for tracing known tasks.
Does crontab restore merge jobs with the current schedule?
No. Running crontab with a file replaces the current user crontab with the file contents, so save the current schedule before you restore.
How do I restore another user’s crontab?
Run the command as root and use crontab -u followed by the account name and backup file. Confirm the account and file before you run it.
Can I recover a deleted crontab without a backup?
Usually you must reconstruct the schedule from a filesystem backup, configuration management, deployment files, or logs. Cron cannot restore a deleted user crontab by itself.
Keep one dated copy of every important user crontab outside the host, then test that the file can be read and installed before you need it.