 |
Anything special you know about the affected files? Some filesystems behave oddly, react on access time ... You can configure, what attributes are evaluated on accurate mode by the fileset include option "accurate", see http://doc.bareos.org/master/html/bareos-manual-main-reference.html#FileSetIncludeRessource If you are only interested in the file contents, setting accurate = 5 might be an option. |
|
|
Joerg, thanks for your reply. Affected files were pst(s), media files and binaries but no M$ office files (which are the most on this server / fileset). The File system is a ntfs on a Server 2016. I understand that it is a possible workaround to reduce the attribut set which decides about if a file has changed or not. I will give it a try. Please correct me if I am wrong but from my understanding of bareos the decision of backingup a file or not is done by the catalog entries. The entries in the catalog (see my database dump in the bug report) for the files which were all the time backed up were the same so there must be a bug in the decision process. |
|
|
It depends. Normal backup is based only on timestamps (backup all files that have been modified after the last backup). As you are using Always Incremental, I assume you are using accurate backup, where the backup decision is really based on the catalog data. My proposal can be seen as workaround, but it has been intended as a way to track down the problem. If it works with some settings, we can determine which attributes are treated wrong. Anyhow, there are also other possible reason: maybe there have been job runs in between, where the data have not been present (volume not mounted, ...). In this case the in between job has find out that foo.bar has not been available in between. As it had been available afterwards, it has been backuped again. |
|
|
Hi, i have same problem on two servers with Ubuntu 16.04 and BareOS 17.2.4. I have 2 milions files, which are backuped with incremental job again (ALL) after update Bareos from version 15.2 to 17.2. But this do only on BIG backups (2 and 3 milions files). I saw, that upgrade of database from version 2004 to new 2171 merge somehow tables File and Filename. Maybe here is some problem. In restored environment back to version 15.2 i have in table File 2 848 506 rows (size 1,2 GiB) and in table FileName 2 297 827 rows (337 MiB). After upgrade to 17.2 has table File 2GiB and incremental backup did backup all. In another environment in version 17.2 i have 14 600 000 rows (size 3,6GiB) - there i have problem. |
|
|
I have the same problem, I have a simple incremental backup job for a web server's almost static files (php, js, pictures). Every time all files are backup up. There is 1,7 millions files. The environment is: OS: Debian GNU/Linux 9.4 (stretch) Bareos: Version: 17.2.4 (21 Sep 2017) |
|
|
Same here. We have 99 Jobs on quite identical machines. All Linux. All ext3 or ext4. *Two* of these jobs fail and do a full backup each incremental "accurate" backup. Both have over 4 million files. All other 97 jobs have < 2 million files and work just fine! Disabling accurate fixes this. I have looked into the source code (filed/accurate.c) and found that the init for the MDB accurate database is called and then the return code (which could false) is *completely ignored*: jcr->file_list->init(jcr, nb); jcr->accurate = true; It should read: if (!jcr->file_list->init(jcr, nb)) { // emit error message, possibly informing director: dir->fsend(_("2991 Failed to allocate memory'); return false; } I don't know if this fixes this issue, it just points to a missing error handling... OS: Gentoo Linux, Ubuntu Linux, Debian Linux, ... Bareos: Various versions, most of them 17.2.4 and 17.2.7 |
|
|
Should be fixed in 21 |
- Anonymous
