Source:Automatic Retention (EOL) Management: Difference between revisions

From SEPsesam
(Marked this version for translation)
m (implementing review feedback (KAD))
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
<noinclude>
<noinclude><div class="noprint"><languages />
<div class="noprint"><languages />
<br />


<translate>
==<translate> <!--T:67--> Overview</translate>==
<!--T:65-->
{{Copyright SEP AG|en}} </translate>


<translate><!--T:66--> {{Navigation_latest|release=[[Special:MyLanguage/SEP_sesam_Release_Versions|5.0.0 ''Jaglion'']]|link=[[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL|Managing EOL in earlier versions]]}}</translate></div><br /></noinclude>
</div></noinclude><translate><!--T:131-->
Retention time defines a specific duration (in days) for which a backup or data set is protected against deletion or overwriting. It ensures that backups are retained for a predetermined period to meet operational, regulatory, or other requirements. Once the retention time for a backup expires, it may be deleted or overwritten based on the backup retention policies in place.


<!--T:132-->
To set the retention time for backup data, SEP sesam uses the EOL attribute (End-of-Lifetime). The EOL is the expiration date of a backup or a saveset and defines the date when a backup or a saveset reaches the end of its defined retention time and can be removed or overwritten.


===<translate> <!--T:67--> Overview</translate>===
<!--T:133-->
<noinclude><div class="boilerplate metadata" id="Additional resources" style="background-color:#ecedf1; color:#8695a7; border: 1px ridge #cdd3db; margin: 0.5em; padding: 0.5em; float: right; width: 35%; "><center><b>
Retention time and EOL determine when backups can be safely removed from storage to free up space and resources. This ensures that data remains accessible for a specific period of time, and enables efficient management of storage resources by allowing the removal of backups that are no longer needed for recovery or compliance purposes.  
<translate>
<!--T:68-->
Additional resources</translate></b></center>


