cPanel Backups and Restore with JetBackup 5

Every iWebVault cPanel account is backed up automatically by JetBackup 5 — daily, weekly, and monthly snapshots, retained according to your plan. You don’t have to configure anything; backups just happen. What you do need to know is how to use them when something goes wrong: restoring a single file, recovering a database, rolling back a whole site. This guide covers all of that, plus how to create your own additional backups for the things JetBackup doesn’t cover.

What JetBackup 5 backs up automatically

• All files in your home directory (/home/yourcpaneluser/) — websites, scripts, configs.
• All databases — MySQL/MariaDB databases under your account.
• Email accounts and email storage.
• DNS zones.
• cPanel account settings — addon domains, redirects, cron jobs, SSL certs.

Retention varies by plan but typically includes daily for the past week, weekly for the past month, and monthly for several months. Backups are stored off-server on dedicated backup infrastructure — even if the primary server has a catastrophic failure, your backups are safe.

Accessing JetBackup 5

cPanel → Files → JetBackup 5. You’ll see a dashboard with categories for different restore types: Full Account Backups, File Backups, Database Backups, Email Backups, and so on. Each lists available snapshots with timestamps.

Restoring a single file

Most common scenario: you broke wp-config.php or .htaccess and need the old version back.

1. JetBackup 5 → File Backups.
2. Choose a backup from before the problem (a day or two back).
3. Browse the file tree to the file you want — same paths as in your File Manager.
4. Check the file’s box.
5. Click Restore at the top.
6. Confirm. JetBackup queues the job; you’ll get a notification when it completes (usually under a minute).

Restored files replace whatever’s currently there. If you want to keep both versions, download the file from the backup first instead of restoring directly.

Restoring a database

For when WordPress, a script, or a database operation corrupted data:

1. JetBackup 5 → Database Backups.
2. Choose the backup date.
3. Check the database to restore.
4. Click Restore.

The restore overwrites your current database completely — any data added since the backup is lost. If you want to be safer, use Download instead: get the SQL dump locally, inspect it, and import via phpMyAdmin only the pieces you want.

Restoring the whole account

The “nuke option” — useful after a site compromise, a botched migration, or just a really bad day:

1. JetBackup 5 → Full Account Backups.
2. Pick the date you want to roll back to.
3. Click Restore.
4. Confirm — JetBackup warns you everything will be replaced.

Full account restores take longer (5-30 minutes depending on account size). Your site is offline during the restore. Schedule for off-peak hours if you can.

Downloading a backup for off-site storage

JetBackup keeps backups off the server, but for ultra-safety some customers want their own copies stored elsewhere (their own cloud storage, an external drive). To download:

1. JetBackup 5 → Full Account Backups (or any category).
2. Click Download next to the backup date you want.
3. JetBackup builds a downloadable archive — for large accounts, this takes a few minutes.
4. Once ready, you get a download link. Save the file locally.

Personal backup workflows: download monthly to your own cloud storage. Combined with JetBackup’s automatic backups, you have multiple recovery layers.

Creating your own on-demand backup

Before any risky change (major plugin update, theme switch, database migration), create a manual snapshot:

1. JetBackup 5 → Snapshots (or “My Backups” / “Generate Backup” — exact label varies).
2. Click Create Backup.
3. Optionally name it (“pre-theme-switch”, “before-WP-6.5-upgrade”).
4. Wait for it to finish — minutes to an hour depending on account size.

On-demand backups are retained separately from the automatic schedule, so they don’t get rotated out. Useful for marking “known good” states before experimentation.

What JetBackup doesn’t cover

• External services. Cloudflare DNS records, Mailchimp lists, third-party APIs — JetBackup only sees what’s on the iWebVault server.
• Real-time data. Backups are point-in-time. If your e-commerce store took 50 orders between the last backup and the moment you restore, those orders are lost. For high-velocity sites, pair JetBackup with an application-level backup (WP Vault, UpdraftPlus, etc.) that snapshots more frequently.
• External git repositories. If your site syncs from a Git repo on every deploy, the repo is the source of truth — JetBackup is for the production state plus user-generated data (uploads, database).

Backup strategy that actually works

The “3-2-1” rule from disaster recovery: 3 copies of your data, on 2 different mediums, with 1 off-site. Translated to web hosting:

• Copy 1: Live site — your everyday production state.
• Copy 2: JetBackup automatic backups — daily/weekly snapshots, off-server.
• Copy 3: Manual download to your cloud storage — monthly download from JetBackup, saved to your own drive or cloud.

For mission-critical sites, add a fourth layer: an application-level backup plugin (UpdraftPlus, BlogVault, BackupBuddy) running daily, pushing to a destination you control. This gives you finer-grain recovery (single posts, single users) than full-site snapshots.

Common backup questions

“How long are backups kept?” Plan-dependent. JetBackup dashboard shows retention period at the top. Typical: 7 daily, 4 weekly, 6 monthly.

“Backup counts against my disk quota?” No — JetBackup stores backups on separate infrastructure. They don’t show up in your disk usage stats.

“How do I restore to a different account?” Use Download to get the archive, then Restore the archive from the destination account’s JetBackup interface (or contact support for assisted migration).

“My account was suspended/terminated — can I still access backups?” Suspended accounts retain backup access while paid up. Terminated accounts have their backups retained per our retention policy briefly, but recovery becomes much harder. Open a ticket immediately if you need post-termination backup access.

“Restore failed halfway.” Rare, but possible with very large accounts or during high server load. Re-run the restore; if it fails twice, open a ticket and we’ll do it server-side.

What’s next

• Avoiding the need for restores: WordPress hardening, malware cleanup guide.
• Database management: phpMyAdmin guide.
• VPS-specific backup approaches: VPS backup options.

JetBackup 5 is the kind of feature you hope never to use — but when you need it, you really need it. Spend 10 minutes clicking around the interface once so the workflow is familiar before an actual crisis.