DE112011103378T5 - Automatic and self-adjusting backup operations - Google Patents

Abstract

Techniques for adjusting the frequency of backups and triggering event-driven backups in a storage system are disclosed herein. In one embodiment, a self-adjusting backup frequency, known as a rate of change destination, is defined to perform or delay backups for one or more volumes in the storage system based on an associated policy value. The change rate goal may be associated with one or more business or data activity events, such as the amount and type of data changes since a last backup. The storage system may also be tailored to perform or delay full or incremental backups based on a rate of change goal that measures whether a full or incremental or differential backup is more appropriate. Various data or system errors or data or business events may also be used to adjust the data retention periods for uninterrupted data protection (CDP) data and delay the rollup of CDP data.

Description

TECHNICAL AREA

The present invention relates generally to data storage and recovery techniques. More particularly, the present invention relates to backup activities and procedures triggered by business and data activity events that enable the storage and recovery of valuable data.

BACKGROUND

A tremendous increase in the volume of data and the increasing demands on the availability of data continue to require innovation in the crucial operations of data protection and data recovery. Traditional day-to-day backups are inadequate today for many business environments. There is a need for more efficient and more frequent backups, which has led to the proliferation of efficient, "always incremental" block-level data protection techniques. Current backup techniques have even evolved into Continuous Data Protection (CDP) strategies in which any data change at the input / output (I / O) level can be captured and protected.

Despite these advances in data protection operations, current practices still present inadequacies. For example, most privacy operations are time based (daily, hourly, etc.). Although there is some flexibility and granularity as to how often data protection operations are performed, time-based data protection operations are inherently incompatible with business data activities. Business data activities are often event-based, not time-based.

CDP solutions protect data at the level of individual I / O events, not time. CDP protects data at a very low granularity level of data activity (i.e., single I / O operations) and therefore presents a significant potential value for recovery. However, CDP operations also have some disadvantages. A disadvantage of CDP is that individual I / O operations often do not directly constitute a business event. For this reason, recovery at the level of individual I / O operations may not have any direct business benefit. Yet another disadvantage of CDP operations is that it is extremely difficult, and sometimes even impossible, to synchronize individual I / O operations with application transactions. Again, recovery at the level of individual I / O operations may not constitute a complete application or business transaction and is therefore limited in utility. In addition, the potential benefits of data protection are not fully exploited on the low level of granularity that CDP allows. The granularity of CDP data is typically lost when CDP data is aggregated into snapshots or other backups, and is therefore unavailable for various data error events. Although CDP data can be stored longer by configuring a longer storage period, this is very expensive in terms of processing and storage. For these reasons, backup using CDP is not widely used in the industry despite its utility.

SUMMARY

The present disclosure describes the implementation of a number of improved privacy practices designed to cause an information infrastructure to be more aware of and respond to its environment, particularly as a response to business and data activity events. Business data events include activities such as business transactions that modify or create data, updates to business applications, data shifts or copies required due to technological advancements, distribution of new software, changes to system configuration, disk space defragmentation processes, and the like. These business data events are not fully captured and protected by existing backup and recovery solutions that occur as a result of a time-based plan or as a result of I / Os.

The data protection techniques described herein are also capable of responding to data activity events in an information infrastructure and performing a full backup, for example, based on the amount of data changed since the last full backup. The numerous variations of the presently disclosed techniques provide a robust and customizable backup solution that can meet recovery time objectives (RTOs) and recovery point objectives (RPOs) much faster and more efficiently than time-based backup rules.

In a particular embodiment of the present invention disclosed herein, a method for performing event-driven automatic and self-adaptive backup operations in a memory management system setting a change rate target and associated rate of change target value that are used for event-driven backups of a data store. This rate of change goal is used to measure changes in the data store that are sequences of one or more data activity events, such as the amount or type of changed data in memory. The rate of change goal may also be a derived value based on multiple values.

The rate of change destination in the data store and any appropriate data activity are then monitored to determine if appropriate changes have occurred and backup operations are warranted. The save operations are then executed in response to reaching or exceeding the rate of change target value. The backup operations can be further customized or modified based on a policy. In addition, the backup operations can be coordinated with time-based scheduled backup operations.

In another specific embodiment of the present invention, automatic and self-adjusting backup operations may be performed in conjunction with full and incremental or differential backups of a data store. Multiple rate of change goals are used to determine whether to postpone a full backup or make it earlier than planned (and whether to postpone an incremental or differential backup, or to do it earlier than scheduled). For example, a first rate of change target and an associated first rate of change target value may be set to advance a full backup of the data store prior to a scheduled full backup, wherein the first rate of change target value defines a threshold amount of modified data of the data store where the full backup is required. A second rate of change goal and an associated second rate of change target value may be set for resetting a scheduled full backup and performing an incremental or differential backup instead of the scheduled full backup, the second rate of change target defining a maximum amount of changed data in the data store, where an incremental or differential backup is allowed. The amount of data changed since a last full backup is monitored, and a full backup of the data store is performed in response to a determination: (a) The amount of changed data backed up since the last full backup is during an incremental or differential backup cycle greater than the first rate of change target value, or (b) the amount of changed data saved since the last full backup is greater than the second rate of change target value during a full backup cycle and, similarly, an incremental or differential backup of the data store is performed in response thereto in that: (a) The amount of changed data backed up since the last full backup for the data store is less than or equal to the first rate of change target during an incremental or differential backup cycle or (b) the amount of changed data saved since the last full backup is less than or equal to the second rate of change target during a full backup cycle.

