Data gathering
Define the workload types that you have and the front-end terabytes (FETB) of each workload. A workload type would be classified as VMware, Oracle, SQL, MS-Exchange, NDMP, etc. For each workload type, then determine if there are some key data characteristics that could be of great importance.
For instance, if Enterprise Vault (EV) is one of the workload types, then a key data characteristic is that it can sometimes result in millions of little files which results in slower, resource intensive backups. Sometimes EV data can be grouped into Windows Cabinet Files (CAB), but if WORM is a factor, then CAB collections aren't an option which means being faced with protecting a workload type with a data characteristic of millions of files with an approximate size of 40KB per file. This is excluding databases and indexes that must be protected as part of a full EV backup.
If the workload types are Oracle and/or SQL, then understanding if transaction and/or archive logs are required to be protected is also very important as it can result in thousands of tiny jobs. The overhead of thousands of tiny jobs versus a smaller number of larger jobs has been observed to be a significant factor in determining compute requirements.
If VMware is the workload type, then often it makes sense to leverage the Accelerator feature to improve performance of VMware backups. The use of that feature leverages additional compute resources, but only for the first copy of the data.
In the case that a specific workload leverages 3rd party encryption, it is recommended that the customer consider leveraging our native encryption instead of a 3rd party encryption. In some cases, a customer may require a specific workload to be encrypted at the source. If this is case, any backups of this data will experience very poor dedupe rates. Therefore, the use of MSDP isn't a good fit for this type of workload. That said, understanding this requirement is very important as it can have a significant impact on solution design, feature use, and solution sizing.
Once the workload qualification is done, calculate how large a complete full backup would be for each workload type. Then, discuss with stakeholders the estimated daily rate of change per workload type. That information is also very important.
Complete a data lifecycle for the protection strategy. A data lifecycle traces each step of the primary and secondary processing of a specific type of workload. For example, for a specific workload, is there a secondary operation required? If so, is the secondary operation a duplication, or perhaps a replication via Auto-Image Replication (AIR)? Also, are there additional steps in the process that involve writing an N+1 copy of the data to S3, or perhaps to tape for offsite storage? Tracing each step is critical because each step will be part of a NetBackup Storage Lifecycle Policy (SLP), which then requires resources to complete.
It is important to consider what the retention requirements are for each copy. Perhaps the primary copy of the data would be retained in an MSDP pool for 35 days and the secondary copy via AIR is kept for 90 days. Then, perhaps this workload requires a long-term retention (LTR) whereby a 3rd copy is sent to an S3 bucket or out to tape for a period of several years.
As part of this step in defining the retention requirements, determine what type of backup is required and how often, as well as which type of backups are targeted for LTR. Is it a weekly full? A monthly full? Typically, frequent backups being duplicated or replicated to LTR aren't a good fit because of cost and long-term management of such a large amount of data. Consider the S3 storage costs for storing large amounts of data with an LTR of many years. For customers that require a tape copy, consider the management implications of an LTR of potentially hundreds of tapes offsite for many years. There is a cost of time and compute resources to produce a tape copy, and then the cost of maintaining that data in the NetBackup catalog, as well as the cost of storing those tapes in a vault offsite.
Some customers require incrementals or transaction logs to be subject to secondary operations, like replication or duplication. If such a requirement exists, it is important to narrow the requirement to the exact workloads or specific host clients that require incrementals and transaction logs to be replicated or duplicated. It is important not to paint this requirement with a broad brush because it seems expedient.
Another factor that many customers don't fully consider is the implication of an infinite retention. The idea of an infinite retention is not realistic.
Consider for a moment a large database containing patient records. That database should be protected by a variety of primary and secondary methods. Backup is a secondary method, whilst high availability and disaster recovery should be the primary protection methods. It is reasonable to require this database to maintain patient records infinitely, but the backups of that data shouldn't require an infinite retention. While most states and countries have requirements around record retention, it is important to understand those requirements and not just presume an infinite retention is required. It would be more reasonable for an LTR for monthly full backups to be up to 7 years. If the patient data is maintained in the database indefinitely, then that data would be in every single full backup taken. Why would a customer want to restore a database from greater than 30 days if the data in the source is never archived or purged? On the outside chance that the primary copy of the database is corrupted, the business owner would want the most recent, consistent copy restored.
Keep this in mind when retention levels are set for n+1 copies of specific workloads.
Determining the timing of when backups must run based upon internal customer RPO, RTO, and SLAs is extremely important because it is a significant variable that drives when, and how fast backups and secondary operations like replication and duplication must be completed. When MSDP pools are unable to keep up with backup and secondary operations, that can result in missed backup windows and SLP backlog.
Consider a scenario when backups are kept for only 7 days, but the N+1 copy taken during secondary operations via an SLP is kept for 35 days. If backups don't meet their backup windows because of workload imbalance and/or solution under-sizing, then that performance degradation can impact the performance of secondary operations. In extreme situations, that can result in data that is being replicated and/or duplicated that is already considered past the retention period. Clearly, it is important to avoid that type of scenario, which is why sizing for compute, as well as capacity, is paramount.