Unsolved

This post is more than 5 years old

16 Posts

1414

September 14th, 2011 02:00

/nsr on SAN best practice

Hi -

we are currently thinking of moving of /nsr partition onto a SAN AX4 storage arrray as we are running out of local storage

Is there any docs out there for best practices regarding this.

I would think this would need to work with clones/snapview because if there is a corruption on the

primary side it would get replicated leaving us with no failback option

So probably not as straight forward

thanks

Abid

2 Intern

 • 

128 Posts

September 14th, 2011 05:00

Hi Abid,

Normally, /nsr/index is the most consuming disk space. It's so easy to move them: you only need to edit index path at client configuration (in NMC), move the folders and restart Networker Server daemons. If you are thinking about moving all /nsr, you'll need to read Networker Disaster Recovery Guide carefully.

Regards

Claudio

2 Posts

September 14th, 2011 12:00

Hi Abid,

I'm not 100% sure of what you need to do, but from the sound of it a product called FilePilot Copy might help (http://www.filepilotsoftware.com). With it you could do the copy as a file copy instead of a block copy. Or, if you still wanted to use what you have for the actual copy, File Pilot Copy has a "dry run" feature. But whether you do it as a copy or dry run, File Pilot Copy would do a file by file copy and spot any corruption or other file issues. The detailed log would then tell you what files are an issue. And then you could fix them accordingly.

So I'd do a dry run, then copy your normal way or use File Pilot Copy. You could also do the copy with File Copy right from the start, fix exceptions listed in the log, and then do an Update Copy. Our users tell us we do a copy as fast as other product's update copy, and that our update copy is easily 10 times faster.

If you have questions there are contact details on the web site.

I hope that helps.

Thanks,

Doug

445 Posts

September 15th, 2011 00:00

Abid,

If you want to use SAN disk for /nsr then you must look at the latency which this may introduce for access. There have been Customers who has moved or started on SAN disk and this has become an issue with performance in NetWorker. The software makes frequent updates to many folders within /nsr (res, jobsdb, logs and index) which can cause issues. Ensure the disk latency is 25ms or below for stable backup performance good backup speeds, otherwise move the some or all of the indexes as suggested in the previous progress and keep on local storage.

There is a Performance Optimisation Planning Guide available on Powerlink which has more details at: -

Home > Support > Technical Documentation and Advisories > Software ~ J-O ~ Documentation > NetWorker Family > NetWorker > 7.6 & Service Packs

Regards,

Bill Mason

23 Posts

September 15th, 2011 06:00

Hello Abid,

You should also download with the Peformance Guide as per Bill's recommendation above ; a copy of the EMC Technical Note:

IOPS Requirements for the NetWorker Server Technical Notes

P/N 300-012-592

REV A02  June 2011

Home > Support > Technical Documentation and Advisories > Software ~ J-O ~ Documentation > NetWorker Family > Technical Notes

Regards,

Conor.

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

September 15th, 2011 11:00

Abid Shah wrote:

Hi -

we are currently thinking of moving of /nsr partition onto a SAN AX4 storage arrray as we are running out of local storage

Is there any docs out there for best practices regarding this.

I would think this would need to work with clones/snapview because if there is a corruption on the

primary side it would get replicated leaving us with no failback option

So probably not as straight forward

Is this Windows or UNIX?  I assume UNIX... Anyway, I would do following:

- stop NW

- move from local disk to /nsr to AX4

- update /nsr symlink /nsr--> /mnt/with/storage/on/ax4

- start NW

On Windows, pretty much the same except that easiest way to move is to reinstall software with install path on AX array.

You can't use snapshots against local disks - only against volumes which are already on disk array.   Replication is there for HA and quick failover.  If something get's corrupted, you recover from backup - as always. 

No Events found!

Top