Another specific embodiment of the present invention provides for automatic and self-adjusting privacy in connection with uninterrupted data storage data protection operations. This is determined by a policy to extend the retention of data generated by the non-disruptive data protection operations over a period of time, as the Directive specifies one or more events that require an extension of the retention period and an extension of the retention period. When a data rollup (summary) for stored data is initiated, the extension of the retention period is taken from the policy according to the corresponding events. Finally, the data rollup is deferred for the duration of the storage period.

In another specific embodiment of the present invention, a storage management system is provided that includes a processor, a storage device, and instructions stored in the storage device for performing event-driven automatic and self-adjusting privacy activities in accordance with the techniques described herein. Additionally, another specific embodiment of the present invention provides a computer program product for performing event-driven automatic and self-adjusting privacy activities, the computer program product having a computer readable storage medium having computer readable program code embodied thereon for implementing the techniques described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the invention will now be described by way of example only, with reference to the accompanying drawings, in which:

1 FIG. 12 illustrates an illustration of a backup procedure performed in a memory management system according to one embodiment of the present invention; FIG.

2 FIG. 12 illustrates an illustration of a flowchart for a backup procedure during a full backup cycle, in accordance with an embodiment of the present invention; FIG.

3 FIG. 12 shows an illustration of a flowchart for a backup procedure during an incremental or differential backup cycle, and in accordance with an embodiment of the present invention

4 "In accordance with one embodiment of the present invention, an illustration of a schedule for adjusting retention periods in connection with uninterrupted privacy operations.

DETAILED DESCRIPTION

The present disclosure provides a set of data protection techniques that may be used standalone or in conjunction with existing backup scenarios. Unlike existing backup strategies that are time based only (eg, doing backups every night at 24:00), a backup schedule can be modified using the various techniques of the present invention such that backups based on other relevant factors more often or be made less frequently. These factors can be triggered by business or data activity events that more precisely control the underlying need to perform the backup at all.

The present disclosure describes improved privacy practices that may be time-based, adaptable based on changing environmental conditions, and event-based and directly related to business events and data activity. These methods address the need for more efficient backup methods that are fully synchronized with applications and executed only when required by business or data activity events. Moreover, these methods also address the need for enhancements to CDP operations so that storage times for CDP data can be automatically adjusted based on data or system errors or business events.

In one embodiment disclosed herein, a privacy policy is provided in which the frequency of the backup operations is automatically adjusted based on data activity events. As data modification activities increase, the frequency of backup operations may increase. Likewise, backup operations may be performed less frequently as data change activities decrease or come to a standstill, thereby sparing system resources. This self-adjusting backup frequency method also allows scheduled backups to run in concert with the event-driven backups. This self-adjusting backup frequency (referred to herein as the "Change Rate Objective" (CRO)) may be based on a particular amount of data (eg, 5GB of changed blocks since the last snapshot), or it may be based on a percentage changed data (for example, if 1% of the data has changed since the last backup) or based on a number of data transactions. In addition, the CRO may be configured to be used to create certain backup or disaster recovery copies, or otherwise trigger useful events.

In another embodiment, the data protection method described above is provided, augmented by a data activity backup policy that defines the sensitivity of backup operations to data modification activities in a storage management system. This policy is used in addition to and coordinated with the frequency of backup operations that are commonly used with existing time-based scenarios.

In another embodiment, an advanced analysis of a rate of change goal is provided that is applied to a conventional full backup plus incremental / differential backup approach. It keeps track of the amount of data backed up by incremental or differential backups since the last full backup. When it is time for the next full backup (or image backup) (for example, a weekly full backup), and the amount of incremental data backed up since the last full backup falls below a set amount (a target rate of change), the full Fuse reset until the amount incremental Backup data reaches the specified amount. Conversely, if during an incremental backup it is determined that a specified amount of data (or percentage of full backup) has changed since the last full backup, an unplanned full backup is triggered. This approach minimizes unnecessary data protection operations to prevent unnecessary full backups from being performed when very little data has changed. This approach also initiates event-driven data protection operations when needed to facilitate recovery (for example, a full backup can be started early if there is a large amount of changed data). In many scenarios, performing a full backup in the presence of a large amount of changed data can allow for shorter recovery times by avoiding the need for large amounts of incremental restores in addition to the full backup.

In another embodiment of the present invention, non-disruptive data protection (CDP) techniques are provided in which CDP data retention periods are automatically adjusted based on data or system errors or business events. CDP data is usually collected regularly (often scheduled) into snapshots or backups. The low level of granularity of data protection at the I / O level is lost. When a data, system, or memory failure event occurs, there is a much greater likelihood that possibly recent CDP data will be needed. Rather than allowing CDP data to be aggregated and the low level of granular recovery lost, in this embodiment the storage periods for CDP data are automatically adjusted (ie, extended) based on a rate of change target value to store that data longer. when possible recovery events are detected.

1 shows data storage and backup operations in a storage management system 110 which can be used in conjunction with an embodiment of the present invention. The storage management system 110 is used to store and manage data such as a data file 102 that comes from the client computing device 104 provided. In the storage management system, the primary data storage becomes 112 commonly used to maintain a working copy of data. Usually also a backup data storage becomes 126 used to make an extra copy of data changes from the primary data store 112 to entertain.

