Panellicense

Set up JetBackup 5 deduplication backups to cut storage cost

JetBackup 5.4 added a deduplication backup structure that fingerprints data in chunks and stores each unique chunk once — here's how it works, where it pays off, and how to turn it on.

6 min readUpdated 2026-07-29jetbackup-5 · deduplication · backup-structure · storage-cost
schema: HowToschema: FAQPageschema: BreadcrumbList

JetBackup 5.4.0 (April 2026) added a fourth backup structure — Deduplication — alongside the existing Incremental, Archived, and Compressed options. Instead of storing whole files or file deltas per snapshot, it splits data into content-defined chunks, fingerprints each one with a cryptographic hash, and writes any given chunk to the destination exactly once, no matter how many accounts or snapshots reference it.

For hosts paying per gigabyte on S3, Wasabi, or Backblaze B2, this is the first structural change to JetBackup's storage model in years. This guide covers how it differs from the existing structures, where the savings actually show up, and how to turn it on without breaking an existing job.

How it differs from Incremental, Archived, and Compressed

The three older structures all operate at the file level:

  • Archived writes a full .tar snapshot every run — no dedup, no deltas, largest footprint.
  • Compressed does the same as Archived but with gzip — smaller on disk, more CPU per run.
  • Incremental (local and SFTP destinations only) uses hardlinks to earlier snapshots for unchanged files, so a 30-day retention window costs roughly one full snapshot plus 30 days of deltas rather than 30× the size.

Deduplication works below the file level. A WordPress wp-includes/ directory that's byte-identical across 200 customer accounts on the same server gets fingerprinted once and stored once, referenced 200 times. The same applies across snapshots of a single account — if a 2 GB uploads/ folder doesn't change between Tuesday and Wednesday, Wednesday's backup references Tuesday's chunks instead of rewriting them. Chunks are also encrypted at rest, which is new relative to the plaintext Archived/Compressed structures.

The practical effect: Incremental already deduplicates within one account over time using hardlinks, but hardlinks don't work on object storage and don't dedupe across accounts. Deduplication does both, which is why the gains are largest on shared servers with a lot of near-identical accounts (WordPress- and cPanel-account-heavy environments) backing up to S3-compatible storage.

Enable deduplication on a backup job

Deduplication is set at job creation, not toggled on an existing job.

  1. In WHM, go to JetBackup 5 → Manage Jobs → Create New Job.
  2. Under Backup Structure, select Deduplication (it sits alongside Incremental, Archived, and Compressed).
  3. Configure Account Filter, Schedules, and Destination as normal — dedup works with any destination type, but the cost case is strongest on object storage.
  4. Save and run the job once manually before trusting it to a schedule, so you can confirm chunk upload completes cleanly and check the job log for errors.

Update to 5.4.1 before running it in production

JetBackup 5.4.1 (July 2026) shipped restore reliability fixes specifically for deduplicated backups, alongside improvements to destination performance testing and dashboard filtering. Deduplication is new enough — three months old at time of writing — that running 5.4.0 in production without the follow-up patch is a bad trade for a feature whose entire point is protecting your restore path. Check your installed version in JetBackup 5 → About, and update via WHM's plugin manager if you're behind.

Plan for the CPU and IO tradeoff

Chunking and fingerprinting cost CPU during backup, and chunk-lookup adds IO during restore compared to a straight file copy off an Archived snapshot. On a busy shared server, that's a real cost — schedule the first few dedup runs outside your peak backup window and watch load average, the same way you'd stagger any new JetBackup destination performance test. Restore time for a single account is usually not noticeably different; a full bare-metal restore across thousands of chunks is where the IO overhead is most visible, so test that path specifically rather than assuming single-account restores represent it.

Verify the storage savings

Compare destination usage before and after switching a representative job. For S3-compatible destinations, check the bucket's actual stored size via the provider console rather than trusting JetBackup's reported usage figure alone — it can lag the true bucket size by up to one job run, the same caveat that applies to retention pruning. Run the same account set through Archived or Incremental first to get a baseline, then switch to Deduplication and compare after a full retention cycle — the first snapshot won't show much benefit since there's nothing to dedupe against yet.

What is JetBackup 5 deduplication and how is it different from incremental backups?+
Deduplication is a new backup structure in JetBackup 5.4 that splits data into content-defined chunks and stores each unique chunk once, referenced across accounts and snapshots. Incremental backups only dedupe a single account's data over time via hardlinks, and only on local or SFTP destinations — they don't dedupe across accounts and don't work on object storage.
Can I switch an existing JetBackup job to deduplication?+
No. Deduplication is set when a job is created and there's no in-place conversion from Incremental, Archived, or Compressed. Create a new job targeting a new destination path, verify restores work, then retire the old job under its existing retention policy.
Does JetBackup deduplication work with S3 and Wasabi destinations?+
Yes, and that's where it delivers the most value — object storage destinations don't support the hardlink-based dedup that Incremental uses locally, so chunk-level deduplication is the only way to avoid paying for duplicate data across accounts on S3, Wasabi, or B2.
Is JetBackup 5 deduplication safe to use in production?+
Wait for at least version 5.4.1, released July 2026, which fixed restore reliability issues specific to deduplicated backups. The structure itself is sound, but it's new — run it alongside your existing backup structure for one full retention cycle and confirm restores before retiring the old job.
Does deduplication slow down JetBackup restores?+
Single-account restores aren't noticeably slower. Large-scale restores — bare-metal or multi-account — carry more IO overhead from chunk lookups than a straight file copy off an Archived snapshot, so test that path specifically before relying on it for disaster recovery.

Next steps

Related articles

All tutorials & how-tos →
how to
Plesk 360 setup guide for centralized licenses and monitoring
Plesk 360 is the SaaS control plane for everyone running more than one Plesk box — license management, uptime monitoring, and SSO into every panel from one dashboard.
7 min read
how to
Use the Plesk REST API with reseller and customer accounts
Plesk Obsidian 18.0.79 opens the REST API to reseller and customer accounts and adds file, log, and impersonation endpoints — how to authenticate and use them.
7 min read
how to
How to move a cPanel license to a new server or IP address
cPanel licenses are bound to a primary IP, not a server. Here's how to repoint one to a new IP after a migration, IP change, or provider swap without downtime.
6 min read
Switch in an afternoon

Switch from your current reseller — free.

We migrate active cPanel, Plesk, LiteSpeed and CloudLinux licenses from any reseller. We prorate the first month so you never pay twice, and your customers see zero downtime during the swap.