problem with incremental backups

urgido

• December 12, 2016 17:09

After change from compress backup to incremental backup but it's failed to begin execution. I had set it to run everyday sunday and keep only one copy (latest) Here is my log:
cpuwatch (Sun Dec 11 01:26:24 2016): System load is currently 3.50, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:26:29 2016): System load is currently 3.54; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:27:19 2016): System load is currently 3.49, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:27:24 2016): System load is currently 3.85; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:27:56 2016): System load is currently 3.06, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:28:09 2016): System load is currently 3.91; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:28:40 2016): System load is currently 3.34, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:29:04 2016): System load is currently 3.75; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:29:54 2016): System load is currently 3.32, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:30:04 2016): System load is currently 3.98; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:35:19 2016): System load is currently 3.38, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:36:39 2016): System load is currently 3.53; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:37:59 2016): System load is currently 3.32, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:38:54 2016): System load is currently 3.69; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:39:26 2016): System load is currently 2.88, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:40:05 2016): System load is currently 3.75; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:46:24 2016): System load is currently 3.47, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:46:44 2016): System load is currently 3.97; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:47:16 2016): System load is currently 3.40, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:47:20 2016): System load is currently 3.53; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:47:51 2016): System load is currently 3.15, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:48:15 2016): System load is currently 3.84; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:49:05 2016): System load is currently 3.40, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:49:15 2016): System load is currently 3.51; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:49:47 2016): System load is currently 2.69, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:50:14 2016): System load is currently 4.21; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:57:30 2016): System load is currently 3.43, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:57:55 2016): System load is currently 3.53; waiting for it to go down to 3.50 to continue "" cpuwatch (Sun Dec 11 01:58:26 2016): System load is currently 3.35, which is below the threshold of 3.50. Continuing "" cpuwatch (Sun Dec 11 01:58:30 2016): System load is currently 7.97; waiting for it to go down to 3.50 to continue "" rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(546) [sender=3.0.6] rsync: writefd_unbuffered failed to write 78 bytes to socket [generator]: Broken pipe (32) [cpbackup] Final state is Backup::Success (TERM)
I been looking into weekly's directory for recently backups and there is nothing new. This is the first time that I am using incremental backups. How I can solve this?

• 

  cPanelMichael

  • December 13, 2016 18:43

  Hello, You can alter the load average at which backups are suspended via the "Extra CPUs for server load" option under the "Stats and Logs" tab in "WHM >> Tweak Settings". Per it's description: This setting allows you to specify a value to add to the number of physical CPUs in your server. The sum of these two numbers becomes the value at which the cpuwatch, cpanellogd, backups, and CPU statistics daemons consider the system to be in a critical load state.
  Try increasing the value if you'd like backups to generate at higher loads. Thank you.

  0
• 

  urgido

  • December 14, 2016 08:16

  Ok, done. Thanks!

  0

Please sign in to leave a comment.