In the configuration off 1 represents the storage management system 110 a processing server 114 who is responsible for managing the data storage and backup operations in the system 110 is. The processing server 114 is configured for backup and data storage policies 116 to implement data storage activities in the primary data store 112 using a monitor 118 be monitored. The display 118 monitors for triggering events or schedules associated with backup activities and policies 116 , When it is determined that a backup is required, the processing server proceeds with the necessary backup activities, such as an event-based backup 122 or a time-based backup 124 so that the data in the backup data store 126 get saved.

Policies that set the sensitivity of backup operations to data modification activities can be implemented in different ways without departing from the scope of the present invention. For example, the policy may include a parameter for enabling and disabling a backup based on a rate of change destination or event. When disabled, backup operations can take place as normal time-based backups. When enabled, large volumes of changed data or a large number of I / O transactions can cause backup operations to occur alongside the normal time-based backup operations.

The policy may also include a rate of change goal based on various sources, including activity rates, amount of data, number of I / O operations performed, amount of changed metadata, or defined percentages. For example, the rate of change goal may be a percentage of the total expected amount of data to be backed up at the next scheduled backup. The expected amount of data to be backed up can be determined using any of a number of methods-for example, the total amount of data backed up for a given client using the data amount of the last full backup or the average amount of backup data over a period of time.

• • CRO_#GB_Changed_Data, definiert als ein ganzzahliger Wert. Dieser Wert stellt die aktuelle Menge geänderter Daten in Gigabytes für die aktuelle Sicherungsoperation dar.
• • CRO_#GB_Changed_Data_Threshold, definiert als ein ganzzahliger Wert. Dies ist der Schwellenwert, aufgrund dessen eine Entscheidung getroffen werden kann, eine aktuelle Sicherungsoperation fortzusetzen, einzuleiten oder abzuändern.
• • CRO_#MB_Changed_Metadata, definiert als ein ganzzahliger Wert. Dieser Wert stellt die aktuelle Menge geänderter Metadaten (z. B. Änderungen bei der Zugriffssteuerung für das Dateisystem) in Megabytes für die aktuelle Sicherungsoperation dar.
• • CRO_#MB_Changed_Metadata_Threshold, definiert als ein ganzzahliger Wert. Dies ist der Schwellenwert, aufgrund dessen eine Entscheidung getroffen werden kann, eine aktuelle Sicherungsoperation fortzusetzen, einzuleiten oder abzuändern.
• • CRO_%_of_Total_Client_Backup_Data, definiert als ein ganzzahliger (Prozent-)Wert. Dieser Wert steht für die Menge geänderter Daten bei der aktuellen Sicherungsoperation als ein Prozentanteil der Gesamtmenge der für den Client gesicherten Daten.
• • CRO_%_of_Total_Client_Backup_Data_Threshold, definiert als ein ganzzahliger (Prozent-)Wert. Dies ist der Schwellenwert, aufgrund dessen eine Entscheidung getroffen werden kann, eine aktuelle Sicherungsoperation fortzusetzen, einzuleiten oder abzuändern.

In another example, the rate of change goal may be a percentage of the total amount of data saved for a given client. The change rate target may also be a fixed one Amount of changed data (for example, the number of gigabytes of changed data). Thus, in one embodiment, a different type of rate of change target and threshold can be used for each criterion. For example, the following rate of change target values and thresholds can be used in a policy as follows:

• • CRO_ # GB_Changed_Data, defined as an integer value. This value represents the current amount of changed data in gigabytes for the current backup operation.
• • CRO_ # GB_Changed_Data_Threshold, defined as an integer value. This is the threshold against which a decision can be made to continue, initiate, or modify a current backup operation.
• • CRO_ # MB_Changed_Metadata, defined as an integer value. This value represents the current amount of changed metadata (for example, file system access control changes) in megabytes for the current backup operation.
• • CRO_ # MB_Changed_Metadata_Threshold, defined as an integer value. This is the threshold against which a decision can be made to continue, initiate, or modify a current backup operation.
• • CRO _% _ of_Total_Client_Backup_Data, defined as an integer (percent) value. This value represents the amount of changed data in the current backup operation as a percentage of the total amount of data backed up for the client.
• • CRO _% _ of_Total_Client_Backup_Data_Threshold, defined as an integer (percent) value. This is the threshold against which a decision can be made to continue, initiate, or modify a current backup operation.

In this embodiment, each rate of change target may be evaluated against its corresponding rate of change target threshold to determine whether the current backup operation should be continued or altered in any way.

Moreover, the rate of change goal may be a normalized value derived from a combination of these factors. In another embodiment, a single normalized value is used that includes one or more of the criteria. For example, the above-described rate of change target values and threshold values may be merged into a single normalized value that provides further analysis as input to the disclosed self-adjusting backup operations.

In one embodiment, CRO_ # GB_Changed_Data is shared by CRO_ # GB_Changed_Data_Threshold, CRO_ # MB_Changed_Metadata is shared by CRO_ # MB_Changed_Metadata_Threshold, and CRO _% _ of_Total_Client_Backup_Data is shared by CRO _% _ of_Total_Client_Backup_Data_Threshold, resulting in three percent change rate target percentages. The average of these three change rate target percentages gives a CRO_Normalized_Value. The CRO_Normalized_Value is then compared to a client-configured CRO_Normalized_Value_Threshold to determine if the current backup operation should continue or be modified in any way. This provides additional analysis for self-adjusting backup operations.

A hedge scenario would be conceivable in which each of the individual rate of change target values is slightly below its corresponding rate of change target threshold (eg, each could be 95% of its threshold). These individual CROs would not trigger automatic adjustments to the backup operations. However, if CRO_Normalized_Value_Threshold was set to 90%, the change activity would be sufficient in this scenario to justify some customization of the backup operations.

