精通数据备份与恢复：现代数据保护策略

需积分: 0 17 浏览量更新于2024-07-26 收藏 7.13MB PDF 举报

"《数据备份与恢复》是Steven Nelson撰写的一本关于数据保护的专业书籍，主要探讨了在海量数据时代如何确保信息的安全。书中涵盖了新发展的数据保护技术、单实例存储对备份基础设施的影响，以及备份和数据复制策略的运用。同时，书中也讨论了B2D（Backup to Disk）和D2D（Disk to Disk）策略的误用，无磁带备份环境，以及连续数据保护和远程复制策略在备份策略中的整合。本书旨在帮助读者理解不同备份软件的设计原理，设计实际可行的恢复方案，并考虑新的数据保护标准和数据复制的影响。书中通过具体的软件架构（如CommVault和NetBackup）和应用备份策略进行深入讲解，并提供了样本备份环境以供实践参考。此外，还涵盖了监控和报告等重要环节。" 本书适用于系统管理员、IT专业人员、数据保护专家，以及任何关心如何在TB级别数据量下保障信息资产安全的读者。全书分为11章，详细内容包括： 1. 备份与恢复基础：介绍备份恢复的基本概念和重要性。 2. 备份软件：探讨各种备份软件的功能和选择。 3. 物理备份介质：讨论磁带、硬盘等传统备份介质的优缺点。 4. 虚拟备份介质：介绍虚拟化环境下的备份解决方案。 5. 新媒体技术：讨论如云存储、固态硬盘等新技术在备份领域的应用。 6. 软件架构——CommVault：解析CommVault系统的备份架构和特性。 7. 软件架构——NetBackup：分析NetBackup的备份和恢复策略。 8. 应用备份策略：针对不同类型的应用程序提供备份最佳实践。 9. 整合应用：展示如何将所有元素结合，创建实际的备份环境示例。 10. 监控与报告：讲解如何监控备份过程并生成报告，以确保备份系统的效率和可靠性。 11. 总结：回顾全书核心内容，总结关键要点。通过学习本书，读者能够掌握不同备份技术的使用，理解各种备份架构，设计适应组织需求的备份和恢复策略，从而在面对数据丢失风险时，有能力迅速恢复业务运行。

CHAPTER 1 ■ INTRODUCTION TO BACKUP AND RECOVERY

date of the backup creation. This typically becomes an issue with backups of database systems, but can

also affect all types of software applications.

When architecting backup systems, it is important to consider data to be backed up as well as data

that will be archived or stored for long periods. Although backups and archives are related, they are

distinctly different in character. Backups should be used to provide short- and medium-term protection

of data for purposes of restoration in the event of data loss, whereas archives provide long-term storage

of data in immutable formats, on static or protected media. The data classification is critical for the

proper design of backup systems needed to provide the level of protection required by the organization.

Service and Recovery Objectives: Definitions

When designing a backup solution, there are three key measures that will be the primary governors of

the design with regard to any particular set of data:

• Recovery Time Objective (RTO)

• Recovery Point Objective (RPO)

• Service Level Agreement (SLA) associated with the data set

As such, these measures deserve a substantial review of their meaning and impact on design.

There are many different definitions of the SLA that are available. It can refer to the quality of service

provided to a customer, the responsiveness of operational personnel to requests, and/or many other

factors, but the measure that will be the focus of this discussion is the window in which backups of a

particular data set are accomplished. The identification of what constitutes a backup window can be

particularly difficult because different stakeholders in the completion of the backup will have differing

views of when the window should start and end, and the length of the window. This definition of the SLA

must be well-documented and agreed-upon by all parties so that there is no confusion regarding how

the SLA is to be interpreted. The proper performance expectations of all parties should be set well before

the SLA is in force.

The RTO represents the maximum amount of time that can elapse between the arbitrary start of the

recovery and the release of the recovered data to the end user. Although this seems like a simple

definition, there can be a great many vagaries embedded into this measure if you look closely (see Figure

1–10). The first is the definition of when the recovery starts. Depending on who you are in relation to the

data being recovered, it can mean different things. If you are the end user of the data, this window might

start at the point of failure: “I have lost data and I need to access it again within the next ‘X’ hours.” If you

are the systems administrator responsible for where the data resides, it might start at the point at which

the system is ready to receive the restoration: “The system is up and I need the data back on the system

in ‘X’ hours.” Finally, as the backup administrator, you are concerned with the amount of time that it

takes from the initiation of the restore to the end of the restore, including identification of data to be

restored—“I need to find data ‘ABC’, start the restore, and have the restore finish in ‘X’ hours.”

CHAPTER 1 ■ INTRODUCTION TO BACKUP AND RECOVERY

From the perspective of the data owner, this might represent a number of transactions, an amount

of data that can be lost, or a particular age of data that can be regenerated: “The organization can afford

to lose only the last 30 transactions”.

The primary issue with establishing the RPO is the translation between time and data. A good way to

illustrate this is to look at the two requirement statements in the previous paragraph. The first one, from

the backup administrator, talks in terms of time between backups. For the backup administrator, the

only way to measure RPO is in terms of time—it is the only variable into which any backup software has

visibility. However, the requirement statement from the organization does not have a direct temporal

