One of the most powerful aspects of NetWorker is that the entire design philosophy of the product is that of a framework. Rather than trying to be all things to all people, NetWorker has a core set of components and a flexible, extensible CLI, allowing relatively easy adaptation to suit site-specific purposes.
Indeed, in my book, I suggest that a backup product must be designed as a framework rather than a monolithic product in order to be classified as enterprise – attempting at the design stage to anticipate every possible user requirement and deny all other options hobbles and hinders, rather than enhances backup.
While we should focus on backup products that act as a framework to the overall data protection process, we must also be mindful of the obligation this puts on the architecture and maintenance of the product. Using a framework doesn’t entitle you to a blank cheque on design – every framework has limits. After all, you can’t build the framework for a 3 bedroom house and then use it to construct a 40-room mansion.
Every framework has limits.
There’s some basic design rules that should of course be followed with a backup system, outside of the core principles of ensuring it can recover data when required and as quickly as required. Two of the most important principles are:
- The system should be as simple as possible, but no simpler.
- The system should follow the rule of least astonishment.
The first rule is an acknowledgement that the more you “dumb down” a system, the more chance there is of locking users into non-choices. You could potentially design a backup solution that has a single console, and that console has just 2 giant buttons – green for go and red for stop. (Excluding recovery.) But pressing the red-stop button may abort everything and reboot all systems in the environment as well as ejecting all media being used, etc. Hardly a graceful way to allow an administrator to say, stop one errant backup. As a system is simplified, the granularity of control over it is equally reduced. Thus, the system should be as simple as possible, but no simpler.
The second rule is the core rule to follow for a framework – a suitably trained user, with minimal site knowledge, should be able to sit down in front of your system and not only review the configuration accurately, but also be able to perform general administrative functions without fear of surprise. When I’m talking about this in training courses, I use exaggerated examples – a user, for instance, when encountering a script called “eject_media” should be able to run this without discovering it erases and ejects media, or anything else suitably dumb.
It’s also the second rule we’re most likely see violated in sites that … ahem … “go nuts” with customising how their products work. For instance, in larger sites, with high amounts of dependencies on job schedules, it can become necessary to move scheduling of backups out of the NetWorker job daemon and into an alternate scheduler. However, that doesn’t give carte blanche to run as many jobs as desired at any point in time. In short, NetWorker provides a basic scheduling framework which not only handles starting jobs, but also places limits on internal resource oversubscription. If you take the job scheduling away from NetWorker, this creates the obvious requirement to construct your own interrogation and management process for resource utilisation.
Ironically, this leads to these sites being most vocal in talking about the “limitations” they’re experiencing; yet for me it actually goes to prove the fundamental rule of IT: technology is rarely the issue. If the framework is being bent and twisted out of all proportion, is it the fault of the product, or the fault of the design?
It’s almost impossible for a software product to be fault free – well at least, once it builds to a certain level of complexity (i.e., becomes useful). That being said, misusing the software does not necessarily point to a software flaw*. Don’t confuse “extensible framework” as “infinitely extensible framework”.
As you use NetWorker and the framework it provides, always be mindful the programmers provided you a framework because they couldn’t anticipate all your needs. This equally means they can’t stop you from shooting yourself in the foot. Only you can be in control of that.
Remember: all frameworks have limits.
—
* Of course, I’m not talking about simple things like the failure to sanitise input, etc.