Configure JetBackup 5 destinations on cPanel — S3, B2, and SFTP

JetBackup 5 ships with a long list of supported destination types, but the three that cover ~95% of real hosting deployments are S3-compatible (AWS S3, Wasabi, MinIO, DigitalOcean Spaces, Cloudflare R2), Backblaze B2, and SFTP to a separate box. This guide walks through configuring each one cleanly on a cPanel server, plus the four default settings that silently break large jobs.

Budget 30 minutes for the first destination — most of which is creating the bucket and IAM policy at the provider side — and 5 minutes per additional destination after that. You need a working JetBackup 5 license on a cPanel + WHM server with the plugin already installed under WHM → Plugins → JetBackup 5.

Before you start

• JetBackup 5.3 or newer. The destination plugin set changed substantially between 5.2 and 5.3 — older guides referencing Amazon S3 as a separate type are obsolete; everything S3-shaped now lives under S3 Compatible.
• 50-100 GB of free space on the cPanel server's backup partition. Jobs stage locally before uploading, so even with an offsite-only retention policy you still need the working space.
• Outbound HTTPS (port 443) open to the destination endpoint. SFTP destinations need outbound TCP 22 (or whatever the target SSHd listens on).
• A separate IAM user, application key, or SSH key per destination — never reuse your root cloud credentials. JetBackup stores destination credentials in /usr/local/jetapi/data/ and they're recoverable from a server image.

Destination type, briefly

Pick by cost-per-GB and recovery profile, not by familiarity:

For most independent hosts, Backblaze B2 + a weekly SFTP to a colo box is the cost-optimal pair. AWS S3 is rarely the right answer unless billing constraints lock you in.

Step 1 — Create the destination at the provider

The pattern is the same for every S3-compatible target:

1. Create a bucket. Name it <hostname>-jetbackup — JetBackup writes everything under a single bucket and uses a folder hierarchy internally.
2. Disable public access. JetBackup writes encrypted blobs, but a misconfigured bucket policy is still the most common backup-data leak.
3. Create an IAM user (AWS), application key (B2), or access key (Wasabi/R2) scoped to the bucket only. The minimum permissions are GetObject, PutObject, DeleteObject, ListBucket, and ListAllMyBuckets.
4. Save the access key ID, secret key, and endpoint URL — you'll paste them into JetBackup in the next step.

For Backblaze B2 specifically, the endpoint format is https://s3.<region>.backblazeb2.com when using the S3-compatible API. Don't use the native B2 API endpoint — JetBackup 5 deprecated the native B2 connector in 5.4.

Step 2 — Add the destination in JetBackup

In WHM → JetBackup 5 → Destinations → Create New Destination:

Type:        S3 Compatible
Name:        b2-primary
Path:        /                      ← leave as root, JetBackup creates its own subfolders
Bucket:      myhost-jetbackup
Endpoint:    https://s3.us-west-002.backblazeb2.com
Region:      us-west-002
Access Key:  <your-application-key-id>
Secret Key:  <your-application-key>

Hit Validate Destination before Create. JetBackup uploads a 1 KB test object, lists the bucket, and deletes the test object. If validation fails, the error tells you which step broke — 403 is almost always a permission missing from your IAM policy, 404 is a typo in the bucket name or wrong region in the endpoint.

For SFTP, the same form takes a host, port, username, and either a password or an SSH private key. Use the key — JetBackup encrypts it at rest, password auth ages badly:

Type:        SSH
Host:        backup.example.net
Port:        22
Username:    jetbackup
Auth Type:   Private Key
Path:        /home/jetbackup/incoming

Drop the SFTP target's host key into JetBackup's known_hosts on first connect via the validation step — JetBackup pins the host key and refuses to upload if it changes later, so plan for that on key rotation.

Step 3 — Tune the four defaults that break large jobs

Out of the box, JetBackup 5's destination defaults work for a single small server and fail once you have real customer data on the box:

