Best Practice – Pool content

NB: Don’t forget to fill in the NetWorker Usage Survey, if you haven’t already done so. It’s open until 31 January 2013.

NetWorker has a bunch of predefined pools that come in the bootstrap configuration: Default, Default Clone, Offsite, Archive, etc. For the purposes of best practices, I’d suggest these pools should be used for reference purposes only: there are better and more logical ways to separate data than the predefined pools.

Generally speaking, pools should separate data by common features, so as to make backup management more straight forward. For this reason, I recommend pool content breakdown by:

1. Backup frequency / retention
2. Intended location of media
3. Other logical breakdowns (only if required).

Using this layout, I typically end up with pools such as the following:

1. Daily Onsite
2. Daily Offsite
3. Monthly Onsite
4. Monthly Offsite
5. Yearly Onsite
6. Yearly Offsite

The “Daily”, “Monthly” and “Yearly” in the pool titles refer to the frequency at which the backups going to those pools are performed. On that front, I try to align naming conventions to suit backup frequency. Therefore I’ll have “Daily X” schedules, a “Daily” policy, “Daily X” groups, and on on.

The “other logical breakdowns” refers to introducing additional separation points, if required, that are consistent. For example, if dealing with a backup environment that features both encrypted-at-rest and unencrypted-at-rest data that is required to be stored on separate media, you might end up with say:

1. Daily Onsite Secure
2. Daily Offsite Secure
3. Daily Onsite Insecure
4. Daily Offsite Insecure

Alternatively, if it is necessary to send all Oracle data to one particular type of media, you might end up with:

1. Daily Onsite
2. Daily Onsite Oracle
3. Daily Offsite
4. Daily Office Oracle

The advantages of this style of pool layout are fairly obvious:

1. Data stored by the same backup frequency/retention is likely to expire at a broadly similar time – if configured correctly it’ll avoid situations where you have media ready to recycle except for one or two savesets that have vastly longer retention times;
2. Data that needs to be physically separated is;
3. The layout still has flexibility in terms of additional layers of separation.

There are undoubtedly other ways of configuring pools within NetWorker for data separation, but in my opinion, this represents a best practice approach most likely to allow for a flexible, logical and functionally useful setup.

PS: Don’t forget to fill in the NetWorker Usage Survey, if you haven’t already done so. It’s open until 31 January 2013.