5 1 0:Backup Chain Dependencies
Overview
|
Visit SEP sesam YouTube Channel for latest videos and webinars. |
|
Check FAQ to find the answers to most common questions. |
|
Problems? See the Troubleshooting Guide. |
|
If you are using an older SEP sesam version, refer to Documentation archive. |
A backup chain in SEP sesam consists of full, differential and incremental backups, organized in a sequential order. A backup chain begins with a full backup, which captures a complete copy of the specified data at a specific point in time. The full backup serves as the starting point for subsequent backups in the chain. Following the full backup, differential and incremental backups are performed to capture changes made to the data since the last backup in the chain.
Each backup in the chain generates a saveset containing the backed-up data. Additionally, backups can be migrated and replicated, creating additional copies of the savesets.
During restore, SEP sesam reconstructs the data by utilizing the appropriate backups in the chain. It starts from the full backup and applies the necessary differential and incremental backups to restore to a specific point in time.
A backup chain, consisting of full and subsequent differential and incremental backups, is treated as a single backup entity and simplifies backup management and retention. Backup chains optimize storage efficiency by storing only changes made since the last backup, minimizing data transmission and storage. However, long backup chains can be inefficient and more vulnerable to errors because backups within the chain are interdependent. This can lead to challenges during restore operations, including insufficient storage availability and extended restore times.
|
Note |
| In SEP sesam, there are no limitations on the number of backups within a backup chain. To mitigate potential problems that may arise from long backup chains, SEP AG strongly recommends implementing periodic full backups and setting a cap of around 100 incremental backups. |
What are backup chain dependencies
Backup chains are sequences of backups that follow a specific order and dependency structure. These chains consist of primary and dependent backups. In SEP sesam, the following terms can be used to describe backup relationships and their dependencies:
- Primary backup is a standalone backup that doesn’t require any other backups to successfully restore data.
- Dependent backup requires other backups for a successful data restore. It depends on preceding backups, such as full, differential, or incremental backups, to restore the data.
A primary backup is a full backup, which captures an entire dataset, while dependent backups, such as incremental backups, rely on the presence of other backups to complete the restore process. In the case of incremental backups, for instance, all preceding savesets (including full and differential backups) are required for a successful restore.
Respective depth of a dependent backup in a backup chain indicates how many preceding backups are necessary to successfully restore a particular backup in the chain. The respective depth defines the backup's position in the chain.
For example, in a backup chain that starts with a full backup, followed by five incremental backups, then a differential backup is performed, followed by another set of five incremental backups. The respective depth of the first incremental backup is 1, as it only depends on the full backup for restore. For each subsequent incremental backup, its respective depth is increased by 1, as each requires the full and all preceding incremental backups for restore. The fourth incremental backup holds a respective depth of 4. The differential backup resets the respective depth to 1, as it only depends on the full backup for restore. The next incremental backup requires the full backup and the preceding differential backup, which increases its respective depth to 2. Similarly, the respective depth of the fourth incremental backup following the differential is 5.
Backup chain EOL
To ensure the recoverability of an entire backup chain, retention management tracks dependent backups and adjusts the EOL so that the savesets are preserved and available for restore. Retention time defines how long a backup is protected in the system before it can be deleted. For a backup chain, EOL follows the rules of dependency-based retention and is based on the longest EOL of interdependent savesets in the chain. This ensures that no backup is removed prematurely from the system, which could potentially disrupt the backup chain, and guarantees that interdependent backups remain available throughout their retention period.
For more information on retention management and rules for adjusting the EOL of a backup chain see Automatic Retention (EOL) Management
Saveset tree
In SEP sesam GUI, a saveset tree view provides detailed information about savesets in a backup chain. This view displays information about the current saveset and any preceding savesets in the same backup chain upon which the current saveset depends.
For primary or independent backups, the saveset tree view shows recoverability information for the individual saveset. For dependent backups, the view shows details not only for the current saveset but also for other savesets in the backup chain that are required to successfully restore the current saveset.
The details presented in a saveset tree view are read-only and offer insights into the recoverability status of the backups. This overview can be used for assessing dependencies and determining the EOL of an FDI backup chain before making any manual adjustments to the EOL, which could potentially disrupt the integrity of the backup chain.
The saveset tree summary provides insights into the location and status of savesets in a backup chain for restore. For example, availability 5 indicates that not all savesets are immediately accessible and should be migrated to ensure they can be mounted and selective restore can be performed.
Checking the dependencies of the saveset tree
To open the saveset tree in Web UI, perform the following steps:
- In navigation menu click Monitoring and then Last Backup State or Backups to open the list of backup results.
- Click the backup task name of the selected backup result in the list to open the backup result properties window.
- In the backup result properties window, click Dependencies.
One of the displayed details in the saveset tree view is Priority, which indicates the location and accessibility of the saveset. Priority is denoted numerically, where 1 represents the lowest priority (least accessible for restore) and 6 (or 7, if associated with a specific pool) represents the highest priority (immediately available for restore).
For example, a saveset initially resides in the media pool DAY on a data store and is assigned priority of 7. Subsequently, this saveset is migrated to another pool named DeDup on a data store, and its priority there is lowered to 6. Then the saveset is further migrated to a tape for long-term storage and the priority of this saveset copy is lowered to 1. This indicates that the saveset is not immediately accessible for restore, as tapes require additional retrieval and processing steps before their contents can be restored.
Furthermore, the priority information of savesets in the chain defines the overall availability in the status summary of the backup chain. Backup chain is assigned the lowest availability status (priority) of all displayed savesets within the backup chain that are required to perform restore. If there is more that one saveset available for a backup, the one with the highest priority (most readily available for restore) is used for restore.
See also
Automatic Retention (EOL) Management – Changing Retention (EOL) – Backup Strategy Best Practices – Deleting backups - Tape Management