Schedule Automated Backups

JetBackup runs backups on a schedule you define. This guide covers creating a layered schedule that gives you maximum restore coverage without wasting storage.

Creating a backup schedule

1. Log into WHM and go to Plugins → JetBackup 5 → Backup Jobs → Add Backup Job.
2. Enter a job name: e.g. Daily Full Backup.
3. Select your S3 destination from the dropdown. If you haven’t added one yet, see Configure S3 destination.
4. Under Schedule, choose a preset or enter a custom cron expression.
5. Set Backup Type to All Accounts for full server coverage.
6. Set Retention: how many copies to keep before old ones are deleted.
7. Click Save.

Recommended three-tier schedule

Create three separate jobs:

Job name	Cron	Retention	What it gives you
Daily backup	0 2 * * *	7	7 daily restore points
Weekly backup	0 1 * * 0	4	4 weeks of weekly snapshots
Monthly backup	0 0 1 * *	3	3 months of monthly archives

With this setup you can restore to any point in the last 7 days, any Sunday in the last month, or the 1st of any of the last 3 months.

Cron expression reference

*  *  *  *  *
|  |  |  |  |
|  |  |  |  └── Day of week (0=Sun, 7=Sun)
|  |  |  └───── Month (1-12)
|  |  └──────── Day of month (1-31)
|  └─────────── Hour (0-23)
└────────────── Minute (0-59)

Common schedules:

• 0 2 * * *: every day at 2:00 AM
• 0 1 * * 0: every Sunday at 1:00 AM
• 0 0 1 * *: 1st of every month at midnight
• 0 */6 * * *: every 6 hours

Stagger your jobs

Don’t run multiple large jobs at the same time. Backups are disk and I/O intensive. Stagger start times by at least 30 minutes:

• Daily: 0 2 * * *
• Weekly: 0 3 * * 0
• Monthly: 0 4 1 * *

Verifying jobs are running

After saving a job, check it runs correctly:

1. Click Run Now on the job to trigger a manual run
2. Go to Queue & Logs and watch the job complete
3. Check your S3 bucket to confirm files were written
4. Set up email alerts under JetBackup → Settings → Notifications

A scheduled job that silently fails is worse than no backup: Always verify after setup. Many teams assume backups are running only to discover during a disaster that the job was failing due to wrong credentials or a full bucket.