NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.

October Hits

Posted by Preston on 2009-11-01

(We interrupt this regularly scheduled blog article with a reminder that Enterprise Systems Backup and Recovery: A Corporate Insurance Policy is currently on-sale with the publisher, CRC Press, as well as continuing to be available from such other fine online retailers as Amazon and others. Don’t forget – having enterprise class backup and recovery software is only just part of the equation in ensuring that you have a well running and reliable backup and recovery system. For comprehensive details about building that complete and reliable system, the book is an indispensable resource.)

So with October over, we’ve got some clear winners in the blog-article popularity stakes. Driven by search engine referrals we have a return to the top of the “Basics – Fixing NSR Peer information errors“. This is something that a constant turnover of visitors to the blog.

Here’s a thought: it’s time this should be addressed in the NetWorker Management Console. That’s right, instead of having NetWorker just log these warnings/errors, it would be handy if instead there was a section of NMC devoted to “intervention required” events … let’s see, that would probably fit most in the monitoring panel, and could even be reported under logging, with a double-click on the event to lead into a dialog box/session offering to delete the offending peer information if and only if the NetWorker administrator were certain that the host wasn’t being spoofed.

If you’re wondering why you need to fix these errors, it’s simple: they cause all sorts of issues when it comes time to recovery – either directly when trying to recover data for that client back onto that client, or as part of a directed recovery.

Sorry, the comment form is closed at this time.