conf.log_rotate_size - the maximum size of the log file
conf.log_rotate_count - the count of archived copies to keep

You start with just backup.log. When it grows to conf.log_rotate_size, it is moved to backup.0.log as soon as the backup is idle, and a new backup.log is started. When new .log grows to the threshold, the process is repeated, i.e. backup.0.log is moved to backup.1.log, backup.log - to backup.0.log and new backup.log is started. Conventionally, this is called "log rotation".

Defaults are 16 MB for size and 1 for rotation count (meaning that there'll be .log and .0.log only). Rotation count cannot be less than 1.

Additionally

As of Release 73 Revision 6 it is now possible to rotate the logs on schedule, e.g. every day or every week. This is controlled by the following two settings.ini entries -

conf.log_rotate_intvl - the rotation interval
conf.log_rotate_first - time of the first rotation

The interval is in "<unit>:<value>" format, whereby <unit> is

2 for microseconds,
3 for milliseconds,
4 for seconds,
5 for minutes,
6 for hours,
7 for days,
8 for weeks

On the first server I changed log size to 128 (very small) and rotation count to 30 on 4 jobs and it's working perfectly. The jobs were configured in version 69, but it's since been upgraded to version 70.

On my latest server I did the same thing (after closing the app and stopping the service) but the logs aren't rotating. I've confirmed that the settings.ini has maintained the changes for both jobs. I've even changed the rotation size to 1.

We're now running into a problem of our C drives filling up with Bvckup2 log files rather rapidly (causing OS issues, etc). I was able to narrow down the cause and it appears to be a bug related to conf.log_rotate_intvl.

When you manually change the conf.log_rotate_intvl (to "7:2", for instance), while Bvckup2 process is not running, these settings later get wiped when Bvckup2 process is running. As soon as you right click on the set (in Bvckup2), click adjust backup settings option, and then simply click the Update button...the "\engine\backup-0001\settings.ini\conf.log_rotate_intvl" value changes back to 0:0. Since we also do purposely have our "conf.log_rotate_size" value set to "0"...this combo then seems to result in a single log file growing out of control (200GB on one machine this week).

If you can please squeeze a fix for this into your next release, that would be greatly appreciated. This one keeps coming back to bite us more and more now (3 OS drives filled to capacity this week alone). Until then, perhaps I'll set our default "conf.log_rotate_size" to "1024000000" and will set our "conf.log_rotate_count" value to "4". That should limit our max log file usage to 4GB total, if I'm thinking correctly.

Scratch that last workaround option to modify the "conf.log_rotate_size" to "1024000000"...it also wipes that value out (to "0") when we click the Update button. So our only relief, until this issue is addressed code side, is for me to tell our guys to manually modify these two values (conf.log_rotate_intvl and conf.log_rotate_size) each and every time they click Update button on a set. That's going to be difficult to enforce or remember to do, I imagine...so, the sooner this can get fixed the more appreciative we will be.

I can confirm this is a bug. We will get a maintenance release out by the end of today.

---

Internally this is due to how the engine and the UI communicate with each other. When you "touch" a backup configuration in the UI, the UI packages all settings into a binary blob and sends it to the engine. The engine then unpacks it and uses to replace its own copy job's configuration.

Now, the issue is that log_rotate_intvl and log_rotate_first weren't included into this binary blob, so when the engine unpacked what the UI sent, these two fields remained at their defaults and that wiped any custom values that might've been read from the INI earlier.