The rate of change target may also be determined as the number of application or I / O transactions since the last backup (eg, in one embodiment, the number of I / O operations may be tracked using a device driver implementation) in another embodiment, the application transaction counters such as the system change number may be monitored at an Oracle database and compared against the change rate target). When the rate of change goal is reached, an additional backup operation can be initiated. Another policy parameter can be used to specify whether to perform this event-based backup based on changed data in addition to or instead of the next regular time-based backup.

It is obvious that by adjusting these policy parameters, the sensitivity of backup operations can be adjusted to the data rate activity. For example, one could expect the rate of change goal to be realized as a percentage of the total amount of data backed up for a client, and that 2 to 5% of that client's data would typically change between scheduled backups. If the rate of change goal is set to 100%, will rarely, if ever, perform additional backups due to changed data. However, if the rate of change target is set to 5% or less, additional backups will occur on almost every backup cycle due to changed data. For some data store implementations, the change rate target will work most effectively when set to the value of 5 to 10%.

Two key concepts relevant to the data protection and recovery solutions disclosed herein are commonly known as Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). Recovery time goals determine how quickly a business needs to recover lost data. Recovery point goals determine when in the past a company can allow the loss of data. RTO and RPO are typically implemented as time-based goals. For example, a customer might need an RTO of 1 hour to recover and can only afford a 3-hour data loss (RPO). However, like data protection operations, time-based RPOs can be incompatible with business data activities. For example, if an RPO is 3 hours, in some cases this might be enough. However, at a time of intense system work (resulting in large amounts of data changes that need to be backed up), a 3-hour RPO can be inadequate and put a business at risk of serious data loss. A Rate of Change goal provides improvements over the use of RTO and RPO in that it allows detection of increased data modification activity or increased transaction activity, and a response thereto by increasing the frequency of backup operations.

As discussed earlier, data protection techniques in the art are generally time-scheduled and are not directly related to data activity or business events. CDP privacy is generally I / O-based (not time-based), but has disadvantages if used as the sole backup strategy. The disclosed embodiments of the present invention provide improved privacy techniques that, in addition to incorporating time-based schedules, may also be directly linked to important business events and data activity.

The data protection methods disclosed herein may therefore, in addition to time-based backup operations, enable backup operations controlled by data activity and business events. Monitors can be used to use techniques that detect these events, eventually leading to reactions to these events. For example, a monitor may be configured to detect certain business events, assess the impact of those events on privacy operations, analyze the policy associated with each event, and initiate event-driven backups as needed. These types of policy-based backup operations allow for event-based restores (such as restoring data at a point in time before a particular business event occurred).

A non-limiting list of relevant business events on which to base backup activity: business application updates; data shifts or copies, application migrations, server migrations and the like required due to technological advancements; Distributing new software, system configuration changes, disk space defragmentation processes, disk I / O errors; Events that change large records; Events that change large amounts of metadata, such as changes to data security settings, and other similar events or event triggers.

The following sections provide further details and working examples for embodiments configured to implement data rate backups using a rate of change target: (a) in conjunction with event-driven backup operations; (b) full versus incremental / differential backup scenarios; and (c) combined with improved CDP backup operations. Those skilled in the art will recognize that a number of variations of these techniques can be used and applied to a memory system, such as the combination of a rate-of-change target and event-driven backup with full or incremental backups.

Example of a data activity backup policy with rate change target values

• • Perform_Changed_Data_Backups, mit den Werten „EIN” oder „AUS”. Dieser Wert legt fest, ob geänderte Daten als ein Auslöser für zusätzliche Sicherungen verwendet werden sollen.
• • Perform_Regular_Scheduled_Backups, mit den Werten „EIN” oder „AUS”. Dieser Wert legt fest, ob reguläre geplante Sicherungen (z. B. zeitbasierte Sicherungen) in Verbindung mit Sicherungen aufgrund geänderter Daten ausgeführt werden sollen.
• • Perform_Next_Scheduled_Backup, mit den Werten „JA” oder „NEIN”. Dieser Wert legt fest, ob nach dem Ausführen einer Sicherung aufgrund geänderter Daten die nächste regulär geplante Sicherung ausgeführt werden soll.
• • Change_Rate_Objective, mit einem ganzzahligen Wert. Dieser Wert legt die geänderten Daten als einen Prozentanteil der Gesamtmenge der für einen Client gesicherten Daten oder die Anzahl der GB geänderter Daten oder die Anzahl von Transaktionen vor dem Auslösen einer zusätzlichen ereignisgesteuerten Sicherung fest. Wie hier beschrieben, kann für jedes Kriterium eine andere Art von Änderungsraten-Ziel und -Schwellenwert verwendet werden. Wie hier weiter beschrieben wird, kann dieser Wert auch normalisiert und von verschiedenen Werten oder aus einer Kombination von Quellen abgeleitet werden.

In a particular embodiment, a data activity backup policy may be defined in a software environment using a set of variable data values. These values are given as guidelines in examples in the following sections. It is obvious that the data activity backup policy in a software environment using different names or using programming language values, values in an XML data file, direct input from a user into a user interface or similar types of settings or choices can be realized. In one embodiment, these policy values may include:

