I got a bit bored this morning, probably have many other things I should be doing but after seeing this thread here and on WHT; I thought I'd take a look.
What happens when a backup is kicked off, in simple terms: The source server creates a SSH connection to the backup server and starts a rsync server, the source server starts a rsync transfer of the website files using archive and compress modes. Archive mode keeps all file and directory timestamps, ownership, etc. Compress mode compresses the data ready for transfer over the network - this is why you're seeing a CPU spike as it takes CPU cycles to compress this data.
The rsync process runs within the website user account, I haven't looked into the cgroup implementation so it's a 'more than likely' correction assumption that the rsync process is contained to the limits you set on the package. However, by default rsync is a single threaded application so it can theoretically only use 100% of 1 CPU/Thread anyway. But... if you are running multiple backups at the same time then you're going to see this spike higher as each rsync process will use up to 100%, therefore, 10 concurrent backups * 100% = 1,000% or 10 CPU/Threads.
You will not only be limited to the 1,000% CPU though as there's network throughput and disk throughput happening at the same time which increases the CPU load so you're actually using more than 1,000%.
The Disk I/O graph you've posted is Disk I/O and not a memory graph so the Swap you're seeing isn't memory swap. Disk I/O Swap isn't very accurate, it's more of a generalisation and there are better ways to graph disk I/O. Disk I/O Swap counts all input/output operations including memory usage, file read/write operations and any other interactions with the storage so it's pretty useless to drill down into any troubleshooting using Disk I/O swap.
I monitored my source server while performing a 19GB backup and there was minimal memory usage and no memory swap usage from the process.
For reference, here's a screenshot of the rsync process while transferring the backup from top:
![](https://i.ibb.co/zhTWwh6/Screenshot-2024-01-19-at-09-16-06.png)
These are the rsync commands mentioned earlier:
`root@redacted:/var/www/152074ae-14f1-449c-82f1-c428c7969de5/public_html# ps -ef | grep rsync
testweb+ 1852504 132209 98 09:23 ? 00:00:17 rsync -e ssh -p 222 -i /tmp/41949d97-4bdf-45c9-8c1a-fc0ae8461077 -o StrictHostKeyChecking=no -o BatchMode=yes --archive --verbose --compress --delete /var/www/152074ae-14f1-449c-82f1-c428c7969de5/ testwebs1@redacted:/backups/152074ae-14f1-449c-82f1-c428c7969de5/backup-subvolume/home
testweb+ 1852505 1852504 0 09:23 ? 00:00:00 ssh -p 222 -i /tmp/41949d97-4bdf-45c9-8c1a-fc0ae8461077 -o StrictHostKeyChecking=no -o BatchMode=yes -l testwebs1 redacted rsync --server -vlogDtprze.iLsfxC --delete . /backups/152074ae-14f1-449c-82f1-c428c7969de5/backup-subvolume/home`