Incremental backups
Incremental backups that restore like a full backup
Incremental backups save time and space. Classic ones make you pay at restore time, rebuilding a long chain. Ours don’t.
The problem
A restore is the worst moment to wait.
With a traditional incremental, restoring means taking the last full backup and applying every later increment one by one. The longer the chain, the slower and more fragile it gets.
But sending gigabytes of images that never change every night wastes time, space and your client’s server resources.
How it works
Every backup has its own complete index.
- 1
Only the differences
The site compares the size and date of each file with the previous backup and sends only new or changed ones.
- 2
A complete index
For every backup the platform builds an encrypted index saying where each file lives, in that backup or an earlier one.
- 3
One-pass restore
To restore we read each needed part once: no chain to rebuild.
In detail
Fast to make, fast to restore.
- In our tests: 35 MB for the first backup, 67 KB for the next
- Every backup is complete: delete old ones without losing new ones
- Parts still in use stay as long as needed; mostly-empty ones are compacted automatically
- The database is always saved in full
- “Always full” schedules available if you prefer them
FAQ
Frequently asked questions
If I delete the first backup, do later ones still work?
Yes. Parts of the first backup still used by later ones stay in storage as long as they’re needed, and are removed only when no backup uses them.
How does the site know what changed?
It keeps the list of paths, sizes and dates from the latest backups, with no content, and compares it with the current files.
Related features
Goes well with
Try it on your clients’ sites.
During the beta we welcome agencies in small groups and set up the first sites together.