• • Perform_Changed_Data_Backups, with values "ON" or "OFF". This value specifies whether changed data should be used as a trigger for additional backups.
• • Perform_Regular_Scheduled_Backups, with the values "ON" or "OFF". This value specifies whether scheduled scheduled backups (for example, time-based backups) should be performed in conjunction with backups due to changed data.
• • Perform_Next_Scheduled_Backup, with the values "YES" or "NO". This value determines whether to perform the next scheduled backup after performing a backup because of changed data.
• • Change_Rate_Objective, with an integer value. This value sets the changed data as a percentage of the total amount of data backed up for a client, or the number of GB of changed data, or the number of transactions before triggering an additional event-driven backup. As described herein, a different type of rate of change target and threshold can be used for each criterion. As further described herein, this value may also be normalized and derived from various values or from a combination of sources.

This data activity backup policy can then be applied to a storage system to perform backups and scheduled backups as triggered by the rate of change target value. The rate of change goal is generally a variable value that may be changed by a system administrator if desired. For example, a system administrator who recognizes that resource-intensive backups occur too frequently could increase the rate of change target. If the rate of change target value is based on a combination of factors, the factors may be wholly or partially assigned minimum or maximum values (eg, in one configuration, a change of 5 GB or 8% in the data store may automatically occur, depending on whether whichever comes first - a backup will be triggered).

Example of a backup policy used in conjunction with full and incremental backup procedures

• • Perform_Changed_Data_Analysis_Since_Full_Backups, ein Wert, der als entweder „AUS” oder „EIN” definiert ist und festlegt, ob seit der letzten vollständigen Sicherung geänderte Daten als ein Auslöser verwendet werden sollen, um automatisch zu steuern, ob eine vollständige oder inkrementelle Sicherung ausgeführt wird.
• • Change_Rate_Objective_For_Incremental, ein als Ganzzahl definierter Wert, der die Menge geänderter Daten als einen Prozentanteil der Gesamtmenge der seit der vollständigen Sicherung für einen Client gesicherten Daten oder die Menge geänderter Daten (z. B. die Anzahl der Gigabytes) darstellt. Wenn die Menge geänderter Daten diesen Wert unterschreitet, ist anstelle einer vollständigen Sicherung eine inkrementelle oder differenzielle Sicherung auszuführen.
• • Change_Rate_Objective_For_Full, ein als Ganzzahl definierter Wert, der die Menge geänderter Daten als einen Prozentanteil der Gesamtmenge der seit der vollständigen Sicherung für einen Client gesicherten Daten oder die Menge geänderter Daten (z. B. die Anzahl der Gigabytes) darstellt. Wenn die Menge geänderter Daten diesen Wert überschreitet, ist anstelle einer inkrementellen oder differenziellen Sicherung eine vollständige Sicherung auszuführen.
• • Full_Backups_OK, ein als ganzzahliges Array definierter Wert von Anfangs- und Endzeiten im 24-Stunden-Format, der festlegt, wann vollständige Sicherungen akzeptabel sind. Anstelle eines ganzzahligen Array können auch andere Darstellungen von Zeiträumen und -spannen verwendet werden.

When a storage system uses a full plus incremental (or full plus differential) backup approach, special policy processing and analysis is used. In conjunction with existing techniques (such as full plus differential backups), you can track the amount of data that has changed since the last full backup. This specific policy processing and analysis can be achieved by defining the following policy to monitor data activity since a last full backup:

• • Perform_Changed_Data_Analysis_Since_Full_Backups, a value defined as either "OFF" or "ON" and determines whether modified data since the last full backup should be used as a trigger to automatically control whether a full or incremental backup is being performed.
• • Change_Rate_Objective_For_Incremental, an integer value that represents the amount of changed data as a percentage of the total amount of data backed up for a client since the full backup, or the amount of changed data (for example, the number of gigabytes). If the amount of changed data falls below this value, perform an incremental or differential backup instead of a full backup.
• • Change_Rate_Objective_For_Full, an integer value that represents the amount of changed data as a percentage of the total amount of data backed up for a client since the full backup, or the amount of changed data (such as the number of gigabytes). If the amount of changed data exceeds this value, perform a full backup instead of an incremental or differential backup.
• • Full_Backups_OK, an integer-array value of start and end times in 24-hour format that determines when full backups are acceptable. Instead of an integer array, other representations of time periods and spans may be used.

2 shows an illustration of a logic flow 200 for an improved complete backup cycle according to an embodiment of the present invention. If it's like the step 202 Time to run the next full backup (usually scheduled weekly) determines the total amount of data changed since the last full backup, as in the step 204 , If the total amount of data changed since the last full backup is less than the rate set target - incremental backup policy value (Change_Rate_Objective_For_Incremental), do not perform a full backup, but perform another incremental or differential backup as in the step 206 , If the rate of change target policy value for "incremental backups" has been reached or exceeded as in the step 204 , proceed with the full backup as in the step 208 , This completes the special processing needed for the full backup cycle, as in 210 ,

3 shows an illustration of a logic flow 300 for an improved incremental or differential backup cycle according to an embodiment of the present invention. When it is time to run the next incremental or differential backup cycle (usually scheduled hourly or daily) as in the step 302 , the total amount of data changed since the last full backup is retrieved as in the step 304 , If the total amount of data changed since the last full backup is less than the rate set by the Rate-of-Change target - the "Full Backup" policy value (Change_Rate_Objective_For_Full) as in the step 304 determines an incremental or differential backup is performed as in the step 310 , If the total amount of data changed since the last full backup is greater than the full backup policy value, an additional request is executed. This additional request determines if the policy allows full backup during this period (Full_Backups_OK) as in the step 306 , If the policy allows a full backup, it will be executed as in the step 308 ; if not, an incremental or differential backup is performed as in the step 310 , This completes processing of the rate of change target for an incremental or differential backup cycle as in the step 312 ,

