cancel
Showing results for 
Search instead for 
Did you mean: 

Symantec DLO 7.5 .log directories

smithj
Level 6

Hi

We are having issues where the .logs directories of certain users are filling up with millions of logs.

Even though the console has been set up to purge these directories for logs older than 14 days, some .logs

folders keep log files from 6-12 months ago.

Is there any known issues that may cause millions of logs files to be generated by certain users?

Also, is it possible to store log files in a different location to the DLO Storage locations?

Thanks for any help

Jimmy

1 ACCEPTED SOLUTION

Accepted Solutions

smithj
Level 6

Hi Enzo JE

After many months chasing Symantec to try and get this resolved, we ended up downgrading all our clients to 7.0. Symantec did try to analyse data we collected, but we spent so much time trying to fix it that we decided to downgrade and everything is fine now. Apparently it is something to do with Dedupe, even though we had it turned off, it still caused problems. Hopefully 8.0 may resolve some of these issues. For now we're sticking with 7.0.

Sorry, I couldn't supply you with a resolution. Maybe if you contact Symantec directly they may have found something to fix the problem

Jimmy

View solution in original post

15 REPLIES 15

VJware
Level 6
Employee Accredited Certified

Under log file maintenance, what is the second option set to (the one about combined size) ? Verify the profile setting as well as the global setting. And what's the approx size of each .log ?

Not aware of any known issue as such, however you should be able to delete the older files manually and observe for any reoccurence.

I checked on my test system and could not find a way to change the .logs location. Looks like it is hardcoded at each user share under NUDF.

smithj
Level 6

Thanks for the reply VJware

The combined size option is set to 1MB. The approx size of each log file was less than 1KB.

What do you mean by Verify the profile and global setting?

Thanks

Jimmy

VJware
Level 6
Employee Accredited Certified

By profile settings, i mean the log file maintenance options set in the profile & by global settings, i mean the settings set from tools - options..

smithj
Level 6

Hi VJware

In Global settings under Log File maintenance I have the following:

Keep log files for a minimum of (days)   - 14

After minimum number of days, delete oldest log files when combined size exceeds (MB)  - 1

In Global settings under Logging Options:

Select the type of messages to be logged. By default message types not listed below will always be logged.

Off - Log groom messages

Off - Log information messages for backup

On - Log warning messages

For profile settings, the 3 users that are having this problem are on different profiles, one user is on the Default profile (5GB), the two other users are on 10GB and 15GB. The settings on the 10GB and 15GB are the same as the Global Settings, but the 5GB profile is shown below:

In Profile settings under Log File maintenance I have the following:

Keep log files for a minimum of (days) - 14

After minimum number of days, delete oldest log files when combined size exceeds (MB) - 1

In Profile settings under Logging Options:

Select the type of messages to be logged. By default message types not listed below will always be logged.

On - Log groom messages

On - Log information messages for backup

On - Log warning messages

Any further assistance is greatly appreciated

Thanks

Jimmy

VJware
Level 6
Employee Accredited Certified

For the time being, I would recommend to manually clear the older .logs. Restart the Desktop Agent on the client systems & observe if log grooming works fine or not. If not, would recommend to log a formal support case for us to review further.

smithj
Level 6

Hi VJware

Thanks for the reply, can you answer the below questions in relation to this problem?

Will the clients continue to backup the data even if the DLO server is disabled or offline?

Also, would you know why the Last Backup is showing up as 12:00:00 AM with no date on these users?

Thanks

Jimmy

VJware
Level 6
Employee Accredited Certified

If the DLO server is not reachable (offline or disconnected), clients will continue to backup to the DUDF. Once its able to connect to the DLO server, it would transfer the data from the DUDF to the NUDF.

Last backup correlates to the actual data transfer to the NUDF for that user.

smithj
Level 6

Thanks VJware

So, there will be a copy of all the backup data on the users system under the Symantec DLO directory? If the server is not available, will this also create additional log files locally on the users system until it is available, will the users system fill up with log files?

Would you know why these users have 12:00:00AM as last backup. Other users have the format 9/4/2013 14:35:22PM as their last backup

Thanks again for all the help

Jimmy 

VJware
Level 6
Employee Accredited Certified

Yup, there will be a local backup present. (I am not 100% sure about logs, but if i recall, logs will be present too)

If there were no occurences of data transfer to NUDF post 12:00:00AM, then it seems to be the updates were not synced b/w the agent and the server...does deleting .settings from the client machine help ?

smithj
Level 6

Hi VJware

I deleted all the users backup data and disabled their accounts on the DLO Console as they were creating millions of logs on the NUDF, causing performance issues on the filer location. I'm just wondering, would there be continuous logs created on the DUDF if they can't reach the NUDF?

I haven't tried deleting the .settings folder from the client yet, they are based in the US and I'm in Ireland, so it'll take a few days

Thanks

Jimmy

smithj
Level 6

Hi VJware

Also, should the console, remove log files older than 14days?

Thanks

Jimmy

Enzo_JE
Level 2

Was there any resolution to this issue? 

 

I seem to have the same issues from time to time with some of my DLO clients. I'm on Symantec DLO 7.5.1 and the agents are on 7.5.1 as well. 

smithj
Level 6

Hi Enzo JE

After many months chasing Symantec to try and get this resolved, we ended up downgrading all our clients to 7.0. Symantec did try to analyse data we collected, but we spent so much time trying to fix it that we decided to downgrade and everything is fine now. Apparently it is something to do with Dedupe, even though we had it turned off, it still caused problems. Hopefully 8.0 may resolve some of these issues. For now we're sticking with 7.0.

Sorry, I couldn't supply you with a resolution. Maybe if you contact Symantec directly they may have found something to fix the problem

Jimmy

Enzo_JE
Level 2

Jimmy,

 

Thank you for your reply. I'm sorry to hear that you had to roll back. But if it's working on 7.0, I think I may have to do the same. I will contact symantec for support. 


Thank you for your help,

Enzo

smithj
Level 6

No problem Enzo

Can you let me know if you get anywhere with this?

Thanks

Jimmy