{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
<!--T:134-->
| rowspan="2" style="padding:0px 10px 0px;" |<translate><!--T:69--> [[File:SEP_next.png|45px|link=Special:MyLanguage/Changing_Retention_(EOL)|Changing Retention (EOL)]]</translate>
Retention time is defined on a media pool level. When a saveset is written to a medium in a specific media pool, the expiration date is calculated and set, and retention begins. For example, a media pool has retention time of 30 days. If a saveset is created and written to this pool on January 1st, its EOL is set to January 31st.
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |
To maintain consistency of the backed-up data and keep the backup chain available for restore, SEP sesam automatically manages retention and adjusts the EOL of backups and media.


<translate>
<!--T:135-->
<!--T:70-->
You can also manually adjust the EOL of your data, as described in [[Special:MyLanguage/Changing_Retention_(EOL)|Changing Retention (EOL)]].
See also: [[Special:MyLanguage/Changing_Retention_(EOL)|Changing Retention (EOL)]] – [[Special:MyLanguage/Backup_Chain_Dependencies#check|Backup Chain Dependencies]] – [[Special:MyLanguage/Backup Strategy Best Practices|Backup Strategy Best Practices]] – [[Special:MyLanguage/Tape_Management|Tape Management]] – [[Special:MyLanguage/Backup Strategy Best Practices|Backup Strategy Best Practices]]</translate>
</translate>
|}


{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
{{note|<translate><!--T:84--> Retention time and EOL refer only to backups and related migrated and replicated savesets. SEP sesam logs, readability check logs, calendar sheet entries, and restore tasks have separate retention parameters. For details, see [[Special:MyLanguage/ SEP_sesam_Glossary#retention_periods| retention periods]].</translate>}}
| rowspan="2" style="padding:0px 10px 0px;" | <translate><!--T:71--> [[File:SEP_Video.png|45px|link=Special:MyLanguage/Video Tutorials & Screencasts#installation|installation videos & screencasts]]</translate>
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |


<translate>
==={{anchor|bck_chain}}<translate><!--T:85--> Backup chain and EOL</translate>===
<!--T:72-->
Watch SEP sesam [[Special:MyLanguage/Video Tutorials & Screencasts#installation|installation videos & screencasts]].</translate>
|}


{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
<translate><!--T:136-->
| rowspan="2" style="padding:0px 10px 0px;" | [[File:SEP Tip.png|45px|link=Special:MyLanguage/FAQ|FAQ]]
For a [[Special:MyLanguage/ SEP_sesam_Glossary#backup_chain|backup chain]], SEP sesam manages the EOL values of backups according to the rules of dependency-based retention, synchronizing the EOL of interdependent savesets in the chain. This ensures that no backup is prematurely removed from the system and prevents interruption of the backup chain. Interdependent backups remain available throughout their retention time to ensure the recoverability of the entire backup chain.
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |


<translate>
<!--T:137-->
<!--T:73-->
For more information refer to [[Special:MyLanguage/Backup_Chain_Dependencies|Backup Chain Dependencies]].
Check [[Special:MyLanguage/FAQ|FAQ]] to find the answers to most common questions.</translate>
</translate>
|}


{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
==={{anchor|expired_EOL}}<translate><!--T:138--> Storage management</translate>===
| rowspan="2" style="padding:0px 10px 0px;" | <translate><!--T:74--> [[File:SEP Troubleshooting.png|45px|link=Special:MyLanguage/Troubleshooting_Guide|Troubleshooting Guide]]</translate>
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |


<translate>
<translate><!--T:139-->
<!--T:75-->
When the EOL is reached, the protection for a saveset expires. However, the storage space occupied by an expired saveset isn't immediately freed. When space is required, the savesets with the oldest EOL are deleted first. SEP sesam uses the <tt>GET_OLDEST</tt> policy to preserve data on the media for as long as possible.
Problems? See the [[Special:MyLanguage/Troubleshooting_Guide|Troubleshooting Guide]]. </translate>
|}</div></noinclude>


<!--T:140-->
To overwrite a saveset and reuse the storage space, there should be no other savesets dependent on a particular saveset. Automatic retention management tracks dependencies and synchronizes the expiration dates to prevent deletion of savesets that might be still required for restore. This condition can be bypassed by modifying the expiration date (EOL) of the backup chain manually.


<translate><!--T:76--> Data retention is the amount of time a backup is kept by SEP sesam. When you create a [[Special:MyLanguage/SEP_sesam_Glossary#media_pool|media pool]], you set the retention time for the pool. Running respective backup tasks creates a backup chain on your backup storage consisting of a [[Special:MyLanguage/SEP_sesam_Glossary#FULL|full]] backup, followed by [[Special:MyLanguage/SEP_sesam_Glossary#DIFF|differential]] and [[Special:MyLanguage/SEP_sesam_Glossary#INCR|incremental]] backups, a backup metadata file, and may also include other dependent backups, such as migrated and replicated backups. Some INCR backups use [[Special:MyLanguage/Changed_Block_Tracking_(CBT)|CBT (changed block tracking)]].</translate>
<!--T:141-->
Media can be reused when the EOL of all stored savesets expires and is not [[Special:MyLanguage/SEP_sesam_Glossary#write-protected|write-protected]] (locked).  


<!--T:142-->
SEP sesam automatically allocates the media in a media pool with the oldest expired EOL for reuse. The media that has the longest time since EOL expired is reused first.</translate>


====={{anchor|dependency-based_retention}}<translate><!--T:77--> What is retention time and EOL (End of Lifetime)</translate> =====  
==={{anchor|EOL}}<translate><!--T:143--> EOL types</translate>===


<translate>
<translate><!--T:144--> SEP sesam manages the EOL property for three main object types: savesets, backups, and tape media.</translate>
<!--T:78-->
Retention time specifies the time period for which backup data is protected after it is written to the media, so that the savesets are preserved and available for restore. Data retention is important to ensure that all regulations and retention schedules are met. How long you should retain data depends on the nature of your business, as well as regulatory, legal, and other requirements.</translate>
*<translate><!--T:79--> Retention time is set up at a media pool level and is specified in days.</translate>
*<translate><!--T:80--> The retention period starts from the date a saveset is written to the media (at the end time of the first backup) and thus defines the '''expiration date of the saveset''' – '''EOL''' (''End of Lifetime''). For example, the retention time of a media pool is 30 days and the data is backed up to the media on January 1, therefore the ''saveset EOL'' is January 31. There are three different EOL types associated with object types and also depending on the storage media used; for details, see the section [[Special:MyLanguage/5_0_0:Automatic_Retention_(EOL)_Management#EOL|EOL (retention) types]].</translate>
*<translate><!--T:81--> When the protection (EOL) expires, SEP sesam can use the media for backups again. For more details, see the section [[Special:MyLanguage/5_0_0:Automatic_Retention_(EOL)_Management#expired_EOL|What happens when retention expires]]. </translate>


<translate>
;<translate><!--T:145--> Saveset EOL: The expiration date of a single saveset. It is initially calculated by adding the backup day (the date when the data is written to the medium) and the retention time specific to the media pool.</translate>
<!--T:82-->
:<translate><!--T:146--> For example, in a media pool with 30 days retention time, a full backup is run on January 1st. EOL of this backup is set to January 31st. Five days later a differential backup is run, with EOL set to February 5th. Because differential backup depends on the preceding full backup, the EOL of the full backup is adjusted to match the EOL of the differential backup and is also set to February 5th.</translate>
SEP sesam provides automatic EOL (retention) management to ensure recoverability of the entire backup chain and protect against data loss, based on backup chain dependencies. You can also manually adjust the EOL of your data, as described in [[Special:MyLanguage/Changing_Retention_(EOL)|Changing Retention (EOL)]].</translate>


{{<translate> <!--T:83--> note</translate>|<translate> <!--T:84--> EOL (retention time) refers only to backups and related migrated and replicated savesets. SEP sesam logs, readability check logs, calendar sheet entries, and restore tasks have separate retention parameters. For details, see [[Special:MyLanguage/SEP_sesam_Glossary#retention_periods|retention periods]].</translate>}}
;<translate><!--T:147--> Backup EOL: The expiration date of all savesets belonging to the same backup, including migrated and replicated savesets.</translate>
:<translate><!--T:148--> For example, you extend the backup EOL for a saveset. The EOL is adjusted for all savesets belonging to this backup (original, migrated and replicated savesets) to match the new EOL.</translate>


{{Note|<translate><!--T:149--> By default, failed backups are also retained for the configured media pool retention time. This backup retention behavior can be changed by modifying the EOL-related keys, as described in [[Special:MyLanguage/Changing_Retention_(EOL)#EOL_keys|Customize the default retention behavior for backups and migration]]. These keys are not supported in versions prior to [[Special:MyLanguage/SEP_sesam_Release_Versions|4.4.3 ''Beefalo V2'']], where failed backups were automatically deleted after 3 days.</translate>}}


====={{anchor|bck_chain}}<translate><!--T:85--> What are backup chain dependencies </translate>=====
;<translate><!--T:150--> Media EOL: The expiration date of a tape medium, determined by the longest saveset EOL on that medium. In case an interdependent saveset exists on another medium or datastore, the media EOL (''Locked until'' attribute in tape properties) is adjusted accordingly. The tape can be reused after EOL of all savesets on tape expires (provided that the tape is not locked or write-protected). When another saveset is added to tape or EOL of an existing saveset on tape is changed, SEP sesam checks which EOL is the longest. If new EOL exceeds the current EOL of the tape, media EOL is automatically extended, otherwise it remains unchanged.</translate>
:<translate><!--T:151--> For example, a media EOL is set to February 3rd. A saveset is added to the tape with EOL set to February 25th. The media EOL is extended to February 25th. Another saveset with EOL February 20th is added to the tape, and the media EOL remains set to February 25th.</translate>


<translate>
==<translate><!--T:152--> Automatic adjustment of retention and EOL</translate>==
<!--T:86-->
A backup chain consists of [[Special:MyLanguage/SEP_sesam_Glossary#FULL|full]], [[Special:MyLanguage/SEP_sesam_Glossary#DIFF|differential]] and [[Special:MyLanguage/SEP_sesam_Glossary#INCR|incremental]] backups. Running respective backup tasks creates a backup chain on your backup storage consisting of a full backup, followed by differential and incremental backups, and, additionally, a backup metadata file. Some INCR backups use Changed Block Tracking (CBT), an incremental backup technology for virtual machines that creates faster and smaller backups.


<!--T:87-->
<translate><!--T:153-->
An FDI backup chain can contain any number of backups that each depend on other backups in the chain and can also depend on another backup in the number of backups. A backup chain can contain the first (primary) backup and one or more dependent backups, such as ''migrated'' and ''replicated'' backups.</translate>
If the retention time is considered from the perspective of an individual backup, it can ensure restorability of data only for that backup. To enable complete restore of data backed up in the backup chain, SEP sesam tracks all dependent backup savesets and manages their retention time according to their dependencies.
*<translate><!--T:88--> A primary backup can be a backup that does not require any other backups for a successful data restore. Thus, a primary backup can be a complete backup, but a dependent backup may require additional backups for a successful data restore as it may depend on the additional backups.</translate>
*<translate><!--T:89--> For example, for INCR backups all previous savesets (FULL, DIFF and INCR) must be present for a successful restore.</translate>  
*<translate><!--T:90--> If retention time is considered only from the perspective of an individual backup, it can ensure restorability of data only for that particular backup.</translate>
*<translate><!--T:91--> To enable full recovery of the data backed up in the backup chain, all dependent backup savesets are tracked and their retention time is managed according to their dependencies.</translate>


<translate>
<!--T:154-->
<!--T:92-->
Automatic adjustment of EOL follows the rules of dependency-based retention and is based on the longest EOL of interdependent savesets in a backup chain. This ensures that a backup, on which other backups depend for restore, is not removed prematurely from the system, which could potentially disrupt the backup chain. If a saveset is missing from the backup chain, data recovery to a specific point in time is not possible. SEP sesam maintains control over the dependencies among individual backup savesets and provides rules for automatic retention management based on these dependencies.
Dependent backups are also classified by the respective depth of the dependent backups in the backup chain. The respective depth can be a measure of how many backups are required to complete the restore of a system, e.g. a VM, to a predetermined state.</translate><br />
<translate>
<!--T:93-->
SEP sesam provides the '''''saveset tree view''''' to determine dependencies and EOL of an FDI backup chain. This view shows a data structure that relates savesets to their dependencies. You should use it before manually changing                                                                                                                                                                                                                                  the EOL parameter to avoid breaking the backup chain. For details, see [[Special:MyLanguage/Backup_Chain_Dependencies#check|Backup Chain Dependencies]].</translate>


<translate>
<!--T:155-->
<!--T:94-->
INCR backups require all previous savesets (FULL, DIFF and INCR) in a chain to be available for a successful restore. INCR backup taken as the third INCR after the FULL requires the FULL, the first, the second, and the third INCR to provide complete restore capability. </translate>
'''Example of a 14-day retention scenario'''</translate><br />
<translate>
<!--T:95-->
In a typical 14-day retention scenario, the first execution of the backup job creates a full backup. This is followed by differential and incremental backups. Once the 14-day retention (EOL) is reached, the savesets are marked as EOL-free and can be [[Special:MyLanguage/SEP_sesam_Glossary#purge|purged]]. If the backup data is stored on tape, its protection expires when the [[Special:MyLanguage/Tape_Management#tape_EOL|tape media EOL]] expires. For example, the backup chain has the following retention: FULL on pool MONTH (retention time:32), DIFF on pool WEEK (retention time:15), and INCR on pool DAY (retention time:7). The EOL of such an FDI chain is sufficient and no retention adjustment is required.</translate>


<translate>
===<translate><!--T:156--> Example</translate>===
<!--T:96-->
'''Automatic EOL adjustment'''</translate><br />
<translate>
<!--T:97-->
However, in some cases SEP sesam automatically adjusts the EOL to retain consistency of the backed up data and keep the backup chain readily available for restore. For example, it may happen that the expiry time of some savesets has already expired, but they have not been deleted due to one or more rules of the backup chain dependencies.


<!--T:98-->
<translate><!--T:157-->
There are six main rules that lead to an adjusted EOL.</translate>
For example, the following backup strategy is employed:
*Monthly full backup every 4th Sunday, in media pool MONTHLY with retention time 31 days
*Weekly differential backup every Sunday, in media pool WEEKLY with retention time 14 days
*Daily incremental backup, in media pool DAILY with retention time 7 days


==={{anchor|rules}}<translate><!--T:99--> Rules for the automatically adjusted retention time </translate>===
<!--T:158-->
Backup chain starts with the full backup and ends with an incremental backup. Full backup in a chain is a standalone backup and doesn’t require any other backups to successfully restore data. Therefore, the EOL of the full backup doesn’t affect any other saveset EOL.


<translate>
<!--T:159-->
<!--T:100-->
Differential backup depends on the full backup for restore. Therefore, if EOL of differential backup exceeds EOL of the full backup on which it depends, the EOL of the full backup is extended to match retention of the differential backup.
If the retention time is considered only from the perspective of an individual backup, it can ensure restorability of data only for that particular backup. To enable complete restore of data backed up in the backup chain, SEP sesam tracks all dependent backup savesets and manages their retention time according to their dependencies.  


<!--T:101-->
<!--T:160-->
For example, INCR backups require all previous savesets (FULL, DIFF and INCR) to be available for a successful restore: INCR backup taken as the third INCR after the FULL requires the FULL, the first, the second, and the third INCR to provide complete restore capability. If a saveset is missing from the backup chain, data recovery to a specific point in time is not possible. For this reason, SEP sesam maintains control over the dependencies among the individual backup savesets and provides six rules for dependency-based automatic retention.</translate>
Incremental backup requires previous savesets of all backup levels in a chain for a successful restore. INCR backup taken as the third INCR after a DIFF requires the FULL, the last DIFF, and the last three INCRs to provide complete restore capability. The EOL of incremental backups is adjusted with every new dependent incremental backup. In addition, if EOL of incremental backup exceeds EOL of the differential and full backups on which it depends, the EOL of the differential and full backups is extended accordingly.


===={{anchor|rule_1}}<translate><!--T:102--> Rule #1: Full backups do not expire as long as dependent DIFF/INCR exist </translate>====
<!--T:161-->
In case the entire backup chain is stored on tape, the media EOL matches with the longest EOL of saveset on the tape. If any of the subsequent savesets on the tape exceeds this EOL, the media EOL is adjusted accordingly.


<translate>
<!--T:162-->
<!--T:103-->
The figure below illustrates the adjustment of saveset EOLs. Only the most significant backups are filled in to retain clarity for informational purposes and to avoid cluttering the image. Note that media EOL is initially set to match the first FULL backup, and is adjusted later with the second DIFF backup to match the longest saveset EOL on the tape.
For example, you set a media pool retention parameter to 30 days and run a FULL backup. This FULL saveset is initially kept for 30 days, e.g., until January 31. If a subsequent INCR or DIFF saveset in the chain has a longer EOL, e.g. an expiration date of February 3, the EOL of all previous savesets, including the FULL, is adjusted to the longer expiration date. </translate>


===={{anchor|rule_2}}<translate><!--T:104--> Rule #2: An increased EOL of a DIFF/INCR saveset results in an increased EOL of all dependent savesets</translate>====
<!--T:163-->
[[image:EOLcalendar.png|link=]]</translate>


<translate>
=={{anchor|rules}}<translate><!--T:99--> Rules for the automatic EOL adjustment</translate>==
<!--T:105-->
If the EOL parameter of a DIFF or INCR saveset is increased, SEP sesam also increases the EOL of all dependent savesets (FULL and other DIFF and INCR). In this way, SEP sesam ensures that the EOL of the FULL saveset and other dependent DIFF and INCR is not shorter than the potentially modified EOL of the DIFF or INCR saveset. </translate>  


===={{anchor|rule_3}}<translate><!--T:106--> Rule #3: A decreased EOL of a DIFF/INCR saveset leads to reduced EOL of all dependent savesets</translate>====  
==={{anchor|rule_1}}<translate><!--T:102--> Rule #1: Full backups do not expire as long as dependent DIFF/INCR exist </translate>===  


<translate>
<translate><!--T:164-->
<!--T:107-->
Full backups will not be allowed to expire or be deleted as long as there are dependent DIFF/INCR backups that rely on them. The EOL of a full backup is extended if the EOL of subsequent backups exceeds the EOL of the full backup they depend on. If the EOL of the dependent backups is shorter, the EOL of the full backup remains unchanged.
If the EOL of a DIFF or INCR saveset is decreased, SEP sesam decreases the EOL of all dependent savesets (FULL and other DIFF and INCR).</translate> 


<!--T:165-->
For example, A full backup has EOL set to February 1st. A subsequent DIFF backup has EOL set to January 23rd. Because the DIFF backup expires before the FULL backup (EOL of the FULL is longer), the backup chain is not broken and the EOL of the FULL is not adjusted. Another subsequent DIFF backup has EOL set to February 6th. Because the FULL backup expires before the dependent DIFF (EOL of the FULL is shorter), and the backup chain could become unrestorable, the EOL of the FULL is adjusted to February 6th.</translate>


{{<translate><!--T:108--> warning</translate>|<translate><!--T:109--> If you use the ''Expire'' function to delete unneeded saveset(s) or backup set(s), SEP sesam issues a warning message, asking you to confirm your decision to expire the entire backup chain. If you allow the DIFF or INCR saveset(s) to expire, the entire backup chain will be deleted and overwritten.</translate>}}
==={{anchor|rule_2}}<translate><!--T:104--> Rule #2: An increased EOL of a DIFF/INCR saveset results in an increased EOL of all dependent savesets</translate>===


===={{anchor|rule_4}}<translate><!--T:110--> Rule #4: ''A too short EOL of DIFF/INC savesets leads to an increased EOL''</translate>====
<translate><!--T:105-->
If the EOL of a DIFF or INCR saveset is increased, SEP sesam also increases the EOL of all preceding savesets (FULL and other DIFF and INCR) on which it depends. SEP sesam ensures that EOL of the FULL saveset and other DIFF and INCR is not shorter than the potentially modified EOL of the dependent DIFF or INCR saveset.</translate>  


<translate>
==={{anchor|rule_3}}<translate><!--T:106--> Rule #3: A decreased EOL of a DIFF/INCR saveset leads to decreased EOL of all dependent savesets</translate>===
<!--T:111-->
 
<translate><!--T:107-->
If the EOL of a DIFF or INCR saveset is decreased, SEP sesam decreases the EOL of all dependent subsequent savesets (DIFF and INCR). Note that you cannot set the EOL in the past.</translate> 
 
==={{anchor|rule_4}}<translate><!--T:110--> Rule #4: A too short EOL of DIFF/INC savesets leads to an increased EOL</translate>===
 
<translate><!--T:111-->
If the DIFF/INCR backup detects that a saveset belonging to an FDI chain has an EOL that is too short, then any subsequent DIFF/INCR backup that runs on a pool with a longer retention time will increase the EOL of the saveset from that particular pool.</translate>
If the DIFF/INCR backup detects that a saveset belonging to an FDI chain has an EOL that is too short, then any subsequent DIFF/INCR backup that runs on a pool with a longer retention time will increase the EOL of the saveset from that particular pool.</translate>
{{<translate><!--T:112--> note</translate>|<translate><!--T:113--> If the EOL of a saveset belonging to an FDI chain has already expired, it will not be extended. In this case, the next DIFF/INCR backup will be executed as FULL backup.</translate>}}


===={{anchor|rule_5}}<translate><!--T:114--> Rule #5: ''A new or migrated DIFF/INC backup results in an adjusted EOL for dependent savesets''</translate>====
{{note|<translate><!--T:113--> If the EOL of a saveset belonging to an FDI chain has already expired, it will not be extended. In this case, the next DIFF/INCR backup will be executed as a FULL backup, with settings that were defined for that DIFF or INCR backup (most notably, the media pool).</translate>}}


<translate>
==={{anchor|rule_5}}<translate><!--T:114--> Rule #5: A new or migrated DIFF/INC backup leads to adjusted EOL for dependent savesets</translate>===
<!--T:115-->
When a ''new INCR or DIFF backup is run'' or an ''INCR or DIFF backup is migrated'', SEP sesam automatically adjusts the EOL of all related savesets to preserve the backup data.</translate>


===={{anchor|rule_6}}<translate><!--T:116--> Rule #6: The last successful backup or migration is automatically retained </translate>====
<translate><!--T:115-->
When a ''new INCR or DIFF backup is run'' or an ''INCR or DIFF backup is migrated'', SEP sesam automatically adjusts the EOL of all related savesets to match.</translate>


<translate>
==={{anchor|rule_6}}<translate><!--T:116--> Rule #6: The last successful backup or migration is automatically retained </translate>===
<!--T:117-->
 
<translate><!--T:117-->
SEP sesam automatically retains the last successful backup or migration saveset if the next backup/migration fails. By extending the EOL of the last successful backup/migration, SEP sesam ensures that at least one successful backup is retained. This behavior is enabled by default and can be changed by setting the values of the corresponding keys, as described in [[Special:MyLanguage/Customizing_Global_Retention_Policy|Customizing Global Retention Policy]].</translate>
SEP sesam automatically retains the last successful backup or migration saveset if the next backup/migration fails. By extending the EOL of the last successful backup/migration, SEP sesam ensures that at least one successful backup is retained. This behavior is enabled by default and can be changed by setting the values of the corresponding keys, as described in [[Special:MyLanguage/Customizing_Global_Retention_Policy|Customizing Global Retention Policy]].</translate>


{{<translate><!--T:118--> note</translate>|<translate><!--T:119--> SEP sesam also allows you to [[Special:MyLanguage/Changing_Retention_(EOL)|manually adjust EOL]] if the default retention does not meet the requirements, but you should be careful with this option. Manually adjusted EOL overrides the EOL defined by the retention time in the media pool configuration and should only be used for special cases and exceptions. Some special rules apply to the tape media EOL, see section [[Special:MyLanguage/5_0_0:Automatic_Retention_(EOL)_Management#EOL|EOL (retention) types]].</translate>}}
{{note|<translate><!--T:119--> SEP sesam also allows you to [[Special:MyLanguage/Changing_Retention_(EOL)|manually adjust EOL]] if the default retention does not meet the requirements, but you should be careful with this option. Manually adjusted EOL overrides the EOL defined by the retention time in the media pool configuration.</translate>}}
 
==={{anchor|rule_7}}<translate><!--T:166--> Rule #7: Media EOL cannot be shorter than the longest saveset EOL on that tape</translate>===
 
<translate><!--T:167-->
For tape media, SEP sesam adjusts the media EOL to match the longest EOL of the savesets stored on the tape. The media EOL and saveset EOL are interdependent and changes affect one another.


<!--T:168-->
If a saveset EOL on tape is increased or decreased, the media EOL is adjusted accordingly. Similarly, modifying media EOL impacts saveset EOL.</translate>


==={{anchor|expired_EOL}}<translate><!--T:120--> What happens when the saveset expires</translate>===


<translate>
==<translate><!--T:169--> Viewing EOL</translate>==
<!--T:121-->
The protection of a saveset expires when its EOL is reached. The storage space of an expired saveset is not used immediately; SEP sesam uses the ''GET_OLDEST'' policy to preserve the data on the media for as long as possible. The expired saveset can be used again if the following conditions are met:</translate>


*<translate><!--T:122--> As a rule, there must not be any other savesets that depend on this saveset. An expired saveset is not deleted until all sets in the backup chain that depend on it have expired and been deleted. You can override this condition by explicitly allowing the expiry date (EOL) of the entire backup chain to expire, which deletes the backup data of all related savesets.</translate>
<translate><!--T:170--> EOL for savesets and backups, and for tape media is displayed in GUI and Web UI in several views. In GUI you can also modify the EOL. </translate>


*<translate><!--T:123--> If a saveset is stored on tape, the EOL of all stored savesets must have expired.</translate>
===<translate><!--T:171--> Where in Web UI</translate>===


*<translate><!--T:124--> The media must not be ''[[Special:MyLanguage/SEP_sesam_Glossary#write-protected|write-protected]]'' (locked).</translate>
<translate><!--T:172--> In Web UI the EOL is read-only and cannot be modified.</translate>
;<translate><!--T:173--> Backup & Saveset EOL</translate>
*<translate><!--T:174--> ''Monitoring'' -> ''Last Backup State'' -> click a backup task -> task properties – ''Storage Location'' -> in the storage locations table: '''''Saveset EOL'''''</translate>
*<translate><!--T:175--> ''Monitoring'' -> ''Backups'' -> click a backup task -> task properties – ''Storage Location'' -> in the storage locations table: '''''Saveset EOL'''''</translate>
*<translate><!--T:176--> ''Infrastructure'' -> ''Data Stores'' -> click the selected data store to open the properties -> in tab ''Properties'' click ''View savesets for this data store'': columns '''''Backup EOL''''' and '''''Saveset EOL'''''</translate>
*<translate><!--T:177--> ''Infrastructure'' -> ''Tapes'' -> click the selected tape to open the properties -> in tab ''Properties'' click ''View savesets for this tape'': columns '''''Backup EOL''''' and '''''Saveset EOL'''''</translate>
;<translate><!--T:178--> Tape media EOL</translate>
:<translate><!--T:179--> ''Infrastructure'' -> ''Tapes'', column '''''Media EOL'''''</translate>


*<translate><!--T:125--> SEP sesam Server automatically allocates the media with the oldest EOL for re-use. The oldest medium is the medium with the oldest ''locked until'' (is [[Special:MyLanguage/SEP_sesam_Glossary#backup_day|backup day]]+ retention time) date in the media pool.</translate>
===<translate><!--T:180--> Where in GUI</translate>===
 
<translate><!--T:181--> You can use the GUI to modify the EOL parameter in several different ways:</translate>
;<translate><!--T:182--> Backup & Saveset EOL</translate>
*<translate><!--T:183--> ''Job State'' -> ''Backups'' -> double-click a ''backup task'' -> task properties – ''Info 1'' -> in the ''Storage location'' table: '''''Saveset EOL'''''</translate>
*<translate><!--T:184--> ''Components'' ->  ''Tapes'' ->  ''Media'' -> select the ''media'' and open properties -> ''Savesets tab'' -> columns '''''Backup EOL''''' and '''''Saveset EOL'''''</translate>
*<translate><!--T:185--> ''Components'' ->  ''Media Pools'' -> select the ''media pool'' and expand it to open media -> double-click to open the ''media properties'' -> ''Media properties – Properties 1'' -> ''tab Savesets'': columns '''''Backup EOL''''' and '''''Saveset EOL'''''</translate>
*<translate><!--T:186--> ''Components'' ->  ''Data Stores'' -> double-click the selected data store to open the properties -> ''tab Savesets'': columns '''''Backup EOL''''' and '''''Saveset EOL'''''</translate>
;<translate><!--T:187--> Tape media EOL</translate>
*<translate><!--T:188--> ''Components'' ->  ''Tapes'' ->  ''Media'' -> select one or more tapes -> right-click and select '''''Change Media EOL'''''</translate>
*<translate><!--T:189--> ''Components'' -> ''Tapes'' -> ''Media'' -> select the tape to open its properties -> '''''Locked until'''''</translate>


==={{anchor|track}}<translate><!--T:126--> Tracking the adjusted EOL </translate>===  
==={{anchor|track}}<translate><!--T:126--> Tracking the adjusted EOL </translate>===  


<translate>
<translate><!--T:190-->
<!--T:127-->
SEP sesam provides insight into how and when EOL values were modified. In Web UI, in the backup results window the ''Backup EOL'' displays EOL changes triggered manually or by automatic EOL adjustment process (in GUI this information can be found in the ''EOL changed by'' column in the ''Media'' view). Note that to display further details in the backup results window, you may have to switch to ''Advanced view'' in the Web UI.
In the ''Media'' view in the GUI, you can check the column ''Media EOL changed by'' that shows EOL-changes made via the automatic EOL adjustment by ''Backup ID/Saveset ID'', as well as the EOL that the user changed manually. The modified EOL is also recorded in the main log and can be generated for audit trail purposes, see [[Special:MyLanguage/Audit_Logging|Audit Logging]].</translate>
 
<!--T:191-->
When EOL adjustments occur automatically due to dependency-based retention or system-driven policies, this column displays the associated Backup ID or Saveset ID that initiated the adjustment, and helps you trace the specific backups or savesets responsible for the EOL change.
 
<!--T:192-->
When a user manually alters the EOL, the EOL changed by column will show the username responsible for the modification.
 
<!--T:193-->
The modified EOL is also recorded in the main log. You can generate these logs for audit and compliance purposes, providing a clear history of all EOL adjustments made (see also [[Special:MyLanguage/Audit_Logging|Audit Logging]]).</translate>


==={{anchor|EOL}}<translate> <!--T:128--> EOL (retention) types </translate>===
{{note|<translate><!--T:194--> Adjusting the Backup EOL of savesets stored on tape media may affect the Media EOL. The media EOL may also depend on the EOL of FULL/DIFF/INCR savesets stored on other media or even in datastores.</translate>}}
<translate><!--T:130--> {{EOL_Types/en}}</translate>
<noinclude>
<div class="noprint"><translate>


===See also=== <!--T:129-->
<noinclude><div class="noprint">
[[Special:MyLanguage/Changing_Retention_(EOL)|Changing Retention (EOL)]] – [[Special:MyLanguage/Backup_Chain_Dependencies#check|Backup Chain Dependencies]] – [[Special:MyLanguage/Backup Strategy Best Practices|Backup Strategy Best Practices]] – [[Special:MyLanguage/Tape_Management|Tape Management]] </translate></div></noinclude>
{{Copyright}}</div></noinclude>

Latest revision as of 12:03, 16 November 2023

Retention time defines a specific duration (in days) for which a backup or data set is protected against deletion or overwriting. It ensures that backups are retained for a predetermined period to meet operational, regulatory, or other requirements. Once the retention time for a backup expires, it may be deleted or overwritten based on the backup retention policies in place.

To set the retention time for backup data, SEP sesam uses the EOL attribute (End-of-Lifetime). The EOL is the expiration date of a backup or a saveset and defines the date when a backup or a saveset reaches the end of its defined retention time and can be removed or overwritten.

Retention time and EOL determine when backups can be safely removed from storage to free up space and resources. This ensures that data remains accessible for a specific period of time, and enables efficient management of storage resources by allowing the removal of backups that are no longer needed for recovery or compliance purposes.

Retention time is defined on a media pool level. When a saveset is written to a medium in a specific media pool, the expiration date is calculated and set, and retention begins. For example, a media pool has retention time of 30 days. If a saveset is created and written to this pool on January 1st, its EOL is set to January 31st. To maintain consistency of the backed-up data and keep the backup chain available for restore, SEP sesam automatically manages retention and adjusts the EOL of backups and media.

You can also manually adjust the EOL of your data, as described in Changing Retention (EOL).

Information sign.png Note
Retention time and EOL refer only to backups and related migrated and replicated savesets. SEP sesam logs, readability check logs, calendar sheet entries, and restore tasks have separate retention parameters. For details, see retention periods.

Backup chain and EOL

For a backup chain, SEP sesam manages the EOL values of backups according to the rules of dependency-based retention, synchronizing the EOL of interdependent savesets in the chain. This ensures that no backup is prematurely removed from the system and prevents interruption of the backup chain. Interdependent backups remain available throughout their retention time to ensure the recoverability of the entire backup chain.

For more information refer to Backup Chain Dependencies.

Storage management

When the EOL is reached, the protection for a saveset expires. However, the storage space occupied by an expired saveset isn't immediately freed. When space is required, the savesets with the oldest EOL are deleted first. SEP sesam uses the GET_OLDEST policy to preserve data on the media for as long as possible.

To overwrite a saveset and reuse the storage space, there should be no other savesets dependent on a particular saveset. Automatic retention management tracks dependencies and synchronizes the expiration dates to prevent deletion of savesets that might be still required for restore. This condition can be bypassed by modifying the expiration date (EOL) of the backup chain manually.

Media can be reused when the EOL of all stored savesets expires and is not write-protected (locked).

SEP sesam automatically allocates the media in a media pool with the oldest expired EOL for reuse. The media that has the longest time since EOL expired is reused first.

EOL types

SEP sesam manages the EOL property for three main object types: savesets, backups, and tape media.

Saveset EOL
The expiration date of a single saveset. It is initially calculated by adding the backup day (the date when the data is written to the medium) and the retention time specific to the media pool.
For example, in a media pool with 30 days retention time, a full backup is run on January 1st. EOL of this backup is set to January 31st. Five days later a differential backup is run, with EOL set to February 5th. Because differential backup depends on the preceding full backup, the EOL of the full backup is adjusted to match the EOL of the differential backup and is also set to February 5th.
Backup EOL
The expiration date of all savesets belonging to the same backup, including migrated and replicated savesets.
For example, you extend the backup EOL for a saveset. The EOL is adjusted for all savesets belonging to this backup (original, migrated and replicated savesets) to match the new EOL.
Information sign.png Note
By default, failed backups are also retained for the configured media pool retention time. This backup retention behavior can be changed by modifying the EOL-related keys, as described in Customize the default retention behavior for backups and migration. These keys are not supported in versions prior to 4.4.3 Beefalo V2, where failed backups were automatically deleted after 3 days.
Media EOL
The expiration date of a tape medium, determined by the longest saveset EOL on that medium. In case an interdependent saveset exists on another medium or datastore, the media EOL (Locked until attribute in tape properties) is adjusted accordingly. The tape can be reused after EOL of all savesets on tape expires (provided that the tape is not locked or write-protected). When another saveset is added to tape or EOL of an existing saveset on tape is changed, SEP sesam checks which EOL is the longest. If new EOL exceeds the current EOL of the tape, media EOL is automatically extended, otherwise it remains unchanged.
For example, a media EOL is set to February 3rd. A saveset is added to the tape with EOL set to February 25th. The media EOL is extended to February 25th. Another saveset with EOL February 20th is added to the tape, and the media EOL remains set to February 25th.

Automatic adjustment of retention and EOL

If the retention time is considered from the perspective of an individual backup, it can ensure restorability of data only for that backup. To enable complete restore of data backed up in the backup chain, SEP sesam tracks all dependent backup savesets and manages their retention time according to their dependencies.

Automatic adjustment of EOL follows the rules of dependency-based retention and is based on the longest EOL of interdependent savesets in a backup chain. This ensures that a backup, on which other backups depend for restore, is not removed prematurely from the system, which could potentially disrupt the backup chain. If a saveset is missing from the backup chain, data recovery to a specific point in time is not possible. SEP sesam maintains control over the dependencies among individual backup savesets and provides rules for automatic retention management based on these dependencies.

INCR backups require all previous savesets (FULL, DIFF and INCR) in a chain to be available for a successful restore. INCR backup taken as the third INCR after the FULL requires the FULL, the first, the second, and the third INCR to provide complete restore capability.

Example

For example, the following backup strategy is employed:

  • Monthly full backup every 4th Sunday, in media pool MONTHLY with retention time 31 days
  • Weekly differential backup every Sunday, in media pool WEEKLY with retention time 14 days
  • Daily incremental backup, in media pool DAILY with retention time 7 days

Backup chain starts with the full backup and ends with an incremental backup. Full backup in a chain is a standalone backup and doesn’t require any other backups to successfully restore data. Therefore, the EOL of the full backup doesn’t affect any other saveset EOL.

Differential backup depends on the full backup for restore. Therefore, if EOL of differential backup exceeds EOL of the full backup on which it depends, the EOL of the full backup is extended to match retention of the differential backup.

Incremental backup requires previous savesets of all backup levels in a chain for a successful restore. INCR backup taken as the third INCR after a DIFF requires the FULL, the last DIFF, and the last three INCRs to provide complete restore capability. The EOL of incremental backups is adjusted with every new dependent incremental backup. In addition, if EOL of incremental backup exceeds EOL of the differential and full backups on which it depends, the EOL of the differential and full backups is extended accordingly.

In case the entire backup chain is stored on tape, the media EOL matches with the longest EOL of saveset on the tape. If any of the subsequent savesets on the tape exceeds this EOL, the media EOL is adjusted accordingly.

The figure below illustrates the adjustment of saveset EOLs. Only the most significant backups are filled in to retain clarity for informational purposes and to avoid cluttering the image. Note that media EOL is initially set to match the first FULL backup, and is adjusted later with the second DIFF backup to match the longest saveset EOL on the tape.

EOLcalendar.png

Rules for the automatic EOL adjustment

Rule #1: Full backups do not expire as long as dependent DIFF/INCR exist

Full backups will not be allowed to expire or be deleted as long as there are dependent DIFF/INCR backups that rely on them. The EOL of a full backup is extended if the EOL of subsequent backups exceeds the EOL of the full backup they depend on. If the EOL of the dependent backups is shorter, the EOL of the full backup remains unchanged.

For example, A full backup has EOL set to February 1st. A subsequent DIFF backup has EOL set to January 23rd. Because the DIFF backup expires before the FULL backup (EOL of the FULL is longer), the backup chain is not broken and the EOL of the FULL is not adjusted. Another subsequent DIFF backup has EOL set to February 6th. Because the FULL backup expires before the dependent DIFF (EOL of the FULL is shorter), and the backup chain could become unrestorable, the EOL of the FULL is adjusted to February 6th.

Rule #2: An increased EOL of a DIFF/INCR saveset results in an increased EOL of all dependent savesets

If the EOL of a DIFF or INCR saveset is increased, SEP sesam also increases the EOL of all preceding savesets (FULL and other DIFF and INCR) on which it depends. SEP sesam ensures that EOL of the FULL saveset and other DIFF and INCR is not shorter than the potentially modified EOL of the dependent DIFF or INCR saveset.

Rule #3: A decreased EOL of a DIFF/INCR saveset leads to decreased EOL of all dependent savesets

If the EOL of a DIFF or INCR saveset is decreased, SEP sesam decreases the EOL of all dependent subsequent savesets (DIFF and INCR). Note that you cannot set the EOL in the past.

Rule #4: A too short EOL of DIFF/INC savesets leads to an increased EOL

If the DIFF/INCR backup detects that a saveset belonging to an FDI chain has an EOL that is too short, then any subsequent DIFF/INCR backup that runs on a pool with a longer retention time will increase the EOL of the saveset from that particular pool.

Information sign.png Note
If the EOL of a saveset belonging to an FDI chain has already expired, it will not be extended. In this case, the next DIFF/INCR backup will be executed as a FULL backup, with settings that were defined for that DIFF or INCR backup (most notably, the media pool).

Rule #5: A new or migrated DIFF/INC backup leads to adjusted EOL for dependent savesets

When a new INCR or DIFF backup is run or an INCR or DIFF backup is migrated, SEP sesam automatically adjusts the EOL of all related savesets to match.

Rule #6: The last successful backup or migration is automatically retained

SEP sesam automatically retains the last successful backup or migration saveset if the next backup/migration fails. By extending the EOL of the last successful backup/migration, SEP sesam ensures that at least one successful backup is retained. This behavior is enabled by default and can be changed by setting the values of the corresponding keys, as described in Customizing Global Retention Policy.

Information sign.png Note
SEP sesam also allows you to manually adjust EOL if the default retention does not meet the requirements, but you should be careful with this option. Manually adjusted EOL overrides the EOL defined by the retention time in the media pool configuration.

Rule #7: Media EOL cannot be shorter than the longest saveset EOL on that tape

For tape media, SEP sesam adjusts the media EOL to match the longest EOL of the savesets stored on the tape. The media EOL and saveset EOL are interdependent and changes affect one another.

If a saveset EOL on tape is increased or decreased, the media EOL is adjusted accordingly. Similarly, modifying media EOL impacts saveset EOL.


Viewing EOL

EOL for savesets and backups, and for tape media is displayed in GUI and Web UI in several views. In GUI you can also modify the EOL.

Where in Web UI

In Web UI the EOL is read-only and cannot be modified.

Backup & Saveset EOL
  • Monitoring -> Last Backup State -> click a backup task -> task properties – Storage Location -> in the storage locations table: Saveset EOL
  • Monitoring -> Backups -> click a backup task -> task properties – Storage Location -> in the storage locations table: Saveset EOL
  • Infrastructure -> Data Stores -> click the selected data store to open the properties -> in tab Properties click View savesets for this data store: columns Backup EOL and Saveset EOL
  • Infrastructure -> Tapes -> click the selected tape to open the properties -> in tab Properties click View savesets for this tape: columns Backup EOL and Saveset EOL
Tape media EOL
Infrastructure -> Tapes, column Media EOL

Where in GUI

You can use the GUI to modify the EOL parameter in several different ways:

Backup & Saveset EOL
  • Job State -> Backups -> double-click a backup task -> task properties – Info 1 -> in the Storage location table: Saveset EOL
  • Components -> Tapes -> Media -> select the media and open properties -> Savesets tab -> columns Backup EOL and Saveset EOL
  • Components -> Media Pools -> select the media pool and expand it to open media -> double-click to open the media properties -> Media properties – Properties 1 -> tab Savesets: columns Backup EOL and Saveset EOL
  • Components -> Data Stores -> double-click the selected data store to open the properties -> tab Savesets: columns Backup EOL and Saveset EOL
Tape media EOL
  • Components -> Tapes -> Media -> select one or more tapes -> right-click and select Change Media EOL
  • Components -> Tapes -> Media -> select the tape to open its properties -> Locked until

Tracking the adjusted EOL

SEP sesam provides insight into how and when EOL values were modified. In Web UI, in the backup results window the Backup EOL displays EOL changes triggered manually or by automatic EOL adjustment process (in GUI this information can be found in the EOL changed by column in the Media view). Note that to display further details in the backup results window, you may have to switch to Advanced view in the Web UI.

When EOL adjustments occur automatically due to dependency-based retention or system-driven policies, this column displays the associated Backup ID or Saveset ID that initiated the adjustment, and helps you trace the specific backups or savesets responsible for the EOL change.

When a user manually alters the EOL, the EOL changed by column will show the username responsible for the modification.

The modified EOL is also recorded in the main log. You can generate these logs for audit and compliance purposes, providing a clear history of all EOL adjustments made (see also Audit Logging).

Information sign.png Note
Adjusting the Backup EOL of savesets stored on tape media may affect the Media EOL. The media EOL may also depend on the EOL of FULL/DIFF/INCR savesets stored on other media or even in datastores.
Copyright © SEP AG 1999-2024. All rights reserved.
Any form of reproduction of the contents or parts of this manual is allowed only with the express written permission from SEP AG. When compiling and designing user documentation SEP AG uses great diligence and attempts to deliver accurate and correct information. However, SEP AG cannot issue a guarantee for the contents of this manual.