1. Concurrent transfers. Default is 4. On a 1 Gbps uplink uploading to Backblaze B2, bump to 12-16. JetBackup uses parallel multipart uploads per file, so this number is per-account-being-backed-up, not per-server. Too high and you'll saturate the upstream link and starve other services on the box.

2. Chunk size. Default is 100 MB. For accounts with single files >1 GB (typical for anyone hosting databases or media sites), increase to 250 MB. Larger chunks reduce the round-trip overhead but increase the retry cost on a failed transfer.

3. Encryption. Default is off. Turn it on — JetBackup's client-side AES-256 encryption is the difference between a leaked bucket being an embarrassment and being a notification-triggering breach. Generate the key inside the JetBackup UI and back it up to a password manager before the first run. If you lose the encryption key the backups are unrecoverable — JetBackup support cannot decrypt them.

4. Retention versus destination. The retention policy lives on the schedule, not the destination. A destination with no schedule pointing at it accumulates orphan data forever. Set up at least one schedule per destination immediately or run weekly cleanup with jetapi backup --remove-orphans.

Step 4 — Attach the destination to a schedule

A destination on its own doesn't do anything. In JetBackup 5 → Schedules → Create New Schedule:

Name:              daily-offsite-b2
Type:              Account
Schedule:          Daily @ 02:00
Destinations:      [b2-primary]
Retention:         7 daily + 4 weekly + 6 monthly
Compression:       gzip-fast
Disable on quota:  Yes

The retention numbers above (7/4/6) are conservative for shared hosting. Reseller and VPS hosts usually push to 14/8/12. Each tier multiplies the storage cost roughly linearly — a 30 GB account with 7+4+6 retention sits at ~510 GB on the destination steady-state.

Step 5 — Verify the first job end-to-end

Trigger a manual run on a single small account first:

jetapi backup --create --account testuser --schedule daily-offsite-b2

Watch the live log under JetBackup 5 → Jobs → Running Jobs. A healthy first run goes: Queued → Snapshotting → Compressing → Encrypting → Uploading → Verifying → Completed. The Verifying step downloads the manifest from the destination and confirms the chunk count and checksums match — this is the step that catches misconfigured destinations that accept writes but corrupt them.

If the job completes but the destination shows no folder, you've hit the most common gotcha: the IAM policy allowed PutObject but not ListBucket, so JetBackup wrote the chunks but failed verification and rolled back. Add ListBucket and rerun.

Restoring from an offsite destination

This is where the 30-minute setup pays off — or doesn't. Practice a restore the same day you configure the destination:

jetapi restore --account testuser --backup latest --destination b2-primary

A working restore pulls the manifest, validates checksums, decrypts, and writes the account back. Time the restore. A 10 GB account from B2 typically takes 8-15 minutes on a 100 Mbps download link, mostly bottlenecked by the local disk write rather than the network. If your real-world restore SLA is "within an hour" and your largest account is 200 GB, do the math — you may need an additional faster destination (local NAS, on-net SFTP) for the recovery-critical subset of accounts.

How JetBackup interacts with other tools on the box

A few integrations that cause questions:

• Imunify360 excludes JetBackup automatically from malware scanning — no manual exclude list needed.
• CloudLinux LVE limits apply to the backup process by default. If jobs are getting killed for hitting IO limits, exempt the jetbackup5 user from LVE under CloudLinux LVE tuning.
• WHM backups still run independently if you haven't disabled them. Two backup systems doubling up on disk IO at 2 AM is a common cause of overnight load alerts — pick one and disable the other.

For licensing — JetBackup 5 is per-server, not per-account, and the same license covers unlimited destinations. See the pricing breakdown or contact us for volume questions if you're licensing more than 10 servers.

Next steps

• Pair offsite backups with CloudLinux LVE tuning so backup jobs don't get killed by per-user IO limits at 2 AM.
• For shared hosts running Imunify360 alongside JetBackup, the security agent auto-excludes JetBackup paths but custom backup scripts need a manual exclude.
• Migrating from another panel? The DirectAdmin-to-cPanel migration guide covers the JetBackup re-attach step for accounts imported via the WHM transfer tool.