ADSM-L

Re: [ADSM-L] ANS5013E Not enough memory for backup operation

2008-10-09 12:03:21
Subject: Re: [ADSM-L] ANS5013E Not enough memory for backup operation
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 9 Oct 2008 11:48:39 -0400
Are there any hidden controls on where it puts the "diskcache"?  The book
doesn't seem to indicate anything for MEMORYEFFICIENT other than
YES/NO/DISKCACHEMETHOD?

The node hasn't been backing up.  That is how this issue saw
daylight....when I contacted the client about their backups
failing....they said "yeah....we have been seeing these errors in the logs
and didn't know what to do about them", not that they ever thought of
contacting me......



Wanda Prather <wprather AT JASI DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/09/2008 11:41 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] ANS5013E Not enough memory for backup operation






Hi Zoltan,

I've seen the problem on clients with as few as 10m files.
When you do a typical incremental backup, the first thing that happens is
that the server pushes down to the client a list of the "active" backup
set.

The problem is with the client handling that list.
I'm surprised you aren't also having problems with the client completing
backups on time, having to navigate a filesystem that large.

To fix the memory issue, the quick and dirty is MEMORYEFFICIENT
DISKCACHEMETHOD.
That lets the client use disk space to store that humongous list.  Never
had
it cause a problem, nor does it seem to slow things down that much.

If you still have issues, and the daily file change rate is low, then go
to
journaling.


W

On Thu, Oct 9, 2008 at 11:23 AM, Zoltan Forray/AC/VCU
<zforray AT vcu DOT edu>wrote:

> Is there a "realistic" maximum number of files a Windows client can
handle
> before having this kind of problem?
>
> This system has 30-40 MILLION objects/files.
>
> Not sure if this error is caused by the large number of files or a
client
> problem.  They are currently running the 5.5.0.6 client. Recommended at
> least going to the 5.5.1.1 level before we troubleshoot this problem,
> further, since they are also getting the dreaded "
>
>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup\DRM.
> RC = 13." error which IIRC, the 5.5.1.x client resolves/addresses.
>
> If this doesn't help, what other recommendations are there to handle
this
> situation?  MEMORYEFFICIENTBACKUP ?   Multiple backup/node definitions
to
> run different backups for each drive (1-drive has 26M and another has
> 11M).
>