Understanding the .conf file

[BackupBytesTim]

So I got what appears to be conflicting information from support and since I've now not gotten any response for over 24 hours I thought I'd ask here for clarification.

Support case #06041477

Support says there is a "Resume Backup" feature, which is enabled by "default", but not allowed in the specific backup job.

User Guide refers the Resume Backup feature which is enabled by default and flushes its cache by default after 5 minutes. However, according to log files this feature is not allowed on your backup job, which could lead to more data being transferred if network issues occur. For more information, please refer User Guide:
https://helpcenter.veeam.com/docs/agent ... tml?ver=20

Job.log file snip:
[04.04.2023 00:30:14.627] <0x285446> lpbcore | Resume backup enabled? [true].
[04.04.2023 00:30:14.627] <0x285446> lpbcore | Resume backup allowed? [false].

I am completely certain no one on our side disabled the feature, and since apparently it requires manually modifying a .conf file, I can say the customer wouldn't have either, especially when I found out the file apparently doesn't exist, so it couldn't have been modified even if someone wanted to.

When I asked how to enable the Resume Backup feature the same support person said that a .conf file needs to be modified manually and the service restarted. The first step of which I have no way to do remotely with Veeam, which means it may not be done for a while if at all. However, the same support person also told me that with the file missing Veeam will use the "default" configuration.

The Resume Backup feature is enabled on the /Library/Application Support/Veeam/veeam.conf file

However, according to uploaded log files, this file does not exist on your system. Hence, default configuration applies:
[02.05.2023 11:09:56.459] <0x559d27> lpbcommon| File [/Library/Application Support/Veeam/veeam.conf] does not exist, default settings will used.

To generate a default configuration file manually run /Applications/Veeam/Veeam Agent for Mac.app/Contents/MacOS/veeamsupporttool confFile .

To enable the Resume Backup feature, the following parameter should be added to the file, make sure only an entry exists:
filevelel.resumeBackup = true

To customize the default flush interval, the following parameter should also be added and tuned to the file, make sure only an entry exists:
filelevel.flushintervalMinutes = 5

Save changes to file and restart service by issuing the following commands on a terminal:
sudo launchctl unload /Library/LaunchDaemons/com.veeam.veeamservice.plist
sudo launchctl load -w /Library/LaunchDaemons/com.veeam.veeamservice.plist

Since this is a supposedly "default" setting, shouldn't Veeam be doing it since the file doesn't exist? There seems to be some contradicting information there where the desired functionality is "enabled by default" and also "default settings are used because the file doesn't exist" but the feature still needs to be enabled manually by creating and then editing the file.

Also, if the file doesn't exist to explicitly disable the setting, what might be disabling it, as apparently it's "not allowed"?

Less important question, but I'm curious if Veeam would have created that file automatically at some point or if it's expected to be created manually all the time? Trying to determine if something deleted the file or if it simply never existed, and if it never existed, if that's expected behavior or an unexpected bug that needs to be fixed.

[PTide]

Hi,

As I can see from your log snippet the feature is enabled:

Code: Select all

Job.log file snip:
[04.04.2023 00:30:14.627] <0x285446> lpbcore | Resume backup enabled? [true].

However, the backup job resumes only on retries during the same backup session. Please describe what was going on? Was the same job session trying to finish three (the default value) times but failed to resume each time, or you saw something else?

Thanks!

[BackupBytesTim]

That is my understanding from what support told me, that a connection problem occurred and so Veeam was attempting to retry the backup.
This actually came from attempting to troubleshoot rather backwards file sizing where the file storing data on the repository is significantly larger than the amount of data that Veeam says was backed up, also an issue where the agent is downloading a massive amount of data before it performs the backup each time, "massive" being like 20 GB, though it fluctuates, but is always larger than it apparently should be.

I don't understand how a connection problem could result in that sort of enormous data transfer from our server to the customer's computer, or how it results in the server storing more data than the computer sent us, but that seems to be what support is attempting to resolve. However I can't come up with any scenario in my head for how a connection problem results in those problems appearing. I could sort of understand that large data downloads if it's downloading the same data repeatedly, but to my knowledge Veeam only retries 3 times, or maybe retries 2 times for a total of 3 attempts, wouldn't mind clarification on that if you can, which should under no circumstances result in downloading what would seem to be thousands of times the amount of data it should if all it needs to do is check file modified dates on the server. Also I have no thoughts at all about how a connection problem results in more data stored than the computer sent, would seem a connection problem could only go the other way on that, sending data repeatedly should meanit would send a whole lot more than is actually stored because it tried to send the same thing repeatedly.

Aside from the above mentioned support case, there's more information here: post487394.html

[PTide]

Thank you for your reply. This all is very weird, indeed. I will make sure the case does not unintentionally get swept aside.

Cheers!

[BackupBytesTim]

Thank you, can you confirm if support will be able to package that .conf file creation into a patch I can upload via the VSPC?

[PTide]

Technically it is already possible, but I think it is not required for your use-case.

The thing is that by default VAM does not have that file and it's by design. If the file is missing VAM is supposed to go with default settings.
Default settings presume that 'resume backup' is enabled.

That is, the file is not present, the feature is enabled.

I asked to escalate your case.

Thank you

[BackupBytesTim]

Thank you, after being escalated it was made clear that what you described is the expected behavior and that is what is actually happening, seems the original support rep didn't look very far into the logs as to determine that there was not actually anything blocking the "Resume Backup" feature as originally stated.