Hmmm .... 'shared hosting' .... there are sites on the net that given an IP will show how many host are on that IP - dunno how accurate they really are, but .... you saw 5 users (customers - how do you know that?) are 5 other web based applications being hosted on a server that has 43112192k (according to top) memory.
There are probably memory hungry processes/apps that run on those other host from time to time which have to be metered on a shared host so that no one customer can use more than their allocated share.
On a standalone (not shared), like I mentioned, while watching top I've seen PHP peg the CPU at 100% for a few seconds on backing up what ended up as a 60+ Gig Moodle backup via CLI (have seen the same on other servers that have larger courses - 90+ Gig).
Ok, so the backups are slow when running the autobackup via Moodle. Faster when running single course backups via CLI ... as long as they complete and the users experience is acceptable then think you'll have to live with it. However, ever think that one could have a 'nibuc' (non-interactive backup courses) bash shell script that uses the CLI single backup in a loop of course ID numbers. Have such a script for large courses on systems where there are large courses ... two scripts, as a matter of fact ... one for the 'normal courses' and one that backups up only the large courses. Can't run autobackups on those boxen due to those large courses.
Also mentioned that rsync was slow ... you are doing that incremental, yes? That shouldn't be slow I would think (of course that depends upon what is being added to courses ... videos/audios? - don't forget if you have the backups going to filedir as opposed to an alt directory then backups of courses would take a little longer)
Let's face it ... Moodle (full featured + plugins), as it moves upwards, is more resource hungry. The days of shared hosted Moodle (full featured) might be numbered with some providers.
'spirit of sharing', Ken