When the backup is slow, the first suspect is the storage disk, and the first answer is buying disks. It’s worth knowing where the real bottleneck is first. When the backup sends data to the storage, what holds the speed back: the network, SSH encryption or the storage disk?
Why it matters to whoever runs the server
- The storage disk wrote as fast as throwing the data away (91 MB/s versus 89 MB/s). Here, new disks wouldn’t make the backup any faster.
- The ceiling was the SSH connection, about 90 MB/s each. That decides how long a big account takes, and shows where to work: Lab 06 found the cause.
See the data as a table
| Step | What it measures | Speed |
|---|---|---|
| Sent over SSH, discarded at the destination | network and encryption, no disk | 89 MB/s |
| Sent over SFTP, written to disk | the full path | 91 MB/s |
| Copy inside the storage, forcing the write | the disk reading and writing at once | 75 MB/s |
| Read inside the storage | may have come from the ZFS cache | 154 MB/s |
Method
Source: cPanel test server (CentOS 7, 18 cores). Destination: ZFS backup storage, in a virtual machine on the internal network, with virtual NICs on both ends.
A 4 GB file of random data, so ZFS compression couldn’t “help” and the number stays honest.
At a time with no other backup writing to the storage; low priority on the source server.
What we decided
Nothing changes at the destination: the storage disk keeps up with the upload. In the cache test, a 5.7 GB account was copied in about 50 s (more than 100 MB/s read) and fit under this ceiling because the engine sends less than it reads: identical chunks within the account are not sent again.