Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- VOX
- VOX Knowledge Base
- Data Protection Knowledge Base
- Articles
- Whitepaper: Veritas NetBackup™ 6.5: Designing and ...
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Turls
Level 6
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 01-04-2010 11:57 AM
Abstract
Veritas NetBackup™ 6.5 introduces two new features, Data Classifications and Storage Lifecycle Policies, that are intended to simplify the way in which backed-up data is organized. This paper looks at how these features relate to recovery service levels and how they can be deployed to help ensure that backup storage is used cost-effectively while still maintaining appropriate levels of recoverability.
1.0 An overview of recovery service levels
A service level is an agreed standard (normally a minimum) for the delivery of a service between a customer and a supplier. In the world of data protection, the service level is based on recovery capability—there is no such thing as a “backup service level.” Two key concepts underpin all recovery service levels:
Recovery point objective (RPO)—The most recent state to which an application or server can be recovered in the event of a failure. The RPO is directly linked to the frequency of the protection process; if the application is protected by backups alone, then it means how often a backup is run.
Recovery time objective (RTO)—The time required to recover the application or server to the RPO from the moment that a problem is detected. Many factors influence the RTO—including the provisioning of hardware and the roll-forward time for application transaction logs—but one constant factor is the time needed to restore the data from the backup or snapshot that forms the RPO.
When setting up a data protection system, it is fairly typical to define three or four different service levels, or tiers, for data protection to meet the requirements of applications that are of varying importance to the business. An example might be something like this:
The reason for using a tiered system of this kind is that the cost of storage devices that can support short periods of RTO and RPO is considerable. Applying longer RPO and RTO values to non-critical data allows the use of lower-cost backup media and longer intervals between backups (resulting in less data being held on backup storage and in further reduced costs).
Recovery service levels are generally oriented toward recovery to the last “known good state” and do not incorporate policies for retention of the data beyond the time of the next backup. However, many applications, particularly the more critical ones, are often given long backup retention periods, either for specific compliance reasons or due to some requirement of the application owners. One problem with associating long retention periods with backups of “critical” applications is that, in order to meet the short RPO/RTO targets of the initial recovery period, a high-cost storage medium is often used to store the backup data. Long-term retention on a high-cost storage medium is capital-intensive, and it is therefore desirable to transfer the data to a lower-cost storage medium once the initial rapid recovery requirement has passed (i.e., when a more recent RPO exists). Once the initial recovery period has passed, it is reasonable to assume that the RTO requirements can be relaxed and that this relaxation can be extended as the time from when the backup was created increases. If the RTO is increased, the data can be moved to slower, lowercost storage without contravening the service level—but often, this is not done. One main reason for this is that the cost of managing the migration of backups from high-cost to low-cost storage is often prohibitive. This is where Storage Lifecycle Policies come in, as they can be used to automate the migration process from high-cost, short-term RTO storage to low-cost, longer-term RTO storage as the backup ages.
To read the complete article, please download the PDF.
Veritas NetBackup™ 6.5 introduces two new features, Data Classifications and Storage Lifecycle Policies, that are intended to simplify the way in which backed-up data is organized. This paper looks at how these features relate to recovery service levels and how they can be deployed to help ensure that backup storage is used cost-effectively while still maintaining appropriate levels of recoverability.
1.0 An overview of recovery service levels
A service level is an agreed standard (normally a minimum) for the delivery of a service between a customer and a supplier. In the world of data protection, the service level is based on recovery capability—there is no such thing as a “backup service level.” Two key concepts underpin all recovery service levels:
Recovery point objective (RPO)—The most recent state to which an application or server can be recovered in the event of a failure. The RPO is directly linked to the frequency of the protection process; if the application is protected by backups alone, then it means how often a backup is run.
Recovery time objective (RTO)—The time required to recover the application or server to the RPO from the moment that a problem is detected. Many factors influence the RTO—including the provisioning of hardware and the roll-forward time for application transaction logs—but one constant factor is the time needed to restore the data from the backup or snapshot that forms the RPO.
When setting up a data protection system, it is fairly typical to define three or four different service levels, or tiers, for data protection to meet the requirements of applications that are of varying importance to the business. An example might be something like this:
- Platinum service level—Uses snapshot backup technologies to take frequent backups of mission-critical applications such as order processing systems and transaction processing systems; typical RPO and RTO of one or two hours
- Gold service level—Uses frequent backups, perhaps every six hours or so, for important but non-critical applications such as e-mail, CRM, and HR systems; typical RPO and RTO of 12 hours or less
- Silver service level—daily backup, used to protect non-critical (such as user file and print data) and relatively static data. Typical RPO and RTO of one or two days.
The reason for using a tiered system of this kind is that the cost of storage devices that can support short periods of RTO and RPO is considerable. Applying longer RPO and RTO values to non-critical data allows the use of lower-cost backup media and longer intervals between backups (resulting in less data being held on backup storage and in further reduced costs).
Recovery service levels are generally oriented toward recovery to the last “known good state” and do not incorporate policies for retention of the data beyond the time of the next backup. However, many applications, particularly the more critical ones, are often given long backup retention periods, either for specific compliance reasons or due to some requirement of the application owners. One problem with associating long retention periods with backups of “critical” applications is that, in order to meet the short RPO/RTO targets of the initial recovery period, a high-cost storage medium is often used to store the backup data. Long-term retention on a high-cost storage medium is capital-intensive, and it is therefore desirable to transfer the data to a lower-cost storage medium once the initial rapid recovery requirement has passed (i.e., when a more recent RPO exists). Once the initial recovery period has passed, it is reasonable to assume that the RTO requirements can be relaxed and that this relaxation can be extended as the time from when the backup was created increases. If the RTO is increased, the data can be moved to slower, lowercost storage without contravening the service level—but often, this is not done. One main reason for this is that the cost of managing the migration of backups from high-cost to low-cost storage is often prohibitive. This is where Storage Lifecycle Policies come in, as they can be used to automate the migration process from high-cost, short-term RTO storage to low-cost, longer-term RTO storage as the backup ages.
To read the complete article, please download the PDF.
