 |
Well, this should not happen. Can you please verify, that your fileset changes are properly detected? Use the following bconsole command to get all known versions of the fileset: .sql query="select * from fileset where fileset='<YOURFILESETNAME>'" |
|
|
I found the fileset in question. It was updated on 9/21/2019 to include another path and OneFS set to no. The added path was in the excluded section, which might explain why there was no full backup? One other note: Despite the database showing the additional path in the exclude section in the most recent (9/21/2019) row of FileSet for that fileset, the configuration file for the fileset now has no reference to the excluded path. I'm not sure that this is harmful, but I thought I should mention it. |
|
|
I'm not sure, if I understood this correctly. The fileset entry is written to the database, when a job did run which uses the fileset. Has there been a job using the new fileset? Please also compare it to the output of the bconsole command "show fileset='<YOURFILESETNAME>", just in case, the new configuration is not loaded for any reason. |
|
|
Forget about my last question. I verified that the behavior you describe still exists in the current Bareos master branch. A change to the file list do upgrade the backup level to Full, a change in the options does not upgrade to a Full backup. |
|
|
[I just saw your last post, but I'll include this anyway, for reference. You may delete this note if desired.] The last row for the fileset in question looks like: | 30 | SystemConfig | B9/TG7tfvx+q7++Yw/th+C | 2019-09-21 03:00:01 | FileSet { Name = "SystemConfig" Include { Options { OneFS = No Compression = GZIP9 } File = "/etc" File = "/root" File = "/var" } Exclude { File = "/var/tmp" File = "/var/run" File = "/var/lock" File = "/var/cache" File = "/root/tmp" File = "/var/lib/nothing" } } This resource record is part of 5 backups every night and has been since before this update was made to the config file: FileSet { Name = "SystemConfig" Include { Options { One FS = no Compression = GZIP9 } File = "/etc" File = "/root" File = "/var" } Exclude { File = "/var/tmp" File = "/var/run" File = "/var/lock" File = "/var/cache" File = "/root/tmp" } } The timestamp on this file is: -rw-rw-r-- 1 bareos bareos 302 Sep 21 03:16 SystemConfig.conf Also, I DO backup the /etc/bareos tree every night. I only keep about a month's worth of backups. Dates and times are sync'd to an ntp server. |
|
|
So is this the intended behavior by design and not a bug? Or is it a defect after all? |
|
|
I'm now realizing that this issue/bug might be mis-labeled. I think the real issue here is that the Exclude { } was modified. As you can see, the database thinks the files to be excluded would also mean /var/lib/nothing is to be excluded. But I removed that one exclusion, but the database continues to think /var/lib/nothing should be excluded. (In this case, no problem arises because obviously this was only a test case.) Once the newer definition of the fileset was used once (and it has been, many times since that change) I would expect the database to now have an updated definition as well, but it doesn't. Excluded files probably need to be considered in backup calculations for the same reason that the included ones are. Here, I gave an example of where possibly new files might be added to subsequent backups, but the database might ignore the change and continue to exclude files and directories under /var/lib/nothing. I haven't tested this, but it does seem inconsistent at very least. As to the change to OneFS, that may have been the change I made, probably earlier, that precipitated filing the current issue. Being this was months ago, I have forgotten. Sorry for any confusion. |
|
|
I discussed this issue with the Bareos Developer team. The conclusion is, that it works a designed. However, most people will admit, that a redesign might be a good idea. In my tests I came to the conclusion, that changes to the "File" directives (in Include as well as in Exclude) will upgrade the job to Full, while all other options to not result in an upgrade. I tried to clarify this fact in a change to the documentation, see https://github.com/bareos/bareos/pull/341 There have long been a discussion, if an upgrade to Accurate wouldn't be preferable to an Upgrade to Full. I created to Feature Request for this, together with hints about the current limitation, see https://bugs.bareos.org/view.php?id=1143 With this, I'm closing the bug report and hope future work in https://bugs.bareos.org/view.php?id=1143 will improve that behavior. |
- Anonymous