CDP adjustments based on events

In one embodiment, CDP techniques may be configured to automatically adjust retention periods based on data or system errors or business or data activity events. CDP operations can be enhanced through an interface and policy to expect notification of potential business recovery events. In addition, a new policy can be introduced to allow dynamic adjustment of the retention periods for CDP data.

A monitor for data or system failure, or for business events that affect CDP and backup storage operations may be used in accordance with various monitoring techniques and technologies. This monitor may be configured to detect various business failures or recovery events that may affect CDP operations. Business errors or events may include the failure of a server, disk or application or other failure in the computing environment in which the disk is located. Any such type of error or event may indicate a need to store newer CDP data of all potentially affected volumes for a longer period of time.

In one embodiment, a monitor may be configured to make an API call to an extended CDP component upon detection of an error or event for each volume or entity in which CDP is executed, which could possibly be impacted by the event sends. This indicates to the improved CDP component the need to increase the storage time for the CDP data of each of these volumes. When the event is cleared, another API call is sent to the enhanced CDP component for each volume. This indicates to the improved CDP component that the retention period extensions can be terminated and that the normal policy for storing CDP data for that volume can be followed again.

A customizable retention period may be used to control the severity of the event as determined by the monitor or monitors. The higher the severity of the event, the longer the CDP data is stored. When an event is deleted, or when the dynamically allocated retention period extension is over, the enhanced CDP component will again follow its normal policy for storing CDP data.

• • CDP_Data_Retention_API (Server-ID, Anwendungs-ID, Datenträger-ID, Zeit des Ereignisses, Schweregrad des Ereignisses, Ereigniskennung, Beendigungsstatus) und
• • Event_Clear_API (Server-ID, Anwendungs-ID, Datenträger-ID, Ereigniskennung, Beendigungsstatus).

In the specific embodiment referred to above, API calls may be defined in the CDP extended component to receive information regarding the notification of a CDP data storage event and the deletion of the event. The following are non-limiting examples of two APIs that create and delete data storage events:

• • CDP_Data_Retention_API (Server ID, Application ID, Volume ID, Event Time, Event Severity, Event ID, Termination Status) and
• • Event_Clear_API (server ID, application ID, volume ID, event ID, completion status).

The parameters used in these example APIs may be configured to receive or return the following data values: server ID - indicates the name of the server responsible for the CDP data volume; Application ID - if applicable, displays the name of the application responsible for the CDP data volume; Volume ID - indicates the unique identifier of the volume that is running CDP and that may be affected by a business failure or event; Time of the event - indicates the time of the business failure or event that might affect this volume; Severity of the event - indicates how critical the business failure or event is (this parameter is directly equivalent to the additional amount of time that CDP data is stored for that volume); Event ID - for example, a token that indicates a unique identifier for this event, and completion status - for example, a return code that indicates the completion status of this API call.

Those skilled in the art will recognize that the example APIs described above may be configured to include additional or fewer parameters depending on the configuration of the storage management system and the type of interfaces used with the storage management system. You can also use methods other than API calls to create and delete data storage events in conjunction with CDP data and rollups.

• • Dynamische Speicherung von CDP-Daten zulassen, ein entweder als „EIN” oder „AUS” definierter Wert, der anzeigt, ob die Speicherung von CDP-Daten verlängert werden kann.
• • Speicherung bei niedrigem Schweregrad, ein als Ganzzahl definierter Wert, der die Zeit darstellt, um die die Speicherung von CDP-Daten bei Ereignissen mit niedrigem Schweregrad zu verlängern ist.
• • Speicherung bei mittlerem Schweregrad, ein als Ganzzahl definierter Wert, der die Zeit darstellt, um die die Speicherung von CDP-Daten bei Ereignissen mit mittlerem Schweregrad zu verlängern ist.
• • Speicherung bei hohem Schweregrad, ein als Ganzzahl definierter Wert, der die Zeit darstellt, um die die Speicherung von CDP-Daten bei Ereignissen mit hohem Schweregrad zu verlängern ist.

In another specific embodiment, a CDP data storage policy is defined in conjunction with using a series of API calls, such as those described above. The policy can be used to display the following values that are relevant for storing CDP data:

• • Allow dynamic storage of CDP data, a value defined as either "ON" or "OFF" indicating whether the storage of CDP data can be extended.
• • Stored at low severity, an integer value that represents the amount of time that storage of CDP data should be prolonged for low-severity events.
• • Medium severity storage, a value defined as an integer, which is the amount of time that CDP data storage should be prolonged for medium severity events.
• • High-severity storage, an integer-defined value that represents the time that CDP data storage is to be extended for high-severity events.

4 shows an illustration of a logic flow 400 for improved CDP operations according to an embodiment of the present invention used to automatically adjust a storage period. As shown, the logic flow is initiated during a scheduled rollup of CDP data of a particular volume as in the step 402 , As with the step 404 a determination is made as to whether any of the events recorded on the volume require an increase in the retention period to retain CDP data that may be useful or needed after the event. If no storage period extension is required, the CDP data of the volume will be summarized as in the step 408 ,

