When it comes to backing up your hosted website, you have two fundamental approaches: full backups that copy everything every time, and incremental backups that copy only what has changed since the last backup. Each approach has distinct advantages and tradeoffs in terms of storage consumption, backup speed, restore complexity, and reliability. Choosing the right strategy — or the right combination — depends on your site's size, change rate, recovery requirements, and budget.
This guide provides a clear, practical comparison of incremental and full backups in the context of web hosting, with specific guidance for cPanel-hosted websites. Whether you are managing your own server or relying on a provider like MassiveGRID's high-availability cPanel hosting, understanding these backup methods helps you make informed decisions about your data protection strategy.
How Full Backups Work
A full backup creates a complete copy of your entire hosting account every time it runs. Every file, every database, every email, every configuration — regardless of whether it has changed since the last backup. The result is a self-contained archive that can restore your site to its exact state at the time the backup was created.
Characteristics of Full Backups
- Complete and self-contained — each backup is independent; you need only one backup file to perform a full restore
- Simple to understand — there is no chain of dependencies; each backup stands alone
- Storage-intensive — every backup is the same size as your entire account, regardless of how much actually changed
- Time-consuming — copying everything takes longer than copying only changes
- Reliable restores — because each backup is independent, a corrupted backup does not affect other backups
How cPanel Full Backups Work
When you or your hosting provider runs a full cPanel backup, the system:
- Compresses your entire home directory into a tar archive
- Dumps all MySQL databases to SQL files
- Exports email data, DNS zones, SSL certificates, and cPanel configurations
- Packages everything into a single
.tar.gzfile
The resulting file is a complete snapshot. For a full walkthrough of this process, see our guide on how to download and verify a full cPanel backup.
How Incremental Backups Work
An incremental backup copies only the files that have changed since the last backup (whether the last backup was full or incremental). This dramatically reduces the amount of data copied and stored with each backup cycle.
Types of Incremental Backups
| Type | What It Copies | Restore Requires | Storage Efficiency |
|---|---|---|---|
| Standard incremental | Files changed since the last backup (any type) | The last full backup + all subsequent incrementals | Highest efficiency |
| Differential | Files changed since the last full backup | The last full backup + the latest differential | Moderate efficiency; faster restores than standard incremental |
| Block-level incremental | Only the changed blocks within files (not entire files) | Full backup + all subsequent incrementals | Maximum efficiency for large files |
How Incremental Detection Works
Incremental backup systems track changes using one or more methods:
- File modification timestamps — the most common method; compares the file's last-modified time against the backup's reference time
- File checksums — computes a hash of each file and compares it to the hash stored during the previous backup; more reliable but computationally expensive
- Filesystem change journals — some filesystems (like NTFS or ext4 with inotify) track changes at the filesystem level, providing instant change detection without scanning every file
How cPanel Incremental Backups Work
cPanel's backup configuration system supports incremental backups when configured by the server administrator through WHM. When enabled, the backup system uses rsync-style file comparison to identify changed files and only copies those files to the backup destination. Databases are still fully dumped each time (SQL dumps are not easily incremented), but file-level incremental handling significantly reduces backup time and storage for accounts with large file sets that change infrequently.
Side-by-Side Comparison
| Factor | Full Backup | Incremental Backup |
|---|---|---|
| Storage per backup | Equal to total account size (e.g., 10 GB per backup) | Only changed data (e.g., 200 MB per backup if 2% changed) |
| Backup speed | Slower; must copy everything | Faster; copies only changes |
| Restore speed | Fast; single archive to extract | Slower; must reconstruct from full + all incrementals |
| Restore complexity | Simple; one file, one operation | Complex; must have full backup + unbroken chain of incrementals |
| Reliability | High; each backup is independent | Lower; a corrupted incremental can break the entire chain |
| Server load during backup | High; reads all data every time | Lower; reads only changed data (plus change detection overhead) |
| Best for | Small to medium accounts; weekly/monthly long-term retention | Large accounts; frequent daily backups; storage-constrained environments |
The Hybrid Approach: Full + Incremental
In practice, most well-designed backup strategies combine both methods. The most common pattern is:
- Weekly full backup — creates a complete, independent restore point every week
- Daily incremental backups — captures day-to-day changes with minimal storage overhead
- Monthly full backup retained long-term — provides clean restore points for historical recovery
This hybrid approach gives you the storage efficiency of incremental backups for daily operations while maintaining the reliability and simplicity of full backups at regular intervals. If an incremental chain becomes corrupted, you never lose more than a week's worth of incremental data because the next full backup starts a fresh chain.
Hybrid Example: 10 GB Website
| Backup Type | Frequency | Size per Copy | Retention | Total Storage |
|---|---|---|---|---|
| Full | Weekly (Sunday) | 10 GB | 4 weeks | 40 GB |
| Incremental | Daily (Mon-Sat) | ~0.5 GB (5% change) | 7 days | 3 GB |
| Full (archive) | Monthly | 10 GB | 3 months | 30 GB |
| Total storage | ~73 GB | |||
Compare this to a full-backup-only strategy with the same retention: 7 daily (70 GB) + 4 weekly (40 GB) + 3 monthly (30 GB) = 140 GB. The hybrid approach uses roughly half the storage while providing the same recovery points.
Which Approach Is Right for Your Website?
Use Full Backups Only If:
- Your hosting account is small (under 5 GB)
- Storage cost is not a concern
- You want the simplest possible backup and restore process
- You do not have administrative access to configure incremental backups
- You are downloading manual backups to your local machine
Use the Hybrid Approach If:
- Your hosting account is medium to large (5+ GB)
- You run daily backups and want to minimize storage costs
- You have WHM access or your hosting provider supports incremental configuration
- Your site has many large files that rarely change (media libraries, archives)
Prioritize Incremental If:
- Your hosting account is very large (50+ GB)
- Backup windows are tight (backup must complete during off-peak hours)
- Network bandwidth is limited (important for off-site backup transfers)
- You need frequent backups (every few hours) to meet aggressive RPO targets
How Backup Type Affects Recovery Time
One often-overlooked factor is how backup type affects your Recovery Time Objective (RTO) — how quickly you can restore your site after an incident.
Full backup restore: Extract one archive, import databases, done. Time depends on account size but is straightforward.
Incremental backup restore: You must first restore the last full backup, then apply each incremental backup in sequence until you reach your target restore point. If you have 6 daily incrementals between the last full backup and your target point, that is 7 restore operations instead of 1.
For a disaster recovery plan with a tight RTO, consider how the restore process works when choosing your backup strategy. If you need fast restores, ensure your full backup intervals are short enough that you do not have to apply too many incrementals.
Database Backups: A Special Case
Databases are not well-suited to traditional file-level incremental backups. A MySQL dump file changes entirely even if only one row in one table is updated, because the dump regenerates the entire SQL file. This means:
- File-level incremental backup will see the database dump as "changed" and copy the entire dump every time — no storage savings for databases
- Block-level incremental backup can detect that only a small portion of the dump file changed and copy only those blocks — significant savings for large databases
- Binary log (binlog) backup — MySQL's own incremental mechanism; captures individual transactions; provides point-in-time recovery; requires server-level configuration
For websites where the database is the primary data store (WordPress, eCommerce), database backup strategy deserves special attention. Consider more frequent database-only backups (every 4-6 hours) alongside less frequent full account backups (daily). Your backup retention policy should reflect the different change rates of files vs. databases.
Backup Tools and Their Default Behavior
| Tool | Full Backup Support | Incremental Support | Notes |
|---|---|---|---|
| cPanel/WHM Backup | Yes (default) | Yes (configurable in WHM) | File-level incremental; databases always full dump |
| JetBackup | Yes | Yes (default for file backups) | Efficient incremental with block-level deduplication in newer versions |
| UpdraftPlus (WordPress) | Yes (default) | Yes (premium only) | Database always full; file incremental in premium |
| rsync | N/A (sync tool) | Inherently incremental | Only transfers changed files; ideal for SSH-based backup scripts |
| Duplicity | Yes | Yes (encrypted incremental) | GPG-encrypted incremental backups; good for sensitive data |
| Restic / Borg | Block-level dedup | Block-level dedup | Modern deduplication-based backup; extremely storage-efficient |
Real-World Scenario: Why Incremental Chain Integrity Matters
Consider this scenario: you run weekly full backups and daily incrementals. On Wednesday, the incremental backup file is corrupted due to a storage issue. Here is the impact:
- Monday's incremental: OK — depends on Sunday's full backup only
- Tuesday's incremental: OK — depends on Sunday full + Monday incremental
- Wednesday's incremental: CORRUPTED
- Thursday's incremental: UNUSABLE — depends on Wednesday's corrupted backup
- Friday's incremental: UNUSABLE — depends on the broken chain
- Saturday's incremental: UNUSABLE — depends on the broken chain
With a standard incremental chain, one corruption breaks all subsequent backups until the next full backup. This is why:
- Full backups at regular intervals are essential to limit chain exposure
- Backup integrity verification (checksums, test restores) is critical
- Off-site copies of both full and incremental backups provide redundancy
This chain dependency is the primary disadvantage of incremental backups and the strongest argument for the hybrid approach.
Recommendations for cPanel-Hosted Websites
For most websites hosted on cPanel, including those on MassiveGRID's high-availability cPanel hosting, we recommend:
- Daily full backups if your account is under 10 GB — storage is cheap and full backups are simpler to manage and restore
- Hybrid (weekly full + daily incremental) if your account is over 10 GB — the storage savings justify the added complexity
- Supplement with application-level backups for WordPress and other CMS platforms — these provide faster, more targeted recovery for CMS-specific issues
- Always maintain at least one off-site full backup regardless of your primary strategy — this is your last line of defense
- Test your restore process quarterly — especially if using incremental backups, verify that the full chain restores correctly
Frequently Asked Questions
Are incremental backups less reliable than full backups?
Individually, an incremental backup is just as reliable as any other file. The reliability concern is about the chain dependency: restoring from incremental backups requires an unbroken chain from the last full backup through every subsequent incremental. If any link in that chain is corrupted, you cannot restore to points beyond the corruption. Full backups avoid this because each one is independent. The hybrid approach mitigates this by limiting chain length.
Does my hosting provider use incremental or full backups?
It varies. Most shared hosting providers use full backups because they are simpler to manage at scale. Providers with JetBackup or similar tools may use incremental backups with deduplication. Ask your provider directly — understanding their backup method helps you assess your exposure and decide whether to supplement with your own backup strategy.
Can I switch from full to incremental backups without losing my existing backups?
Yes. When you switch to incremental, the next backup will typically be a full backup (the first in the new incremental chain), followed by incrementals. Your existing full backups remain intact and usable. There is no data loss during the transition.
How much storage do incremental backups actually save?
It depends on your site's change rate. A website where only 2-5% of files change daily will see incremental backups that are 95-98% smaller than full backups. A site with heavy daily changes (large database updates, frequent media uploads) may see less savings. For a typical WordPress site with occasional content updates, incremental backups are 10-20x smaller than full backups.
Should I use incremental backups for my off-site backup destination?
For off-site backup transfers, incremental backups are particularly valuable because they reduce the data transferred over the network. If you are sending backups from New York to Frankfurt, transferring 500 MB of changes instead of 10 GB of full backup saves significant bandwidth and time. Just ensure that full backups are also transferred periodically (weekly) so the remote destination has complete, independent restore points.