I have both an Internal and Cloud backup being performed via a scheduling.
Sometimes one is not done and the other one begins and combined they eat up 100% of my CPU as you see in this image
It there a configuration anywhere that can cause Kopia to recognize and other repo backup is being performed and so queue this snapshot until any active snapshot backups are completed?
Well, I guess that’s what you want on a Kopia server, don’t you? Handle your backups as fast as possible.
100% cpu should not be a problem, just fun the kopiaserver with “nice 10” or so, then all other processes get priority over it, so that it only uses the left-over cpu slices.
Thanks for the reply. I was not familiar ‘nice 10’ but learned about it via ChatGPT. I have begun to restrict things via systemd as shown below. However I wondered if there was a solution within Kopia that could force backups to wait their turn. Let’s say I had 10 clients on the network all scheduled to do backups. It could easily overwhelm the server so some sort of prioritizing queueing system would be nice to stack snapshot backups over ‘2, 3, 4’ or whatever the number of simultaneously snapshots would be allowed.
However I know complexities come with all this. This is my current systemd settings for kopia.
# 1-10000 range with 100 being a default value for system processes
# will cause Kopia backup to take longer to complete if other processes are actively using cpu resources
CPUWeight=50
# CPUQuota restricts Kopia to use at most 50% of one CPU core (or the equivalent across multiple cores).
# For example, 50% of one core, would use 25% of a 4 core system.
# Kopia’s performance is capped, potentially increasing the time required to complete a backup.
# In a highly parallelizable workload like a backup, restricting CPU could prevent Kopia from fully leveraging multi-core systems.
CPUQuota=50%
# IOWeight sets a relative I/O priority for the service, with values ranging from 1 (lowest priority) to 1000 (highest priority). The default for most services is 100.
# A weight of 60 gives Kopia slightly lower I/O priority compared to most processes.
# Ensures Kopia doesn’t dominate disk I/O, reducing potential slowdowns for interactive or critical tasks (e.g., database queries, file accesses).
# Improves system responsiveness during backups by deprioritizing Kopia’s disk access.
# Backup speed may decrease significantly if there’s competition for disk resources.
# If Kopia is performing incremental backups (less disk-intensive), the impact may be minimal. However, for full backups, the lower priority could result in longer backup times.
IOWeight=40
# Prevents Kopia from consuming excessive memory, ensuring other applications have sufficient resources.
# Useful for systems with limited RAM or shared environments.
# If Kopia requires more memory (e.g., for handling large datasets or deduplication), this limit could cause performance degradation or even failures.
# Needs careful tuning based on the size and type of backups. For example:
# Small files or directories may work well with 2GB.
# Backing up large datasets or virtual machine images might require a higher memory limit.
MemoryLimit=8G
There are lots of nice shiny button to fiddle with nowadays, but I don’t see value in restricting cpu to something like 50%, if you other tasks use 40%, then there is 10% unused capacity you are not getting and backups will just take longer for no good reason. Setting a low prio (ie, higher nice value) means that it will use all the cpu it can get, but only after all other normal-prio processes get what they actually can use. Nothing goes to waste and backup finishes as fast as possible.
That’s the way to do it, if any.