If any events recorded on the media require an extension of the retention period as in the step 404 The event is compared to a CDP data storage policy as in the step 406 to determine how much storage of CDP data for the volume is to be extended. For example, if the severity level is low, the storage duration is equal to the storage duration value plus a low-severity storage value. If a medium severity level exists, the storage duration is equal to the storage duration value plus a middle severity storage value. If a high severity level exists, the storage duration is equal to the storage duration value plus a high severity storage value. Once either the retention period is defined or the CDP data of the volume is aggregated, the volume rollup operation is complete as in the step 410 ,

In another embodiment, the monitoring and event management techniques described herein may be used to realize privacy based on particular business events. For example, the following events may be monitored in conjunction with event management components used to initiate data protection operations for the associated data and storage. A simple policy can be introduced to control the automatic response to any type of business event.

These types of business events may include: business application updates (backups may be desirable before and after upgrades); due to technical advances required data shifts or copies, Application migrations, server migrations, and the like; System configuration changes, disk space defragmentation processes; I / O errors on data carriers; Data or system errors; changes occurring on the basis of a set of changed data, as well as events that change large amounts of metadata, such as changes in data security settings. Professionals will recognize other categories of information that may be considered a business event.

Therefore, the monitors disclosed herein may be configured to recognize certain business events, assess the impact of these events on privacy operations, analyze the policy associated with each event, and initiate event-driven backups as needed. In addition, data activity events may also occur in conjunction with a number of business events.

Other variations of the presently disclosed embodiments are possible. A system can be configured to respond only to data-related or business-related events. Other policy values may be used in conjunction with the rate of change goal or as a derived value of the rate of change goal. Similarly, other API calls, data components, and event monitoring components, as well as strategies may be used in conjunction with the presently disclosed embodiments. Additionally, the features described herein may be included in stand-alone or integrated storage management software or in components residing in or even external to a storage management system.

As those skilled in the art will also appreciate, aspects of the present invention may exist as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of a purely hardware embodiment, a pure software embodiment (including firmware, memory resident software, microcode, etc.) or that of an embodiment combining software and hardware aspects, all of which are generally referred to herein "Circuit", "module" or "system" may be designated. Aspects of the present invention may also be in the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied therein.

Any combination of one or more computer-readable media may be used. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination thereof. As more concrete examples (incomplete list) for the computer readable storage medium, the following could be listed: electrical connection with one or more wires, portable computer disk, hard disk, random access memory (RAM), read only memory (ROM) ), an erasable programmable read only memory (EPROM or flash memory), an optical fiber, a portable compact disc read only memory (CD-ROM), an optical storage unit, a magnetic storage unit or any suitable combination of this. In the context of this document, a computer-readable storage medium may be any physical medium containing a program for use by a statement-executing system, device or device, or for use in connection with a system executing instructions, such device or device can save.

A computer-readable signal medium may be, inter alia, a propagated data signal having computer-readable program code therein, for example in baseband or as part of a carrier wave. Such a propagated signal may take various forms, including, but not limited to, an electromagnetic or optical form, or any combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that communicates a program for use by a instructions executing system, apparatus, or device, or for use in connection with an instruction executing system, apparatus, or device , spread or transport.

Program code contained on a computer-readable medium may be communicated using any suitable medium, including, but not limited to, a wireless or wired medium, fiber optic cable, RF, or any suitable combination thereof. The computer program code for performing the operations of the aspects of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C ++ or the like, as well as conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code may be executed in whole or in part on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any network, including a local area network (LAN) or wide area network (WAN), or may be connected to an external computer (e.g. an Internet Service Provider over the Internet).

Aspects of the present invention have been described above with reference to flowcharts and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It is understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a special purpose computer, or other programmable data processing device for manufacturing a machine, such that the instructions executed by the processor of the computer or other programmable data processing device include means for implementing in the block or generate functions / actions specified for the blocks of the flowchart and / or block diagram.

These computer program instructions may also be stored in a computer-readable medium that may control a computer, other programmable computing device, or other devices to function in a particular manner so that the instructions stored in the computer-readable medium produce a product including the instructions. by means of which the function / action specified in the block or blocks of the flowchart and / or block diagram is realized.

The computer program instructions may also be loaded onto a computer, other programmable computing device, or other device to effect a series of operations to be performed on the computer, the other programmable device, or the other devices to provide a computer-implemented process such that the instructions provided on the computer or other programmable device, provide processes for realizing the functions / actions specified in the block or blocks of the flowchart and / or block diagram.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may include a module, segment, or portion of code that includes one or more executable instructions for implementing the specified logic function (s). It should also be noted that in some alternative implementations, the functions specified in the block may occur in a different order than indicated in the figures. For example, two consecutive blocks may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or the flowcharts and block combinations in the block diagrams and / or schedules may be implemented by specialized hardware-based systems that perform the specified functions or actions, or combinations of specialized hardware and computer instructions.

While various representative embodiments of the invention have been described above with some degree of concreteness, those skilled in the art could make numerous changes to the disclosed embodiments without departing from the scope of the inventive subject matter set forth in the specification and claims.

Claims (24)

