Unsolved
This post is more than 5 years old
20 Posts
0
10559
Avamar - Total processed bytes inconsistent with original data size
Every so often I see a line like this in a log when investigating an Avamar backup exception:
00:25:13 avtar Error <16507>: Path "/var/log/resources": Total processed bytes 724 is inconsistent with original data size 731
Does this error indicate that the file size changed between the start of the backup and the time the agent attempted to back up that specific file? I'm not exactly understanding how/why a change in file size impacts the agent's ability to back up the file.
dileep451
82 Posts
0
May 7th, 2015 23:00
Hi All,
I understand its problem with that particular file which is not consistent while backup. I could see at least 20 clients daily facing this issue.(Backup complete with exceptions,not the same server daily). Is there a way where we can avoid those?
Thank in advance.
Regards,
DIleep M
save_123
2 Posts
1
May 8th, 2015 00:00
Hi DIleep,
In my opinion there is no other way then to investigate logs from backups. And then apply resolution mentioned:
Soooo you have to check if files from the clients are of specific type (exclusion using wildcard). Or maybe some directories can be thrown out from the backup? Unfortunately it all depends on the situation you have.
Sometimes rescheduling backup to earlier/later hours (so no user activity will be undergoing) can fix the issue.
Regards,
Kris
dileep451
82 Posts
0
July 15th, 2015 03:00
End user is not happy if I say to exclude, as those are important files to him. If avamar not able to backup these kind of files then is this a bug? We use avamar 7.1.0.370.
ionthegeek
2K Posts
1
July 15th, 2015 06:00
Are Windows clients or Linux / UNIX clients? The cause of these messages is different depending on OS.
No, this is not a bug.
Architecturally, there are a limited number of ways to deal with files changing between the time a program runs "stat" to look up the file metadata and the file is opened for reading.
As an example, Windows deals with this by locking files when they are opened for writing, meaning requests to read the file will fail outright. The reason VSS exists is to provide a mechanism by which backup and other applications can retrieve a copy of these locked files. In the Windows 2000 days (before VSS), open files would just not be backed up. If the VSS snapshot is deleted due to lack of space for the shadow copies of the files, this message will result.
Linux makes locking optional which -- in most cases -- means the files can be backed up but all software (not just Avamar) is vulnerable to this race condition where the file content changes between the time it is queried and the time it is read.
dileep451
82 Posts
0
July 15th, 2015 19:00
Thank you Ian. This is for Linux servers for now.
AshishShankar
12 Posts
0
March 22nd, 2016 01:00
Hi Ian,
I m getting the same error that you mentioned in the case of Linux machine. Should reboot fix the issue or should I delete f cache & p cache and try a new backup?
AshishShankar
12 Posts
0
March 23rd, 2016 05:00
Take a reboot.
AshishShankar
12 Posts
0
March 23rd, 2016 05:00
Reboot the machine. Problem will be fixed.