topic Re: Backup fails exactly at 13GB and particular mount point in Operating System - OpenVMS

Backup fails exactly at 13GB and particular mount point

NathanBabu — Fri, 06 Jan 2012 10:50:58 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

Sebastian.Koehler — Fri, 06 Jan 2012 11:06:06 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

NathanBabu — Sun, 08 Jan 2012 06:06:50 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

Sebastian.Koehler — Sun, 08 Jan 2012 11:11:49 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

NathanBabu — Sun, 08 Jan 2012 12:42:53 GMT

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.

Please advise further.

Regards,

Nathan

Re: Backup fails exactly at 13GB and particular mount point

NathanBabu — Mon, 09 Jan 2012 04:14:32 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

Sebastian.Koehler — Mon, 09 Jan 2012 21:59:40 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

NathanBabu — Wed, 11 Jan 2012 12:32:17 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

Sebastian.Koehler — Wed, 11 Jan 2012 13:15:17 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

Hein van den Heuvel — Thu, 12 Jan 2012 13:18:51 GMT

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

Re: Backup fails exactly at 13GB and particular mount point

GuentherF — Fri, 13 Jan 2012 17:38:37 GMT

Hm, Data Protector...that's been a while ago.

Definitely you have to look at debug.log at the OpenVMS system to get more information.

"/$dir$DUA5372" - That device/file spec looks questionable. Would have expected something like "/$1$DUA5372".

You also have to scan the accounting file on the OpenVMS system for an entry for the backup disk agent (BDA) process exiting. Maybe the exit status gives a clue.

/Guenther

Re: Backup fails exactly at 13GB and particular mount point

NathanBabu — Mon, 16 Jan 2012 04:32:53 GMT

Hi Hein,

Yes, ofcourse there are very large filesystem under it. Now i split them into more pieces, and got the succesfull backup. Now i'm in the process of convincing the customer to accept this solution.

Hope he agree with my view.

Regards,

Nathan

Re: Backup fails exactly at 13GB and particular mount point

Ssram — Sat, 28 Mar 2015 07:56:49 GMT

We do have same issue on one of full Backup set and session is haning at 22% abot 10-15 hours later it resongin and writing the backup to tape.

Client: HPUX 11iV3

DB agent version: 06.10