A method of performing automatic and self-adjusting backup operations in conjunction with full, incremental, and differential backups of a data store in a storage system, the method comprising: setting a first rate of change destination and an associated first rate of change target value, wherein the first rate of change destination is Performing an advanced full backup of the datastore is used before a scheduled full backup and the first Change rate target defines a threshold for a set of changed data in the data store that requires full backup; Determining a second rate of change destination and an associated second rate of change target value, wherein the second rate of change destination is used to defer a scheduled full backup and to perform an incremental or differential backup instead of the scheduled full backup, and wherein the second rate of change target value is one defined maximum amount of modified data of the data store for an incremental or differential backup; Monitoring a set of changed data backed up since the last full backup for the data store; Performing a full backup of the data store in response to determining that the amount of changed data backed up since the last full backup during an incremental or differential backup cycle is greater than the first rate of change target value, or the amount of backup since the last full backup changed data during a full backup cycle is greater than the second rate of change target value, and performing an incremental or differential backup of the data store in response to determining that the amount of changed data backed up since the last full backup is smaller during an incremental or differential backup cycle is equal to the first rate of change target value, or that the amount of changed data saved since the last full backup is smaller during a full backup cycle or equal to the second rate of change target value. The method of claim 1, wherein the first rate of change target and the associated first rate of change target value are assessed during scheduled incremental or differential backup cycles, and wherein the second rate of change target and the associated second rate of change target value are evaluated during scheduled full backup cycles. The method of claim 1, wherein performing the full backup of the data store is also controlled in response to a policy value. The method of claim 1, wherein a plurality of scheduled full backups are defined for the data store. The method of claim 1, wherein a plurality of scheduled incremental or differential backups are defined for the data store. The method of claim 1, wherein the first rate of change target value and the second rate of change target value are each defined as a percentage of changed data in the data store. The method of claim 1, wherein the data store in the storage system comprises one or more storage volumes, and wherein the method is performed in the storage system as a result of executing a computer program product on one or more computer hardware components. A method of performing automatic and self-adjusting backup operations in a data storage system, the method comprising: Determining a rate of change destination used for event-driven backups of a data store in a storage system, the rate of change destination measuring changes in the data store that are the result of one or more data activity events; Determining a rate of change target value associated with the rate of change target, wherein the rate of change target value defines a threshold for performing backup operations of the data store; Monitoring the rate of change target in the data store by comparing the rate of change target value with the changes in the data store that are consequences of the data activity event or data activity events, and Performing the save operations in the storage system in response to the reaching or exceeding of the change rate target value, and thereby performing automatic and self-adjusting save operations in the storage system based on the change rate target. The method of claim 8, further comprising: Determining a schedule used for scheduled backups of the data store at a number of scheduled times and performing the backup operations in the storage system at each of the scheduled times; wherein the data storage timed backups and the data storage event controlled backups are respectively executed based on the time or data activity events in the storage system. The method of claim 9, wherein the scheduled backup operations of the data store are performed in coordination with event-driven backup operations performed on the storage system, including resetting, deferring or changing the scheduled backup operations. The method of claim 8, wherein the rate of change goal is determined based on a plurality of values associated with data activity events in the data store. The method of claim 8, wherein the rate of change target and the associated rate of change target value are based on one or more data activity events, including the amount of data changed since an earlier defined event, a set of metadata changed since an earlier defined event; a percentage of data that has changed since a last backup; a percentage of the total expected amount of data to be backed up on a scheduled backup; a percentage of the total amount of data backed up for a client; a fixed amount of changed data, a measure of data activity in the storage system, and a number of transactions made in the storage system. The method of claim 8, further comprising determining a data activity backup policy defining the sensitivity of backup operations against a plurality of data activity events in the storage system, the data activity backup policy determining the rate of change target value and the rate of change target. The method of claim 8, wherein a policy is used in conjunction with the event-driven backup operations, wherein the policy includes policy settings indicating whether changed data is to be used as a trigger for performing additional backups, whether regularly scheduled time-based backups are associated with event-driven backups To perform backups and whether to perform a scheduled, time-based backup after performing an event-driven backup. The method of claim 8, wherein the data store in the storage system comprises one or more storage volumes, and wherein the method is performed in the storage system as a result of executing a computer program product on one or more computer hardware components. A method for performing automatic and self-adjusting privacy for non-disruptive data storage data store operations in a storage system, comprising: Providing a policy to extend the storage of data created by the uninterruptible data protection operations, the policy setting one or more events requiring an extension of the storage period and a duration of the storage period extension based on the event or events; Triggering a data rollup for data provided by the data storage uninterruptible data protection operations; on the basis of the occurrence of the event or events, obtaining an extension of the retention period from the Directive, and Resetting the data rollup for a new retention period by extending a retention period for the data by using the retention period extension. The method of claim 16, wherein the event or events include a business event selected from the group consisting of: a business application update, a data move operation, a new software distribution, a system configuration change, a memory volume defragmentation process or multiple I / O errors, data loss, or a failure / failure of a server, volume, or application. The method of claim 16, further comprising assessing the data memory using a monitor for occurrence of the event or events requiring the extension of the storage period. The method of claim 16, wherein the storage period of the data is reduced in response to the event or events being deleted. The method of claim 16, further comprising providing a set of application programming interfaces in the storage system that are used to extend the storage period of the data by extending the storage period and clearing the event or events that cause the storage period to be extended; be used to receive calls using the application programming interfaces, extend the storage period extension, and delete the event or events that cause the retention period to be extended. The method of claim 16, further comprising evaluating the severity of the event or events, wherein the storage period of the data is adjusted according to the severity of the event or events. The method of claim 21, wherein with respect to the event or events low, medium and high severity levels and, accordingly, a small, medium and large extension of the retention period are defined. The method of claim 16, wherein the method is performed on the storage system as a result of executing a computer program product on one or more computer hardware components. A computer program stored on a computer readable medium and loadable into the internal memory of a digital computer and having software code portions when the program is executed on a computer to carry out the method of any one of claims 1 to 23.

Images