How to Set Up a Cron Job That Runs a Backup Script Every Sunday at 2 AM

Backing up your files by hand is easy to forget. You mean to do it every week, then a busy month passes, and the one copy you trusted is suddenly out of date. A scheduled backup removes that worry completely. Once it is set up, Linux quietly runs your backup script at the same time every week, even while you sleep.

Cron is the built-in time-based scheduler that has shipped with Linux and Unix systems for decades. It is simple, reliable, and already installed on almost every distribution. In this guide you will create a small backup script, test it by hand, and then schedule it to run every Sunday at 2 AM using your personal crontab.

Quick Answer

Open your crontab with crontab -e, then add the line 0 2 * * 0 /home/yourname/scripts/backup.sh. The numbers mean minute 0, hour 2, any day of the month, any month, and day of week 0, which is Sunday. Make the script executable first with chmod +x backup.sh, and cron will run your backup every Sunday at 2 AM.

What Cron Is and How the Schedule Works

Cron runs in the background as a service called the cron daemon. Every minute it checks a set of tables, called crontabs, to see whether any job matches the current time. If a job matches, cron starts it automatically. You never need to leave a terminal open or stay logged in for the job to run, as long as the computer itself is switched on.

Each line in a crontab has five time fields followed by the command to run. The order is minute, hour, day of the month, month, and day of the week. An asterisk means every value for that field, so an asterisk in the month field means every month of the year.

Reading the Five Fields

For a Sunday 2 AM backup, the fields break down like this:

• Minute: 0 — the job starts at the top of the hour, exactly on 2:00.
• Hour: 2 — the job runs in the 2 AM hour, a quiet time when you are unlikely to be using the machine.
• Day of month: * — you do not want a fixed date, because Sundays fall on different dates each month.
• Month: * — the backup should run all year, not just in certain months.
• Day of week: 0 — zero means Sunday. Seven also means Sunday on most systems, but zero is the clearest choice.

Putting it together gives 0 2 * * 0. If you wanted Saturday instead, you would use 6. If you wanted 3:30 AM on Sunday, you would use 30 3 * * 0. Learning this pattern once lets you schedule almost anything.

Step 1: Write Your Backup Script

Cron can run a single command, but a script is better. A script is easier to test, easier to change, and keeps your crontab line short and readable. Create a folder for your scripts and open a new file in a text editor.

1. Create the folder with mkdir -p ~/scripts.
2. Open the file with nano ~/scripts/backup.sh.
3. Type the script below, adjusting the source and destination paths to match your system.
4. Save the file and close the editor.

A simple, dependable script looks like this: #!/bin/bash on the first line, then SOURCE="/home/yourname/Documents", then DEST="/mnt/backup/weekly", then mkdir -p "$DEST", and finally rsync -a "$SOURCE/" "$DEST/". The first line tells the system to run the file with Bash. The variables keep your paths in one easy place at the top.

You can also add a date stamp so each backup sits in its own folder. Replace the destination with something like DEST="/mnt/backup/weekly-$(date +%F)". The date +%F part produces a value such as 2026-10-25, which makes it simple to find the backup from a particular week later.

Make the Script Executable

A script will not run until you give it execute permission. Run chmod +x ~/scripts/backup.sh once. Without this step, cron will try to start the job and fail with a permission error, and you may not notice for weeks. This single command is the step beginners skip most often.

Step 2: Test the Script by Hand First

Never schedule a script you have not tested. Run it yourself with ~/scripts/backup.sh and watch what happens. If files copy to the destination and no errors appear, the script itself is healthy. If something fails now, it would also fail under cron, so fixing it at this stage saves real frustration.

Check the destination with ls -lh /mnt/backup/weekly. Open one or two files and make sure they are complete rather than empty.

It also helps to add a log line to the script. A line such as echo "Backup finished $(date)" >> ~/backup.log writes a dated note every time the script completes. Later, that log becomes your proof that Sunday backups are really happening.

