A backup that is fast in testing and slow in real life is the worst surprise: the admin sizes the window from the test, and the backup runs into the morning. The fast incrementals in the other tests benefited from files already in the server’s memory. What does a real next-day backup look like: before dawn, hours after the last access, with the engine’s cache empty?
Why it matters to whoever runs the server
- Before dawn, cold, hours after the last access: 4 s for 21 thousand files. The test time holds for the real night.
- 301 files read and 21,019 skipped without opening: the server’s disk barely works, and the sites don’t feel it.
- The scheduled account had been migrated, and Salvo marked the failure with the reason. The admin finds out right away, not on the day they need to restore.
See the data as a table
| Time | Read from disk | |
|---|---|---|
| Before dawn, all cold | 4 s | 105 MB (the changed files + the check) |
| Right after, warm disk | 2 s | 0 MB |
Method
A cPanel test server. One account (13 thousand files, 762 MB) plus the system configuration (8 thousand files), with the previous backup taken three days earlier.
It ran about 7 hours after the server’s last nightly backup, with the engine’s cache deleted beforehand, as in Salvo’s design: each account’s cache is deleted at the end of its backup.
Out of 21,320 files, only 301 were read; the other 21,019 were skipped without opening, just checking size and date.
What happened along the way: the test was scheduled for another account, which had been migrated to another server the day before. Salvo marked the run as failed, with the reason (“the folder doesn’t exist”), instead of pretending everything was fine. We redid it with another account.
What we decided
The design stays the same: each account’s cache is deleted at the end of its backup. In this test, that didn’t slow down the next day’s backup.