Overview
We have received reports from customers running CloudLinux 8 and newer where the system load appears higher while JetBackup jobs are running.
Following an investigation and discussions with CloudLinux, this behavior is not necessarily caused by JetBackup suddenly using more resources. CloudLinux confirmed that recent kmod-lve updates altered how the load average is calculated and reported. While JetBackup executes the same workload as before, CloudLinux is now reporting the actual load differently or more accurately.
Note: CloudLinux published a status update regarding higher load average reporting after kernel and
kmod-lveupdates. They noted that CPU, IO, and vmstat metrics may not indicate an actual performance bottleneck even though the reported load average is higher. Read more in the CloudLinux Support Article.
Separately, JetBackup 5 resource limits require cgroup v2. If your system operates on cgroup v1, JetBackup cannot enforce configured CPU, IO, or memory limits. Backups and restores will continue to function normally, but limits will not be applied.
Why This Happens
CloudLinux environments use LVE (Lightweight Virtual Environment) for resource management. Historically, many CloudLinux environments operated with cgroup v1 for LVE compatibility.
This means there are two related but separate points:
- Reported load may now appear higher because CloudLinux changed how load average is calculated and reported.
- JetBackup resource limits require cgroup v2, so they are not enforced when the server is operating with cgroup v1.
CloudLinux has since announced support for cgroup v2, which provides a path forward for environments that need cgroupv2-based resource controls. (https://blog.cloudlinux.com/cloudlinux-now-supports-cgroup-v2)
Why JetBackup 5 Uses cgroup v2
JetBackup 5 uses cgroup v2 for resource limit enforcement because cgroup v2 provides a unified and more reliable resource control model.
This direction was chosen after evaluation during JetBackup 5 development and early ALPHA testing. At that time, we reviewed reports where CPU and IO limits were not being enforced reliably under cgroup v1. Based on that testing and feedback, cgroup v1 was not considered a dependable foundation for JetBackup 5’s resource control model.
This also aligns with the Linux kernel documentation, which describes cgroup v2 as the unified hierarchy and explains the design limitations and issues that existed with cgroup v1:
https://docs.kernel.org/admin-guide/cgroup-v2.html#issues-with-v1-and-rationales-for-v2
For this reason, JetBackup 5 resource limits are designed around cgroup v2 rather than cgroup v1.
Why This May Have Started Recently
Some customers have reported this behavior appearing only recently. In these cases, the relevant CloudLinux update may have already been installed earlier, but the updated cgroup configuration did not take effect until the server was rebooted. Since tuned profile and boot parameter changes are typically applied at boot time, the impact may only become visible after a later reboot.
In other words, JetBackup may be performing the same backup activity as before, but the server is now reporting that load differently.
Because this load reporting behavior is controlled by CloudLinux kernel / LVE components rather than JetBackup, this can occur independently of any JetBackup update.
What This Means
If the server is running cgroup v1, JetBackup's core functionality, including Backups and Restores, will continue to work normally; however, any Resource Limits configured in JetBackup are not enforced.
This may result in higher reported system load during backup operations compared to what customers previously observed. With newer CloudLinux updates, that higher load may reflect a change in load average reporting rather than a sudden increase in JetBackup resource usage.
How to Check Your Server
You can verify which cgroup hierarchy your server is using by running the following command:
if stat -fc %T /sys/fs/cgroup | grep -q cgroup2fs; then if mount | grep -q "type cgroup "; then echo hybrid; else echo cgroup2fs; fi; else echo tmpfs; fi
Expected Results
If the output is:
cgroup2fs
The system is using cgroup v2, and JetBackup resource limits should function normally.
If the output is:
tmpfs
The system is using cgroup v1, and JetBackup will not be able to enforce resource limits.
If the output is:
hybrid
The system is using both cgroup v1 and v2. JetBackup resource limits should function normally. CloudLinux indicated that LVE currently does not support this configuration.
Temporary Mitigation
If your server is currently operating with cgroup v1, JetBackup cannot enforce resource limits.
As a temporary mitigation, you may consider reducing JetBackup concurrency settings to lower overall resource usage during backup operations.
The following settings may help:
• Concurrent Maximum Threads
This setting controls how many destination operations can run in parallel, such as upload, download, delete, and related destination actions.
Lowering Concurrent Maximum Threads can reduce CPU, IO, network, and destination-side pressure during backups. In some cases, lowering this value can also improve backup completion time, especially when excessive parallelism is causing contention or destination throttling.
Important: lowering Concurrent Maximum Threads does not automatically mean backups will become slower. In some environments, we have seen backup runtimes improve significantly after lowering this value, including cases where backups that previously took around 1 to 1.5 days completed in approximately 1 to 2 hours after tuning.
• Concurrent Tasks
Lowering these values reduces the number of backup operations running in parallel, which may help decrease CPU, IO, and load impact during backups.
Please note that this does not replace resource limiting, and it may increase the total time required for backup jobs to complete.
cgroup v2 Support
CloudLinux has announced support for cgroup v2. Customers who require JetBackup resource limits should review CloudLinux’s current cgroup v2 support guidance and confirm whether enabling cgroup v2 is appropriate for their environment, especially if they rely on LVE.
Once the server is operating with cgroup v2 in a supported CloudLinux configuration, JetBackup resource limits should function normally.
https://blog.cloudlinux.com/cloudlinux-now-supports-cgroup-v2
Summary
If your server is running CloudLinux 8+ with cgroup v1, JetBackup resource limits cannot currently be enforced.
This does not affect backups themselves, only the ability to limit their resource usage.
The recent increase in reported load appears to be related to CloudLinux load average reporting changes, not necessarily JetBackup suddenly using more resources.
In the meantime, lowering Concurrent Maximum Threads on the destination appears to be the most effective mitigation based on previous reports and testing. Lowering this value can reduce resource contention and, in some environments, may even improve backup completion time.
