In den letzten Monaten wunderte ich mich über deutlich zu große Incremental-Backups in Bacula bzw. Bareos. Ich führte einen Restore des Incremental-Backups durch und stellte fest: Da wurde "altes Zeugs" erneut gesichert.
Auf backupzentral fand ich einen Hinweis darauf, dass Virenscanner Metadaten der Dateien verändern und deswegen diese Dateien erneut im Backup landen können.
Und tatsächlich, mit dem "stat"-Befehl konnte man sehen, dass das "Change"-Datum verändert worden war.
18941# stat /var/www/xxxxx/htdocs/administrator/components/com_banners/views/clients/index.html
File: `/var/www/xxxxx/htdocs/administrator/components/com_banners/views/clients/index.html'
Size: 31 Blocks: 8 IO Block: 4096 regular file
Device: 904h/2308d Inode: 25301086 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1064/xxxxx) Gid: ( 1064/xxxxx)
Access: 2014-07-25 08:23:16.000000000 +0200
Modify: 2014-07-25 08:23:16.000000000 +0200
Change: 2016-04-10 09:35:48.997754174 +0200
Kürzlich habe ich den Virenscanner "Sophos Antivirus für Linux" ausprobiert und ein Scan der obigen Datei veränderte tatsächlich das "Change"-Datum.
Folgende Abhilfen sind möglich:
- Benutzen des Parameters " --no-reset-atime" an der command-line von savscan (Sophos)
Damit lässt der Sophos Virenscanner die "Change"-Time in Ruhe, aucj wenn der Parameter eigentlich auf die "Access"-Time hinweist. - Verwenden der "Accurate"-Option in Bacula
Damit kann man Bacula anweisen, bestimmte Parameter der Dateien zu ignorieren, in diesem Fall auch die "Change"-Time