It's an medium-to-advanced level project. For example it installs a 
write-intercept driver under the file system and this will conflict with any 
other third-party drivers at the same level. You have to configure a cache LUN 
for snapshot storage. It uses NDMP protocol (included with the product) to 
control the backup stream. If none of that scares you then read the 
documentation carefully and go for it.


> 
> Hi,
> 
> can anybody share their experience with NetWorker SnapImage those who have
> been using. What level of expertise is required and how complicated it is to
> deploy and havethe solution work!
> 
> Is it necessary for opting for EMC Professional Services ?
> 
> Regards
> Shyam
> 
> 
> On 6/8/06, Steve Warren <swarren AT cresend DOT com> wrote:
> >
> > If you try the suggestions recommended here and it doesn't solve your
> > problem, I suggest you seriously consider SnapImage. It has it's limitations
> > but restore performance from tape is not the issue it's been represented to
> > be here. And on a big slow disk with millions of files, there's no faster
> > way to get file-granular backups to tape.
> >
> > SnapImage sorts all the file extents in the restore list  before it starts
> > so the restore is done in a single pass. Pieces get restored in tape order
> > and assembled on the fly. It's certainly no slower than restoring from a
> > normal multiplexed tape.
> >
> > There are things about it that are a little more cumbersome though so you
> > should make sure you really have a need for it before you go that direction.
> >
> > > > > I think that other person meant that maybe there'd be a way
> > > > > to use the "update" function within nsradmin to update the
> > > > > client's list of savesets to be backed up, in an automated fashion.
> > > >
> > > > I have no problem scripting nsradmin, but what does updating the
> > client
> > > > record more frequently accomplish?
> > >
> > > I read the message not that it needs to be terribly frequent, but that
> > > it needs to be automated so that human intervention isn't needed to pick
> > > up new folders.
> > >
> > > The frequency just gives the maximum time that can elapse between the
> > > creation (and population) of a folder and having it hit the backups.
> > > Daily would probably be sufficient in most environments.
> > >
> > > --
> > > Darren Dunham                                           ddunham AT taos 
> > > DOT com
> > > Senior Technical Consultant         TAOS            http://www.taos.com/
> > > Got some Dr Pepper?                           San Francisco, CA bay area
> > >          < This line left intentionally blank to confuse you. >
> > >
> > > 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 
> > > [email protected] you have any problems
> > > wit 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 [email protected] 
> > you have any problems
> > wit 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
wit 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