Best Practice – Are index pools required?

A common question that you see fielded regularly is whether or not it’s “best practice” to have dedicated index pools.

To me, there’s only a couple of pros to having index backups in their own pools, and a lot of potential cons.

Pros

1. In the event of needing to perform a total index restore, all index data will be on the same set of media.
2. In more complex setups, it allows indices to be directed to specific devices, or storage nodes.

Cons

1. In physical and virtual tape environments, it generates an artificial requirement for additional drives and media. Particularly in the realm of physical tape devices and media, this is odious (and costly); even in the realm of virtualised tape drives and media, it increases the likelihood of running up against storage node/device count limitations. That cost of course for physical media isn’t just limited additional tape drives and media, but all forms of handling – e.g., offsiting costs, operator costs, etc.
2. Further, with physical tape, your available capacity decreases as you add pools, since any media which has been labelled into a particular pool can no longer be used for backups for another pool, until the tape has been recycled/relabelled. Thus, once say, an LTO-5 tape has been labelled for writing with the index pool, that’s 1.5TB of backup capacity that has been immediately sequestered from core data backups. (This typically isn’t an issue for VTLs where storage is thin-provisioned.)
3. One final consideration for physical tape – having a dedicated index pool often means having larger slot counts to accommodate permanently having index media in the library. This isn’t required when indices are written to the active data pools, since you just factor for the standard media requirements.
4. When working with full disk backup (advanced file type devices, Data Domain Boost, etc.), it increases the need for cloning and/or staging activities. (And again, the number of devices required increase.)
5. More devices means more nsrmmd processes, which in turn means more memory requirements for the backup server and any affected storage node. Of course, this will be a relatively small impact, but it still must be considered as a ‘con’.
6. While NetWorker has, over successive versions, become better at handling changes to pool configurations while backup activities are happening, it isn’t perfect. Artificially increasing the number of pools you’re running increases the risk you’ll want to make changes to pools while backups are being performed.

To me, all those “cons” add up to one conclusion – except under exceptional circumstances, it’s generally best practice to avoid having indices backed up to their own pool. Like all “rules”, there’ll be exceptions, but I’ll wager there are far fewer necessary exceptions to this than there are instances of it being done.