Topics | Advanced Backup Options | Support | Related Topics
When Does the Data get Backed Up
How Long is the Backup Data Retained
Agent-Specific Backup Overviews
The primary purpose of a backup is to secure your data to media, for recovery at a later time. Review the topics discussed below to understand the scope of backup operations.
The data that will be backed up is determined first by the agent, which is designed to handle one or more types of data. Then, the subclient content configuration determines what specific data of the supported data type(s) will be backed up.
Each agent is designed to back up one or more specific data types. For example, to secure Windows File System data you would use the Windows File System iDataAgent . To find out what data types an agent is tailored to secure, read the Product Overview for the agent. Some agents may overlap in what data types they can secure, and you should plan your backups accordingly.
Subclient content will determine what gets backed up by the Agent. If an agent is designed to backup Windows File System data, for example, the data you want to backup must be included the contents of a subclient. Subclients provide a flexible way of managing what gets backed up. See Subclients for information on subclients and assigning content to subclients.
For agents that support On Demand Data Protection operations, the content is specified via Content Files (in some cases in conjunction with a Directive File) instead of through a Subclient Properties (Content) tab. See Defining Content for On Demand Data Protection Operations for more information.
You may want to exclude files or subdirectories that are contained within a subclient content path from data protection operations. This is useful to prevent the system from needlessly securing data that does not need to be protected. Also, you can prevent the same data from being secured multiple times in cases where two agents are securing the same data, by excluding the data from operations on one of the agents. See Excluding Data from Data Protection Operations for information on methods of excluding data from data protection operations.
The software allows you to schedule or initiate backups at the subclient, instance and/or backup set level, depending upon the agent. Scheduled data protection operations provide a convenient means of securing data without user intervention. When scheduling data protection operations, you need to establish a schedule for each subclient. For example, a backup schedule always contains a full backup and may contain one or more other backup operations. When combined for a given subclient, these backups comprise a full backup cycle.
You can also schedule data protection operations using a Agent Specific Data Protection Schedule Policy or an All Agent Types Data Protection Schedule Policy.
Almost all operations can either be scheduled, or performed immediately.
Backup jobs using the Run Immediately option allow you to secure data immediately without having to wait for the scheduled backup time. This capability can be useful if:
Each subclient is associated to a storage policy. How long the backup data will be retained on the backup media is determined by the retention rules set in the Storage Policy Copy Properties dialog box. This will affect media usage, and is an important consideration when planning your backups. A longer retention period, for example, could use more media for securing the data over time.
If a retention period other than infinite is selected, the data will be pruned according to backup cycles in relation to the retention rules you set in the Storage Policy Copy Properties dialog box. Pruned data can be overwritten on the backup media.
The backup data from a subclient will be retained according to the rules set for the storage policy associated with it. The ability to define data in subclients, and then associate them to specific storage policies allows you to prioritize exactly what data is retained and for how long.
For example, a client is being backed up with the Windows File System iDataAgent using the default subclient (which backs up the entire file system). It is associated to a storage policy that regularly ages the data. There is a critical folder on that client that you would like retained longer than the rest of the file system. You could create a new subclient with that critical folder as its content, and associate the new subclient with a storage policy that has the desired retention period.
See Data Aging for detailed information and advanced concepts on Data Aging and retention.
See Subclients for information on assigning a storage policy to a subclient.
See the following for detailed information on each of the common backup types:
Not all agents support all of the common backup types. See Backup Options - Support for a list of supported backup types for each agent.
In addition to the common backup types listed above, each agent may support additional backup types. For more information on backups for a specific agent, see the Agent-Specific Backup Overview.
In addition the following backup types are also supported.
The SnapProtect Backup enables you to create a point-in-time snapshot of the data to be used for various data protection operations. SnapProtect backup works in conjunction with hardware snapshot engines to provide snapshot functionality for data protection operations. An effective way to backup live data is to temporarily quiesce it, take a snapshot, and then resume live operations.
For more information, see SnapProtect Backup.
All information for the CommCell is stored in a SQL database and the Windows registries on the CommServe. It is critical to be able to retrieve this information in the case of a disaster or system failure, and thus critical that this data be backed up. For more information and procedures, see Disaster Recovery Backup.
In some cases, the system will automatically run a job as a full backup to ensure the integrity of your data, even if you have selected a non-full backup option. An unplanned full backup could have the following effects:
Therefore, conversions to full should be considered when planning your backups. You can avoid, or plan for these situations by familiarizing yourself with the general circumstances, and the circumstances for each agent in which an operation is converted to full.
See When a Non-Full Backup is Automatically Converted to a Full Backup for detailed information.
The backup scheme for a given subclient can employ more than one type of backup. Often you will use either full backups and incremental backups or full backups and differential backups, depending on your data security needs and preferences. Full backups always back up all the data that is assigned to a given subclient. While full backups are necessary (to establish a backup baseline), they are the least efficient form of backup because they back up all data and therefore take the longest time to complete. Incremental backups generally back up the least amount of data thereby making them the most efficient form of backup. Differential backups, on average, are somewhere between the two. They tend to back up more data than an incremental, but less than a full backup.
Incremental backups are more efficient than differentials from a backup perspective. However, differential backups can increase restore efficiency. Each time a backup occurs, the data is written to an archive file on the backup media. This topic is discussed in Backup Series within Removable Media Groups. Since each incremental backup produces an archive file, the backup data for a given subclient tends to be distributed among different archive files. In differential backups, however, all the changed data resides in one (i.e., the latest) archive file. From a restore perspective, this storage protocol can be important, particularly if you want to restore the latest version of a large amount of data.
To understand this observation better, we will compare the backup examples in Incremental Backups on and Differential Backups. These examples show how the two backup types back up the same file system with the same file modifications. The examples reveal that the incremental backup data is distributed among more archive files than the differential backup data. Consider user files A, C, and D. The latest versions of these files reside in three incremental backup archive files (i.e., one archive file per backup). The same user files are consolidated into one (i.e., the latest) differential backup archive file. This is a clear advantage from a restore point of view since in order to restore the entire file system to its most recent state, the software needs to reference only two archive files: the one produced by the most recent differential backup (i.e., n-1) and the one produced by the preceding full backup (i.e., 1). To restore the same data from the incremental backups, the system would need to reference four archive files: those produced by backups n-1, 4, 3, and 1. This introduces additional latency because the system must actively seek for each required archive file.
Note that from a restore perspective, full backups provide the most efficiency since all data is always in only one archive file. But, because of the load that full backups place on system resources, it is impractical to use them exclusively. Another means of enhancing restore efficiency involves the use of a different kind of backup; a synthetic full backup.
When using any of the Exchange Database iDataAgents, you may choose either full backups and incremental backups, or full backups and differential backups, depending on your data security needs and preferences, but you cannot mix types. If it is more productive to switch to the opposite methodology, a full backup is forced. Any existing backups from the previous methodology can not be restored.
Incremental and differential backups each have their own advantages. Compared to differentials, incremental backups:
Compared to incrementals, differential backups:
Note that differential backups are cumulative and get larger in succession as additional files change over time. This can introduce problems in the backup strategy of subclients where the proportion of data that changes is high. Under these conditions, the size of the differential backup can rapidly approach the size of a full backup. In such cases, you may want to revisit your backup strategy and run full backups more frequently.
In general, the case for using differential backups tends to become stronger if you run few full backups relative to the total number of backups run for a given subclient. If, however, you run full backups fairly frequently relative to the total number of backups for a given subclient, then the need for differential backups becomes less compelling. Keep in mind that these are merely general guidelines. Your own requirements with regard to backup and restore efficiency should dictate the most suitable backup regimen.
For some subclients, there may be no clear advantage to using only one of these backup types. For example, you may have a subclient that requires a lengthy full backup cycle (e.g., one full backup per month) yet needs to be backed up frequently (e.g., every day). To improve backup performance, you would back up the subclient using incrementals; however, doing so would cause the restore performance to suffer. To mitigate the opposing effects of employing either backup type alone, the system allows you to use both types of backups for a given subclient. In this example, you could run incremental backups daily (e.g., Monday through Saturday), but run a differential backup once a week (e.g., Sunday). Doing so would limit the restore operation to at most eight archive files compared with approximately 30 files if only incrementals were run.
| For the Lotus Notes Database iDataAgent, running an incremental backup allows you to update an existing subclient with new databases (discover) without having to run a full backup on the entire subclient. |
Using a balanced combination of full, differential, and transaction log backups can provide your enterprise with the proper level of recovery ability, while balancing system and operation window resources. Adding File and File Group backups to the mix provides the ability to back up the database in a more granular way. Using VSS backups disables all other backup types.
Running only full backups can be useful for smaller, more static databases, but for larger, more robust databases, running only full backups can be overly time- and media-consuming.
Running differential backups in addition to full backups can help to greatly reduce the time and media required to secure the database. Additionally, differential backups are cumulative, so they allow for relatively quick restores. However, restores using differential backups lack the ability to restore any given point in time.
Transaction log backups allow you to perform a restore to any given point in time which may be critical when it is necessary to restore a database to the moment before failure. However, when performing restores that predominantly use transaction log backups, the restore job can take much longer, because each log must be applied in succession.
A File or File group backup is a backup which contains only a selected portion of the database. Using file/ file group backups you can better manage large databases that contain tables that are more dynamic than others. Keep in mind that file and file group backups add an increased level of administration to maintain. For more information regarding their proper usage, consult the Microsoft SQL Server documentation.
It is recommended that you select the file group, as opposed to individual files, as the content for a user-defined subclient. Selecting subclient content at the file level will require you to remember and make manual additions of files which are later added to this file group in the database.
The key to establishing an effective combination of the above backup types is understanding the needs of the databases being backed up and generating an appropriate backup plan:
In addition, the way in which the database tables are modified can also affect your backup plan:
A typical scenario of a combination of full, differential, and transaction log backups will give a better idea of how this works.
This scenario allows you to minimize the number of media necessary to perform a restore compared to using only a full backup cycle and transaction logs. Since a differential backup will pickup all changes since the last full backup, the earlier transaction log information becomes redundant. The earlier transaction logs won’t be necessary for a restore to a time that occurs after the differential backup.
Differential and transaction log backups each have their own advantages. Compared to differentials, transaction log backups:
Compared to transaction log backups, differential backups:
Note that differential backups are cumulative and get larger in succession as additional records change over time. This can introduce problems in the backup strategy of subclients where the proportion of data that changes is high. Under these conditions, the size of the differential backup can rapidly approach the size of a full backup. In such cases, you may want to revisit your backup strategy and run full backups more frequently or use transaction log backups to cover a longer period of time.
In general, the case for using differential backups tends to become stronger if you run few full backups relative to the total number of backups run for a given subclient. If, however, you run full backups fairly frequently relative to the total number of backups for a given subclient, then the need for differential backups becomes less compelling. Keep in mind that these are merely general guidelines. Your own requirements with regard to back up and restore efficiency should dictate the most suitable backup regimen.
Given below is a list of supported Agents. The corresponding linked page provides information on the Agent specific backup options and procedures.
|
Active Directory
Documentum External Data Connector
Microsoft Exchange Server Microsoft Windows File Systems NAS |
Unix File System Virtual Server |
The Backup Job Summary Report provides a summary of backup jobs for each client.
The Calendar Backup Job Summary Report provides a total amount of backup jobs run (along with their job status) for a specified time period.