Backup fails exactly at 13GB and particular mount point

[NathanBabu]

Hi All,

I have a problem here like, Backup fails for a clustered mount point , when other mount points good. 

And moreover it stops being backed up exactly at 13555597KB and I get error as 

[Major] From: BSM@client.domain.net "Backup_Spec_Incr_30" Time: 1/6/2012 1:45:00 PM
[61:1002] The VBDA named "/$dir$DUA5372" on host vvcd.domain.net
reached its inactivity timeout of 72000 seconds.

The agent on host will be shutdown.

I have tested this spec, and for the last 5 sessions it exactly stops at 13555597KB level and for the particular mount point.

Don't know where to start the investigation... Clueless about the issue. Please help... 

Thanks in advance.

Regards,

Nathan

[Sebastian.Koehler]

Increase the VBDA timeout in the global configuration file. If it continues to fail, the source or the communication is most likely the issue.

Is that client a OpenVMS system? What version is the CM and the client running?

Regards,
Sebastian

[NathanBabu]

Hi Sebastian,

Thanks for your prompt reply, and sorry for the late response.

I hope VBDA timeout has been at it's maximum level.

Yes, this is the VMS client system and version OpenVMS 8.3

CM and client in 6.10 Version.

I see last day backup also exactly failed at 13575477KB

Backup started at  Time: 1/6/2012 1:45:30 PM

and the timeout error occured at Time: 1/7/2012 1:50:27 PM

[Sebastian.Koehler]

If you use SHADOW on that specific disk, the backup specification requires the "Do not preserve access time attribute" option defined. If this is not the case, does the BACKUP utility succeed on this disk? Is it ODS-2 or 5?

Regards,

Sebastian

[NathanBabu]

Hi Sebastian,

Just now i check the backup spec for your listed options. And i see "Use Shadow Copy" and  "Do not preserve access time attributes" didn't checked. 

Moreover, from morning onwards, i split the particular directory into sevaral bakkup sets. I see first two sets completed in few minutes. Now backup hang on a particular set of directories, and i see still the Disk agent reading the directories bytes by bytes and still counting, netither fail nor successful. 

Please advise further.

Regards,

Nathan

[NathanBabu]

Hi All,

Futher check i did from yesterday, The backup spec is now started writing into the drive after getting File System statistics of 14.34GB of data in 21.30 hours.  I belive this is not the normal time to read the data of 14.34GB... I hope 14.34 GB of data is very small in size and backup could be completed in 1 hours of time in any such situation. But here it goes around more than a day of time atleast to start.

Here is the File System statistics from the backup...

Filesystem Statistics:

Directories ........ 6889
Regular files ...... 512841
Symbolic links ..... 0
SYSV FIFOs ......... 0
BSD sockets ........ 0
Block Devices ...... 0
Character Devices .. 0
Unknown Objects .... 0
------------------------------
Objects Total ...... 519730
Total Size ......... 14.34 GB

Please someone advise me, whether it's got issue with DP or from the client side...

Thanks in advance... 

Regards,

Nathan

[Sebastian.Koehler]

Moreover, from morning onwards, i split the particular directory into sevaral bakkup sets. I see first two sets completed in few minutes. Now backup hang on a particular set of directories, and i see still the Disk agent reading the directories bytes by bytes and still counting, netither fail nor successful.
Just now i check the backup spec for your listed options. And i see "Use Shadow Copy" and "Do not preserve access time attributes" didn't checked.

This is not what I mean. On your OpenVMS host, is that disk in question in a SHADOW SET? If yes, the "Do not preserve access time attributes" must be checked to be successfull.

If the disk agent struggles on a specific piece of the file system your should run ANALYZE/DISK or at least try to use BACKUP to create a backup set using OpenVMS tools. Just to verify if the filesystem is fine. If both are working, log a support call send send them debugs 1-500 of the filesystem backup. Have you already checked the debug.log in OMNI$ROOT:[TMP]?

Regards,
Sebastian

[NathanBabu]

Hi Sebastian,

Sorry again for the late reply.

I have already ask the Client support team to check the disk issues. and they are very clear, and they don't find any issues with the client disk. Sorry, i do not see any errors related with this issue in debug.log. And I'm not expert in looking at the debug.log. Please advise.

Thanks in advance,

Nathan

[Sebastian.Koehler]

In that case file a support case with HP and provide them with debug 1-500 output for this particular client system. For that, just run manager -debug 1-500 DEBUG_VMS_Backup.txt on a windows client and start the backup manually afterwards. Make the backup as small as possible but make sure the issue occours during debug run. Collect the debugs on the client and send them to the case. Also include the backup specification used and the session output. Let us know if the find the issue.

Regards,
Sebastian

[Hein van den Heuvel · Accepted solution]

Nathan,

You fail to mention any product name/version.

I suspect it is ABC backup from the folks at Storserver?

If so, be sure to reach out to James Amend, but he was working on this in Novemner 2011 for an other customer 

They have a n-square algoritme in the checking for Alias entries.

This becomes apparent with large directories... roughly over 1,000 blocks.

Going form 100 blocks to 1000 does not take 10 times longer, but 100 times longer, and will take over an hour.

Checking for aliases allows them to avoid redundant file saves (notably apparent on SYSTEM DISKS) and may save hours on restore, but it may cost hours (days!) on backup for disks with large directories.

So are there (very) large directories in play?

If you can convince the customer to break up those directories then that will be a win for everything involved.

If you can not break it up try using /ALIAS=IGNORE.

Seems safe, as there are no links reported in the later output to this topic.

Good luck,

Hein