Hello,
If you use script you can send the logs wherever you wish, I suggest you
look into storage node and or NAS Device with NDMP backups or split up the
data into multiple servers perhaps using DFS.
I do believe the bottleneck is the server, you would only see data
transfer once the file system walk is complete and networker is ready to
transfer the data to the VTL, i am not very intune with VSS backups, but
it seems like VSS is processing the data to be snapped and after a long
time when it's ready the data is transferred to VTL.
Have you tried turning off VSS and doing a straight file level backup, one
option may be to break up the data and do either consolidated backups or
backup various directories one at a time with varying schedule.
You may also want to team couple of NIC and provide high throughput
Networkering capabilities for this client.
HTH
aka004db <networker-forum AT BACKUPCENTRAL DOT COM>
Sent by: EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
03/18/2009 04:25 PM
Please respond to
NETWORKER AT LISTSERV.TEMPLE DOT EDU
To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc
Subject
Window 2008 memory and logs
[quote="Fazil Saiyed"]Hello,
Please review storage node or snapimage ( if still available) option for
this client.
How I can enable local logging on the EMC networker client.
If you run the client by script, then -v ( each extra v will
increase the logging level) with the save cmd will do it ( logs will
go to savegrp log)or you can do verbose logging for the group. ( I would
be very careful with either option, as the log file fills up, it
could adversely impact your backup & server performance, you
will get failure messages without extra logging ( i.e open files etc)
aka004db: So in the end the logs will allways completely remain on the
backup server, and not a copy on the client as well? In my eventlog no
entries are written as well..
- Is it possible not to dump the full filesystem for each drive prior to
backing up data?
You will need to look into Native OS capabilities, i.e VSS, also
look into change journal to make use of it's capabilities
aka004db: As far as I can tell from the documentation it is even
impossible not to use VSS. The change journal is a part of VSS, so that is
used and enabled. I simply cannot figure out the reason why every save.exe
process needs to build a complete directory listing...
- Is it necessary to put a hughe amount of physical memory in the server
for backup purposes only?
I don't think so, however, expect backups to run very long time,
unless you breakup the data in various saveset and configure Legato
backups to be spread out. ( How much data and files are you referring too
?)
aka004db: I actually tried splitting up into different savesets, but that
only made things worse as more save.exe processes start to build up a
directory listing in memory. Note this is not only for the designated
logical disk to be backed up, but also on volumes not a member of the save
set :-(
The data is about 2,5 TB written data full of homedirectories,
profiledirectories etc. etc. so, flat file data is millions and millions
of folders...
If you cannot get SN capabilities , try and serrate file system if
possible to different logical disk & spread out your backups, this way you
may gain slight advantage on read access & add a robust raid controller ,
optimized for read. ( This are optional steps and will only go so far)
Does your backup go to tape or VTL ? You may gain slightly better
performance if you use disk or VTL backups vs Tape ( again few other may
disagree)
HTH
aka004db: backup is to VTL, but the data transfer does not even occur so
the bottleneck is not on the server. I did another test today and one
actually finished: save.exe pushed 10 GB of data for a VSS:SYSTEM into the
server, but it took the process more than 5 GB in memory... :-( and
several hours. The actual data transfer was finished in a blink of an eye!
+----------------------------------------------------------------------
|This was sent by arjan.kauffman AT tele2 DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
