Bareos Bug Tracker - bareos-core
View Issue Details
0000907bareos-core[All Projects] file daemonpublic2018-02-09 10:592018-11-20 13:25
mbr 
 
normalmajorhave not tried
feedbackopen 
LinuxWindows2016
17.2.4 
 
yes
yes
0000907: Incremental Job backups same files
Director is running on CentOS 7, FD on Windows Server 2016.
Jobtype: always incremental;
Bug: Some files (~ 180) were copied on every job.

Example:

Jobs:
 22401 Incr 2,187 105.1 G OK 04-Feb-18 01:24 FS01-AI
 22421 Incr 1,143 103.8 G OK 05-Feb-18 08:35 FS01-AI
 22495 Incr 2,515 105.3 G OK 09-Feb-18 07:13 FS01-AI


In the database you can see that the files have not changed between backups:

bareos=# select * from file where pathid='5305263' and name='foo.bar' and jobid=22495;
  fileid | fileindex | jobid | pathid | deltaseq | markid | fhinfo | fhnode | lstat | md5 | name
-----------+-----------+-------+---------+----------+--------+--------+--------+----------------------------------------------------------+------------------------+--------------------
 252600154 | 2292 | 22495 | 5305263 | 0 | 0 | 0 | 0 | A A IH/ A A A BAAAYg ePLa A A BOh02e BN3PJg BZFeCr A A f | VsVr09AEXA85Ywpk6aW+8w | foo.bar
 252163936 | 1010 | 22421 | 5305263 | 0 | 0 | 0 | 0 | A A IH/ A A A BAAAYg ePLa A A BOh02e BN3PJg BZFeCr A A f | VsVr09AEXA85Ywpk6aW+8w | foo.bar
 252090699 | 1934 | 22401 | 5305263 | 0 | 0 | 0 | 0 | A A IH/ A A A BAAAYg ePLa A A BOh02e BN3PJg BZFeCr A A f | VsVr09AEXA85Ywpk6aW+8w | foo.bar
No tags attached.
Issue History
2018-02-09 10:59mbrNew Issue
2018-02-09 19:58joergsNote Added: 0002903
2018-02-09 19:58joergsStatusnew => feedback
2018-02-12 14:38mbrNote Added: 0002906
2018-02-12 14:38mbrStatusfeedback => new
2018-02-12 16:39joergsNote Added: 0002907
2018-02-12 16:39joergsStatusnew => feedback
2018-02-12 16:40joergsbareos-master: impact => yes
2018-02-12 16:40joergsbareos-17.2: impact => yes
2018-02-12 16:40joergsCategorydirector => file daemon
2018-02-12 16:40joergsOSCentOS => Windows
2018-02-12 16:40joergsOS Version7 => 2016
2018-03-05 16:17romorNote Added: 0002938
2018-07-05 23:25beckzgNote Added: 0003062
2018-11-20 13:25kilroyNote Added: 0003152

Notes
(0002903)
joergs   
2018-02-09 19:58   
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.
(0002906)
mbr   
2018-02-12 14:38   
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.
(0002907)
joergs   
2018-02-12 16:39   

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.
(0002938)
romor   
2018-03-05 16:17   
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.
(0003062)
beckzg   
2018-07-05 23:25   
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)
(0003152)
kilroy   
2018-11-20 13:25   
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