VA for AIX v2 : Error when backing up larger files

[erwanns]

Hello,

I've installed VA for AIX v2 for a customer and it's a real improvement compared to v1 previously used ly the same customer : easier, faster.
Unfortunately, one of the jobs I've configured ends up with warnings because most of the files cannot be backed up. Those files are much larger (over 10 GBs) than the files that are backed up by the other jobs ont the same machine.
I was wondering if some of you had encourtered the same issue.

The Job.log does not give any detailed information about the root cause of the failure, but the Agent.Source.log seems more interesting, but I'm unable ton understand what's failing. See log extract below :

Code: Select all

[12.10.2020 14:44:52.676] <  4118> ext4   | Opening filesystem. Device size: [3221225472]. ok.
[12.10.2020 14:44:52.676] <  4118> fb     | Initializing file backup sync operation context.
[12.10.2020 14:44:52.710] <  4118> fb     | Items count: [64]. Total data size: [456849606656]. Changed data size: [456839153664].
[12.10.2020 14:44:52.710] <  4118> fb     | Starting sync operation.
[12.10.2020 14:44:52.829] <  4118> fb     | ERR |Failed to flush directory [/backup/rman/BB01/backupset/2020_10_12].
[12.10.2020 14:44:52.829] <  4118> fb     | >>  |Invalid bitmap access. Sub-bitmap number: [24]. Count of bitmaps: [24].
[12.10.2020 14:44:52.829] <  4118> fb     | >>  |--tr:Failed to allocate [1] data blocks.
[12.10.2020 14:44:52.829] <  4118> fb     | >>  |--tr:Failed to change file coverage. Size: [4096].
[12.10.2020 14:44:52.829] <  4118> fb     | >>  |--tr:Failed to set file size. New size: [4096].
[12.10.2020 14:44:52.829] <  4118> fb     | >>  |--tr:Failed to write file data. Offset: [0]. Buffer: [4096]. Inode: [36].
[12.10.2020 14:44:52.829] <  4118> fb     | >>  |--tr:Failed to flush directory contents. Directory inode: [36].
[12.10.2020 14:44:52.829] <  4118> fb     | >>  |An exception was thrown from thread [4118].
[12.10.2020 14:44:52.845] <  4118> ext4   | ERR |Failed to dispose ext4lib::CDirectory.
[12.10.2020 14:44:52.845] <  4118> ext4   | >>  |Invalid bitmap access. Sub-bitmap number: [24]. Count of bitmaps: [24].
[12.10.2020 14:44:52.845] <  4118> ext4   | >>  |--tr:Failed to change file coverage. Size: [4096].
[12.10.2020 14:44:52.845] <  4118> ext4   | >>  |--tr:Failed to set file size. New size: [4096].
[12.10.2020 14:44:52.845] <  4118> ext4   | >>  |--tr:Failed to write file data. Offset: [0]. Buffer: [4096]. Inode: [36].
[12.10.2020 14:44:52.845] <  4118> ext4   | >>  |--tr:Failed to flush directory contents. Directory inode: [36].
[12.10.2020 14:44:52.845] <  4118> ext4   | >>  |An exception was thrown from thread [4118].
[12.10.2020 14:44:52.846] <  4118> fb     | workload: source[0 0 80] target[13 7 0]
[12.10.2020 14:44:52.862] <  4118> fb     | ERR |Failed to sync item [/backup/rman/DB01/autobackup/2020_10_12/o1_mf_s_1053590453_hr8nw62r_.bkp]
[12.10.2020 14:44:52.862] <  4118> fb     | >>  |Invalid bitmap access. Sub-bitmap number: [24]. Count of bitmaps: [24].
[12.10.2020 14:44:52.862] <  4118> fb     | >>  |--tr:Failed to change file coverage. Size: [10452992].
[12.10.2020 14:44:52.862] <  4118> fb     | >>  |--tr:Failed to set file size. New size: [10452992].
[12.10.2020 14:44:52.862] <  4118> fb     | >>  |An exception was thrown from thread [4118].

I've opened a support case : Case #04438188

Thanks.

[PTide]

Hi,

QC department has joined to the investigation today

Thanks!

[erwanns]

Hi,

We are exchanging with support on this issue that does not seem easy to solve as it appears to not relate to large files but to some environmental specifis. Work in progress. I'll keep this thread updated.

Thanks

[RaymondCox]

Hello,

Did you ever get this resolved? I have a client that is experiencing an identical error.

[Natalia Lupacheva]

Hi Raymond,

As far as I see from the mentioned case, you need to open your Support ticket to make sure it's the same issue and get the fix.
Please post the Support case ID here so we could check your issue.

Thanks!

[RaymondCox]

Hello,
The case number I opened is 04673202, I uploaded the logs as well.

Thank you

[erwanns]

Hello,

Did you ever get this resolved? I have a client that is experiencing an identical error.

Hello,
As far as I know, the problem has been solved after applying a patched version provided by support team.