Step 3: Add the Job to Your Crontab

Now schedule the tested script. Your personal crontab controls jobs that run as your own user, which is exactly right for backing up your own files.

1. Open your crontab with crontab -e. The first time, you may be asked to choose an editor such as nano.
2. Move to the bottom of the file, below any comment lines that start with a hash symbol.
3. Add the line 0 2 * * 0 /home/yourname/scripts/backup.sh, using your real username and the full path to the script.
4. Save the file and exit. Cron confirms the new crontab was installed.
5. Verify the entry with crontab -l, which simply lists your current jobs.

Always use the full path to the script in the crontab. Cron runs with a very limited environment and does not know where your home folder shortcuts point. Writing backup.sh alone will fail, while the full path works every time. You can learn more about the schedule format in the official crontab manual page, which explains every field in detail.

Step 4: Confirm Cron Is Running

The best schedule in the world does nothing if the cron service itself is stopped. On Ubuntu and Debian systems, check it with systemctl status cron. On Fedora and similar systems the service is called crond, so use systemctl status crond. The status should say active and running.

If the service is stopped, start and enable it with sudo systemctl enable --now cron. Enabling matters because it makes cron start again automatically after a reboot. The Ubuntu community guide to cron covers service management and per-user crontabs clearly if you want extra background.

Remember one important limit: cron does not catch up on missed jobs. If your computer is switched off at 2 AM on Sunday, that week’s backup simply does not run. For a laptop that is often closed at night, consider a tool like anacron, or pick a time when the machine is usually awake. Our related guide on using rsync to mirror your home folder to an external drive pairs well with this schedule, because rsync only copies changed files and keeps weekly runs fast.

Common Mistakes and Useful Tips

• Forgetting the executable bit. Run chmod +x on every new script before scheduling it.
• Using relative paths. Cron starts in a plain environment. Use full paths for the script, the source, and the destination.
• Leaving the backup drive unmounted. If your destination is an external drive, make sure it is plugged in and mounted before Sunday, or the script may write to the wrong place or fail.
• Never reading the output. Add >> ~/backup.log 2>&1 at the end of your crontab line to save all output and errors to a log you can check.
• Testing on the wrong day. To test the schedule itself, temporarily set the job a few minutes in the future, watch it run, then change it back to Sunday 2 AM.
• Backing up to the same disk. A backup on the same drive does not protect you if that drive fails. Send the copy to a different disk or another machine.

Keep two generations of backups rather than overwriting one folder forever, so a damaged file does not replace the good copy.

Conclusion

Setting up a Sunday 2 AM backup takes about ten minutes: write a short script, make it executable, test it by hand, and add one crontab line, 0 2 * * 0 followed by the full script path. After that, cron handles the routine for you every week. Check the log once in a while, confirm the drive has free space, and your files will be protected without any weekly effort from you.

Frequently Asked Questions

What does 0 2 * * 0 mean in cron?

It means run at minute 0 of hour 2, on any day of the month, in any month, when the day of the week is 0, which is Sunday. In plain words, every Sunday at exactly 2:00 AM.

Will the backup run if my computer is asleep at 2 AM?

Usually not. Cron runs jobs only while the system is awake and powered on. If the machine is off or suspended, the job is skipped and is not made up later, so choose a time when the computer is normally on.

How do I see or remove my scheduled jobs?

Run crontab -l to list them. To change or remove a job, run crontab -e and edit or delete the line, then save. Avoid crontab -r unless you truly want to delete the entire crontab.

Why should I use a script instead of one long cron command?

A script is easier to test, read, and update. You can run it by hand anytime, add logging, and change paths in one place. The crontab line stays short, which makes mistakes far less likely.

Where do backup errors go if the job fails?

By default cron may mail output to the local user, which many people never read. Redirect output to a log file in the crontab line so errors are saved in a place you will actually check.