Penalties for excessive server usage due to backups

  • Hi everyone. My wife and I have been using i-MSCP for the past 4 or 5 years and we're very pleased with it. I'm having a "unique" problem with a vService provider. We've had either a root server (during the 90s) or a vServer for over 20 years, most recently with a provider whom we signed up with in 2014.

    During the past 20+ years we've always had similar domain sizes and usage, consisting primarily of emails, photo albums, a few music files, and so on. Throughout this time there's always been one domain or another that was used for professional purposes, ranging in total file size from 1 GB to 3 GB for that entire domain. Little to no automation, videos, streaming media or other taxing items, mostly just raw data consisting of html, xml, jpg, png, and a few php scripts. In over 20 years we've never ever had any "excessive use" issues with any server/vServer provider ... UNTIL NOW ... even though the server hardware configurations have improved tremendously throughout all of this time.

    Lately we've been receiving warnings for our vService provider that we'd be penalized or fined or that our vServer may even be shut down completely, if we didn't curb the excessive usage or drain that our vServer is generating on the vServer provider's system i.e. their other clients. This has never occurred before and little to nothing has changed on our domains during the past couple of years. As a matter of fact, we've even removed domains and lessened our email usage, yet suddenly our vServer is (supposedly) generating a serious problem ??? (see attached images)

    We do have a trusted Admin that we hire on a job by job basis. We showed our admin the information and were told that based on our vServer stats it should be impossible to create such a massive drain on our vServer providers system, that it would impact their other clients. The admin went as far as to say that the claim was preposterous, followed by implying that perhaps the provider's equipment was faulty, slow, or outdated. However, since we paid for a "killer system" based on our personal minimal requirements, I'm now looking for a second opinion. I'm including the specs of the exact vServer which we're running, along with the providers screenshot of a log, where he claims there's proof that our vServer is bogging everything else down.
    We're interested in what you think about the provided log image, compared to the hardware that we paid for.
    Thank you for your time.


  • @LinWinux


    About the i-MSCP backup feature

    i-MSCP offers a backup feature which can consume CPU time and which can involve many IO operations, depending on the size of your mail and web folders. The backup is made every days at the same hour through a cron task. The default configuration doesn't take in consideration any restriction made by your provider. For instance, by default, the backup script will use all CPU cores available (parallele jobs), and will run every days. You can change all this of course to mitigate CPU time consumption by editing some configuration values. For instance, you can edit the /etc/imscp/imscp.conf file and change the following configuration parameter:

    1. ZIP = pbzip2


    1. ZIP = bzip2

    By doing this, only one CPU core will be involved at once, which will mitigate your CPU time consumption.

    Another thing you can do is to perform the backup on a weekly basis instead of a daily basis. To do so, you must edit the /etc/cron.d/imscp file and change:

    1. # Backup i-MSCP configuration files and database@daily root perl /var/www/imscp/engine/backup/imscp-backup-imscp > /var/log/imscp/imscp-backup-imscp-mngr.log 2>&1


    1. # Backup i-MSCP configuration files and database
    2. @weekly root perl /var/www/imscp/engine/backup/imscp-backup-imscp > /var/log/imscp/imscp-backup-imscp-mngr.log 2>&1

    Once done, your problem should be gone.

    About your provider

    You use a vserver and as such, that server is hosted on an host which is used by many clients. The problem here is not really you, nor i-MSCP. The problem is your provider that is not able to limit your vserver properly to avoid such problem.


  • Thanks a lot for the advice and clarification. Definitely something to keep in mind from now on. I'm curious though, if you can verify or clarify that based on the log file .gif, our vserver is truly and clearly (as our provider claims) managing to severely impact the use of other clients just because of the backup that's taking place?

    I'm really curious about this because we have very limited server knowledge. So my wife and I always figured that as long as we have a vServer with hardware configurations that "wildly surpass" anything that we might ever need, we'd be good to go? After all, what's the use of paying for "dedicated multiple cpu cores with oodles of ram and disk space" if all of those specs aren't enough to make sure that our vserver isn't negatively impacting someone else?


  • @LinWinux

    The problem here is that we lack information. Your provider assigned 4 virtual CPU cores to your vserver but we don't know if those CPU cores are shared with other clients (other vservers) or not. According your screenshot, we can see that you're consuming a lot of CPU time (all your CPU cores are at ~ 98%). That can explain why your provider is not happy and would want see you away.

    To resume, if the CPU cores are shared with other clients, this can really pose problem for them, else, this should not. But if those CPU cores are shared, I would recommend you to go away from that provider.

    However, if you apply what I've said in my previous post, that problem should be solved ;)

    If you need help to configure your server, feel free to add my SSH key (see in my signature).


  • Thank you so much for all of your help. We'll keep what you said in mind. I'll mention your suggestions to our admin as well since we want to make sure that we avoid further problems down the road. Have a great evening.

  • You're welcome.


  • Could also be because you generate a lot of IO during backup. During backup if you still have it set to pbzip2 try to run the following commands:

    1. # vmstat -S m -w 1 20
    2. # iostat -m 1 20

    If you don't have iostat install do: sudo apt-get install sysstat
    Post the output in a bin and share the link.

  • @courier

    i-MSCP offers a backup feature which can consume CPU time and which can involve many IO operations

    But, normally, the backup script is run with ionice to mitigate sush problem.


  • @c0urier

    The problem here seems related to CPU time (see the provided htop screenshot). I don't say that there is no IO problem here and your advices are also relevant. ;)