component; it deals in transactions. The amount of time that a number of transactions represent

depends on any number of factors, including the type of application receiving/generating the

transactions. Online transaction processing (OLTP) database applications might measure this in

committed record/row changes; data warehouse applications might measure this in the time between

extract/transform/load (ETL) executions; graphical applications might measure this in the number of

graphic files imported. The key factors in determining an estimated time-based RPO using data

transactions are the time bound transaction rate and the number of transactions. The resulting time

between required data protection events is simply the number of transactions required to be protected,

divided by the number of transactions per unit time. For instance, if a particular database generates an

average of 100 transactions per minute, and the required RPO is to protect the last 10,000 transactions,

the data needs to be protected, at a minimum, every 100 minutes.

The other issue with RPO is that when designing solutions to meet particular RPO requirements, not

only does the data rate need to be taken into account but the time for the backup setup and data writing

also needs to be taken. In the previous example, if there is a requirement to protect the data every 8

hours, but it takes 8.5 hours to back up the data, including media loads and other overhead, the RPO has

not been met because there would be 30 minutes of data in the overlap that would not necessarily be

protected. This actually accelerates as time progresses. Again with the example, if on the first backup, it

takes 110 minutes to perform the backup, the backup cycle is 30 minutes out of sync; the next time it will

be 1 hour, and so on. If the extra time is not accounted for, within a week the backup process will be 8

hours out of sync, resulting in an actual recovery point of 16 hours.

If the cause of the offset is simply setup time, the frequency of the backups would simply need to be

adjusted to meet the RPO requirement. So, let’s say that it takes 30 minutes to set up and 8 hours to back

up the data. In order to meet the stated RPO, backups would need to happen every 7.5 hours (at a

minimum) to ensure that the right number of transactions are performed.

However, if simply changing the backup schedule does not solve the problem, there are other methods

that can be used to help mitigate the overlap, creating array-based snapshots or clones. Then performing

the backups might be able to help increase the backup speed by offloading the backups from the primary

storage. Other techniques such as using data replication, either application- or array-based, can also

provide ways to provide data protection within specified RTO windows. The point is to ensure that the data

that is the focus of the RTO specification is at least provided initial protection within the RTO window,

including any setup/breakdown processes that are necessary to complete the protection process.

■ Note So are the RTO and RPO related? Technically, they are not coupled—you can have a set of transactions that

must be protected within a certain period (RPO), but are not required to be immediately or even quickly recovered

(RTO). In practice, this tends not to be the case—RTOs tend to be proportionally as short as RPOs. Put another way, if

the data is important enough to define an RPO, the RTO will tend to be as short as or shorter than the RPO:

RPO <= RTO

Although this is not always the case, it is a generalization to keep in mind if an RPO is specified, but an RTO is not.

C H A P T E R 2

■ ■ ■

Backup Software

Software: CommVault Simpana

History and Background

Now that we have established some basic definitions in the previous chapter, we can delve into the

specifics of how to build out architectures that provide solid, scalable backups for the organization. The

most important component of any backup architecture is the backup software selected for use. We will

address the specific subject software packages individually, beginning with CommVault Simpana.

CommVault Simpana started as a project within AT&T Labs back in 1987. Originally known as

Automated Backup and Automated Recovery and Archive Software, CommVault was the internal backup

software used by AT&T Labs until the division was split off as Lucent Technologies. As part of the

divestiture of Lucent from AT&T, Automated Backup was relaunched as CommVault backup. Later

renamed as Galaxy, and currently as Simpana, CommVault is relatively unique among backup software

because it uses a Microsoft SQL database instance as the information repository for backup information.

The use of a standard database (SQL Server) allows for validation of the referential integrity of the data

within the catalog and provides for known ways to tune the database for performance in large

deployments. This does, however, require that the CommVault server (called the CommServe) be

installed on a Microsoft Windows-based system.

Terminology

Some notes regarding CommVault terminology: Backup software is in many ways similar to operating

systems particularly in the way that the terminology for functions that are common between pieces of

backup software is specific to the application. CommVault Simpana is no exception.

There are three general types of storage media within CommVault:

• Magnetic libraries (MagLib): Backup targets that reside on disk storage.

• Tape: Tape targets are any type of magnetic tape drives, whether they are in a tape

library or stand-alone tape drives.

• Single Instance Library Option (SILO): SILOs actually represent more of a policy of

migration than storage type. SILO media is simply the process of migration of

backups from MagLib to external media. However, CommVault refers to SILO as

media (this will be explained later in the chapter

Dahlmeier, Mike. Common Technology Engine. CommVault: 2009, p 323.

剩余290页未读，继续阅读

huzhouhzy

粉丝: 83
资源: 1659

精通数据备份与恢复：现代数据保护策略

网络存储·数据备份与还原

数据备份与恢复产品强制认证实施规则

数据备份与恢复技术

mysql数据备份与还原

oracle数据备份与还原.pdf

数据故障恢复管理：软RAID恢复、数据备份与还原策略

MySQL数据备份与还原：SQL备份实战

数据库维护：数据备份与还原

数据备份与恢复策略

【数据备份与还原艺术】：使用pickle进行数据恢复的高级技巧

最新资源