Can anyone explain how the save group inactivity time-out works?

[eskolnik]

Can anyone explain how the save group inactivity time-out works? I am working with Legato support on this very question and they are going to talk with engineering on this matter.



Does the clock start as soon as the save group starts or maybe when the client is 1st contacted to generate its work list? When the timers stop when the 1st save stream is sent?



I am having lots of issues with a peculiar save group of about 47 client machines. The clients that fail are different every day. Since I increased the inactivity time-out value from 30 minutes to 90 minutes I only get failures for one client (not the same client each day).



I will summarize the information I get from here and Legato.




Ed Skolnik

 

[605]

From the Manual Pages ....

inactivity timeout (read/write, static, hidden)
The number of minutes that the savegrp command waits for any kind of activity on the server before concluding that a savegrp descendant is hung. This hidden attribute can be modified by a user. Once a hang is detected, savegrp prints a message indicating that a save is being aborted,
kills or aborts the backup, and moves on to its next task.

>>>>> Inactivity is defined as the last time a client has sent data to the server. <<<<<

If a client has a very large filesystem and an incremental is run, it is possible for savegrp to abort a save set that only appears to be hung. In these cases, the inactivity
timeout should be increased to accommodate the particular client.


I agree, this is a bit misleading but the timeout is actually tight to a client's save set, not to a group.

 

[jkalbus]

But it could give you another trouble, when using cluster clients...
Be sure to include the names of the physical machines in the aliases, else you run into a timeout without really being one.
Say you have &quot;machineA&quot; and &quot;machineB&quot; and a cluster package &quot;Application&quot;.
Backup is started for client &quot;Application&quot; which actually runs on &quot;machineA&quot;, so the replies are from &quot;machineA&quot; and not from &quot;Application&quot; -> timeout
If you have &quot;machineA&quot; and &quot;machineB&quot; defined as aliases there should be no problem.

Johanes

 

[eskolnik]

I am having a problem while save's are actully running on a client, could it be that it's taking 30 min. or longer to send packets arcoss the line......



Ed Skolnik

 

[605]

I was involved in timeout problems earlier. I would like to
know when this occurs. In my environment, the save set
seemed to be back up everything but then it was just &quot;waiting to be closed&quot;. As this never happened, the
timeout hit and caused the save set to fail.

Do you see the same behaviour?

 

[eskolnik]

That problem sounds like a firewall port issue on the service ports. We had that at one time, since no traffic goes on the service ports unless there are problems during the save, like open files.

So the firewall was closing the service ports before the save was done. Legato created a keep alive patch for that. The patch # is LGTpa43607_nooutput.

Ed

Ed Skolnik

 

[TDun]

If it is your incremental backups that are failing, then try a full backup. If that works, then it is taking too long (longer than your inactivity timeout) to traverse teh saveset, looking for the next file to back up in an incremental backup.

 

[eskolnik]

It's the full backups also. the backups save's are already running before the timeout happens.

Ed Skolnik

 

[605]

The best of my knoledge:
&quot;No output&quot; means that a save stream has never sent data
&quot;Timeout&quot; is caused by a started save set that does not
continue to send data.

Run &quot;savegrp -v&quot; and it will tell you exactly at which
stage the automatic backup fails.