Difference between revisions of "4 4 3 Beefalo:Managing EOL"

From SEPsesam
Jump to: navigation, search
(Update.)
(Updated and checked.)
Line 139: Line 139:
  
 
<!--T:46-->
 
<!--T:46-->
If EOL of a DIFF or INCR saveset is decreased to a point in time in the past, SEP sesam will issue a warning message, prompting you to confirm your decision to set the whole backup chain to already passed time.  
+
If EOL of a DIFF or INCR saveset is decreased, SEP sesam will decrease EOL of all dependent backups (FULL and other DIFF and INCR). If you use the ''Expire'' function to delete the unneeded saveset(s) or backup set(s), SEP sesam will issue a warning message, prompting you to confirm your decision to expire the entire backup chain.
{{warning|Setting the expired EOL for DIFF or INCR savesets results in purging and overwriting the complete backup chain!}}
+
{{warning|Expiring the DIFF or INCR saveset(s) results in purging and overwriting the complete backup chain!}}
  
 
===={{anchor|chain_increased_EOL}}Too short EOL of DIFF/INC savesets ==== <!--T:47-->  
 
===={{anchor|chain_increased_EOL}}Too short EOL of DIFF/INC savesets ==== <!--T:47-->  
  
 
<!--T:48-->
 
<!--T:48-->
If DIFF/INCR backup detects that a saveset belonging to a FDI chain has too short EOL then any consecutive DIFF/INCR backup that is running on a pool with longer EOL will increase the EOL of the saveset from the respective pool.</translate>
+
If DIFF/INCR backup detects that a saveset belonging to a FDI chain has too short EOL, then any consecutive DIFF/INCR backup that is running on a pool with longer EOL will increase the EOL of the saveset from the respective pool.</translate>
 
   
 
   
{{<translate><!--T:49--> note</translate>|<translate><!--T:50--> If EOL of a saveset belonging to a FDI chain is already expired, it will not be extended. In this case, the DIFF/INCR backup will be executed as FULL backup.</translate>}}
+
{{<translate><!--T:49--> note</translate>|<translate><!--T:50--> If EOL of a saveset belonging to a FDI chain has already expired, it will not be extended. In this case, the DIFF/INCR backup will be executed as a FULL backup.</translate>}}
 
;<translate><!--T:51-->
 
;<translate><!--T:51-->
 
''Example'': The backup chain has the following retention specified: FULL on pool MONTH (EOL:32), DIFF on pool WEEK (EOL:15) and INCR on pool DAY (EOL:7). EOL of such FDI chain is sufficient, therefore EOL is not modified.
 
''Example'': The backup chain has the following retention specified: FULL on pool MONTH (EOL:32), DIFF on pool WEEK (EOL:15) and INCR on pool DAY (EOL:7). EOL of such FDI chain is sufficient, therefore EOL is not modified.
Line 158: Line 158:
 
<ul><li><translate> <!--T:54--> You can enable extended retention period for migration by using a specific GLBV:</translate>  
 
<ul><li><translate> <!--T:54--> You can enable extended retention period for migration by using a specific GLBV:</translate>  
 
  <tt>'gv_adjust_eol_migration_increases_eol_on_other_pool'</tt>.</li>
 
  <tt>'gv_adjust_eol_migration_increases_eol_on_other_pool'</tt>.</li>
<li><translate><!--T:55--> You can enable migration to increase EOL of the referenced savesets on other media pools (not only on the target media pool) by adding (or modifying) the following key to global settings in GUI:</translate>
+
<li><translate><!--T:55--> You can enable migration to increase EOL of the referenced savesets on other media pools (not only on the target media pool) by adding (or modifying) the following key in global settings in GUI:</translate>
 
<ol><li><translate><!--T:56--> In the menu bar, click ''Configuration'' -> ''Defaults'' -> ''Settings''.</translate></li>
 
<ol><li><translate><!--T:56--> In the menu bar, click ''Configuration'' -> ''Defaults'' -> ''Settings''.</translate></li>
 
<li><translate> <!--T:57--> Click [+] to add the following key to global settings (or modify the key value, if it already exists): <tt>eol_adjust_migration_on_other_pool|1|sesam</tt><br /> where ''value=1'' means that the key is active and ''sesam'' is the user name. For more details about retention-related keys, see section [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#keys|Customizing retention policy]].</translate></li>
 
<li><translate> <!--T:57--> Click [+] to add the following key to global settings (or modify the key value, if it already exists): <tt>eol_adjust_migration_on_other_pool|1|sesam</tt><br /> where ''value=1'' means that the key is active and ''sesam'' is the user name. For more details about retention-related keys, see section [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#keys|Customizing retention policy]].</translate></li>
Line 176: Line 176:
  
 
<!--T:63-->
 
<!--T:63-->
;''Example'': COPY backup in pool MONTH (EOL: 32) fails. SEP sesam checks for previous successful COPY backup in the same pool and increases its EOL unless the backup EOL is not sufficient, e.g., a migrated saveset exists in pool YEAR (EOL: 375).  
+
;''Example'': COPY backup in pool MONTH (EOL: 32) fails. SEP sesam checks for previous successful COPY backup in the same pool and increases its EOL, unless the backup EOL is not sufficient, e.g., a migrated saveset exists in the pool YEAR (EOL: 375).  
  
 
====FULL/DIFF/INCR backup fails==== <!--T:64-->  
 
====FULL/DIFF/INCR backup fails==== <!--T:64-->  
Line 184: Line 184:
  
 
<!--T:66-->
 
<!--T:66-->
;''Example'': FULL backup in pool MONTH (EOL: 32) fails. SEP sesam checks for previous ''successful'' or ''with warnings'' FDI backup chain in the same pool and increases the EOL of the whole chain (FULL/DIFF/INCR backups) unless the backup EOL is not sufficient, e.g., a migrated FULL saveset already exists in pool YEAR (EOL: 375).
+
;''Example'': FULL backup in the pool MONTH (EOL: 32) fails. SEP sesam checks for previous ''successful'' or ''with warnings'' FDI backup chain in the same pool and increases the EOL of the entire chain (FULL/DIFF/INCR backups), unless the backup EOL is not sufficient, e.g., a migrated FULL saveset already exists in the pool YEAR (EOL: 375).
  
 
=={{anchor|manual_EOL}}Manual EOL adjustment== <!--T:67--> </translate>
 
=={{anchor|manual_EOL}}Manual EOL adjustment== <!--T:67--> </translate>
Line 190: Line 190:
 
<translate>
 
<translate>
 
<!--T:70-->
 
<!--T:70-->
It is not recommended to manually adjust EOL. This will override the EOL that was defined by the retention time (in days) in media pool configuration and started on the date when a saveset is being written to the media. The following options should be used for special cases and exceptions, for example, to allow premature deletion of an individual saveset or to increase the retention time of a particular backup chain to be stored longer than specified by current EOL.
+
It is not recommended to manually adjust EOL. This will override the EOL that was defined by the retention time (in days) in the media pool configuration and was started on the date when a saveset is being written to the media. The following options should be used for special cases and exceptions, for example, to allow premature deletion of an individual saveset or to increase the retention time of a particular backup chain that is to be stored longer than specified by the current EOL.
  
 
<!--T:71-->
 
<!--T:71-->
*You can modify ''saveset EOL'' for each '''''individual saveset''''', stored on a data store.  The ''saveset EOL'' parameter is available under several properties views, for example, as ''Locked until'' option in the backup task properties or as ''Saveset EOL'' (e.g., Components -> Data Store -> Properties -> tab Savesets -> Saveset EOL). You can extend or reduce the saveset's retention time by setting the exact expiry date in the calendar. If the adjusted saveset is a part of a backup chain, the whole chain might be affected.   
+
*You can modify ''saveset EOL'' for each '''''individual saveset''''' that is stored in a data store.  The ''saveset EOL'' parameter is available under several views, for example, in the ''Media'', ''Media Pools'' and ''Data Stores'' properties as ''Saveset EOL'' (e.g., Components -> Data Store -> Properties -> tab Savesets -> Saveset EOL). You can extend or shorten the saveset's retention time by setting the exact expiration date in the GUI calendar or directly expire the saveset by clicking the ''Expire'' button. If the adjusted saveset is a part of a backup chain, the whole chain might be affected.   
  
 
<!--T:72-->
 
<!--T:72-->
*Additionally, there is also the ''backup EOL'' parameter. This is the expiry date for '''''all data that belong to the same backup, including migrated and replicated savesets'''''. You can check and modify the backup EOL parameter by setting the exact expiry date in the calendar in GUI by using the ''Savesets'' properties (e.g., Main Selection -> Components -> Data Store -> Properties -> tab Savesets -> Backup EOL). If the adjusted saveset is a part of a backup chain, the whole chain is affected.  
+
*Additionally, there is also the ''backup EOL'' parameter. This is the expiry date for '''''all data belonging to the same backup, including migrated and replicated savesets'''''. You can check and modify the backup EOL parameter by setting the exact expiration date in the GUI calendar by using the ''Savesets'' properties (e.g., Components -> Data Store -> Properties -> tab Savesets -> Backup EOL). If the adjusted saveset is part of a backup chain, the entire chain is affected.  
For details, see section [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#chain_dependencies|How SEP sesam deals with EOL-related backup chain dependencies]].  
+
For details, see the section how SEP sesam handles [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#chain_dependencies|EOL-related backup chain dependencies]].  
  
{{tip|As of [[SEP_sesam_Release_Versions| ≥ 4.4.3 ''Beefalo V2'']], you can simply right-click the selected saveset for which you want to modify EOL and then select to either extend EOL or to expire the saveset. But be careful with the expire function as the expired backups are irrevocably lost!}}</translate>
+
{{tip|As of [[SEP_sesam_Release_Versions| ≥ 4.4.3 ''Beefalo V2'']], you can simply right-click the selected saveset for which you want to modify EOL and then select to either extend EOL or to expire the saveset (individual EOL) or backup (EOL of the entire backup set). But be careful with the expire function as the expired backups are irrevocably lost!}}</translate>
 
<translate>[[image:right-click_EOL.jpg|500px|link=]]</translate>
 
<translate>[[image:right-click_EOL.jpg|500px|link=]]</translate>
 
<br clear=all>
 
<br clear=all>
Line 210: Line 210:
  
 
<!--T:75-->
 
<!--T:75-->
*If you are reducing ''backup EOL'', it is adjusted only for the savesets with EOL longer than the newly given EOL, while the savesets with shorter EOL are not affected (their EOL remains unchanged). You cannot set the expiration date to a time in the past. However, you can expire backup sets that you no longer need by using the right-click ''Expire'' function in the ''Savesets'' view -> ''Backup EOL'' -> ''Expire''. Expiring backup EOL terminates the selected backup and all related savesets based on the same backup, including migrated and replicated savesets. This means that all dependent saveset versions that are part of the expired backup are deleted during the next purge.
+
*If you are reducing ''backup EOL'', it is adjusted only for the savesets with EOL longer than the newly given EOL, while the savesets with shorter EOL are not affected (their EOL remains unchanged). You cannot set the expiration date to a time in the past. However, you can '''expire''' backup sets that you no longer need by using the right-click ''Expire'' function in the ''Savesets'' view -> ''Backup EOL'' -> ''Expire''. Expiring backup EOL terminates the selected backup and all related savesets based on the same backup, including migrated and replicated savesets. This means that all dependent saveset versions that are part of the expired backup are deleted during the next purge.
  
 
<!--T:76-->
 
<!--T:76-->
*If you are reducing ''saveset EOL'', the new expiry date is set immediately for the selected individual saveset. You cannot set the expiration date to a time in the past. However, you can expire any individual saveset(s) you no longer need by using the right-click ''Expire'' function in the ''Savesets'' view -> ''Saveset EOL'' -> ''Expire''. In contrast to the backup EOL approach, expiring saveset EOL only terminates the selected saveset(s) and leaves all related savesets untouched. This means that only the selected saveset(s) with expired EOL are deleted with the next purge.
+
*If you are reducing ''saveset EOL'', the new expiry date is set immediately for the selected individual saveset. You cannot set the expiration date to a time in the past. However, you can '''expire''' any individual saveset(s) you no longer need by using the right-click ''Expire'' function in the ''Savesets'' view -> ''Saveset EOL'' -> ''Expire''. In contrast to the backup EOL approach, expiring saveset EOL only terminates the selected saveset(s) (the selected saveset(s) with expired EOL are deleted with the next purge) unless this saveset is part of a backup chain; in the latter case, the entire backup chain is affected as described in [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#chain_dependencies|Managing EOL-related backup chain dependencies]].  
  
 
==={{anchor|manual_extend}}Manually extending EOL=== <!--T:77-->  
 
==={{anchor|manual_extend}}Manually extending EOL=== <!--T:77-->  
  
 
<!--T:78-->
 
<!--T:78-->
Extending EOL can be used for special cases, such as increasing the retention time of a particular backup data that has also been migrated and is stored on different media pools.
+
Extending EOL can be used for special cases, such as increasing the retention time of a particular backup data that has also been migrated and is stored on different media pools. How SEP sesam manages ''extending EOL'' depends on its version.
  
 
<!--T:79-->
 
<!--T:79-->
Line 238: Line 238:
 
<translate>
 
<translate>
 
<!--T:84-->
 
<!--T:84-->
*Extending ''backup EOL'' of savesets stored on tape media may extend the EOL of the tape media! For savesets stored on tape media, a specific retention time that would only apply to one of the stored savesets cannot be set. Every saveset that is stored on tape has its own EOL, but this does not represent the actual expiration date of the tape. Tape media EOL is max EOL of all savesets stored on the tape or max EOL of DIFF/INCR savesets referring to FULL/DIFF/INCR saveset that is stored on other media or even data store.
+
*Extending ''backup EOL'' of savesets stored on tape media may extend EOL of the tape media! For savesets stored on tape media, a specific retention time that would only apply to one of the stored savesets cannot be set. Each saveset that is stored on tape has its own EOL, but this does not represent the actual expiration date of the tape. Tape media EOL is the maximum EOL of all savesets stored on the tape or maximum EOL of DIFF/INCR savesets that refer to FULL/DIFF/INCR saveset stored on other media or even data store.
  
 
<!--T:85-->
 
<!--T:85-->
*To reduce or increase the tape media EOL (shown as ''Locked until'' in the tape properties), the media EOL (identified by tape label) can be adjusted. Manually adjusted EOL is valid for all savesets on tape.
+
*To reduce or increase the tape media EOL (shown as ''Locked until'' in the tape properties), you can adjust the media EOL (identified by tape label). Manually adjusted EOL applies to all savesets on tape.
  
 
<!--T:86-->
 
<!--T:86-->
Line 249: Line 249:
  
 
<!--T:88-->
 
<!--T:88-->
The default backup retention behavior can be changed by inserting or modifying retention-related keys in global settings in GUI: SEP sesam menu bar, click ''Configuration'' -> ''Defaults'' -> ''Settings''. These keys may not be supported in previous SEP sesam versions, for details check [[Special:MyLanguage/4_4_3:Managing_EOL|Managing EOL in versions 4.4.3-4.4.3 ''Grolar'']].</translate>
+
The default backup retention behavior can be changed by inserting or modifying retention-related keys in the global settings in GUI: SEP sesam menu bar, click ''Configuration'' -> ''Defaults'' -> ''Settings''. These keys may not be supported in earlier SEP sesam versions, for details check [[Special:MyLanguage/4_4_3:Managing_EOL|Managing EOL in versions 4.4.3-4.4.3 ''Grolar'']].</translate>
  
 
<translate>
 
<translate>
Line 270: Line 270:
 
  |-
 
  |-
 
|<tt>eol_for_failed_backups</tt>|| | '''0''' (<translate><!--T:104--> use media pool EOL</translate>) <br />'''> 0''' (<translate><!--T:105--> specify the retention period in days, e.g., 3</translate>) || <translate><!--T:106--> Adjust the retention period (in days) for failed backups</translate> ||  4.4.3 ''Beefalo V2'' ||  
 
|<tt>eol_for_failed_backups</tt>|| | '''0''' (<translate><!--T:104--> use media pool EOL</translate>) <br />'''> 0''' (<translate><!--T:105--> specify the retention period in days, e.g., 3</translate>) || <translate><!--T:106--> Adjust the retention period (in days) for failed backups</translate> ||  4.4.3 ''Beefalo V2'' ||  
<translate><!--T:107--> By default, the backup retention policy (media pool EOL) is equally applied to successful and failed backups. A failed backup is retained for the number of days specified by [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#media_pool|media pool EOL]]. If you want to free up space on the storage repository and shorten the number of days for retaining failed backups, specify the desired length of the retention for failed backups in days. For example, 3 means that SEP sesam will delete all failed backups automatically after 3 days. 0 (default) means that all failed backups are retained according to media pool EOL.</translate>  
+
<translate><!--T:107--> By default, the backup retention policy (media pool EOL) is applied equally to successful and failed backups. A failed backup is retained for the number of days specified by the [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#media_pool|media pool EOL]]. If you want to free up space on the storage repository and shorten the number of days for retaining failed backups, specify the desired length of the retention for failed backups in days. For example, 3 means that SEP sesam will automatically delete all failed backups after 3 days. 0 (default) means that all failed backups are retained according to the media pool EOL.</translate>  
  
 
  |-
 
  |-
|<tt>eol_for_failed_not_file_system_backups</tt>|| | '''0''' (<translate><!--T:108--> use media pool EOL</translate>) <br /> '''> 0''' (<translate><!--T:109--> specify the retention period in days, e.g., 3</translate>) || <translate><!--T:110--> Adjust the retention period (in days) for all ''non-filesystem'' (''non-Path'') [[Special:MyLanguage/SEP_sesam_Glossary#task_type|type]] backups, e.g., SAP Hana, Exchange Server, VMware vSphere etc.</translate> ||  4.4.3 ''Beefalo V2'' || <translate><!--T:111--> The only difference with the previous parameter (''eol_for_failed_backups'', see above) is that you can specify the desired length of the retention specifically for all ''non-filesystem'' (''non-Path'') [[Special:MyLanguage/SEP_sesam_Glossary#task_type|type]] backups. For example, 3 means that SEP sesam will delete all failed ''non-filesystem'' backups automatically after 3 days. 0 (default) means that all failed ''non-filesystem'' backups are retained according to ''eol_for_failed_backups'' parameter, if it is set ''> 0'', or according to ''media pool EOL'', if none of the ''eol_for_failed...'' parameters is set (value 0).</translate>  
+
|<tt>eol_for_failed_not_file_system_backups</tt>|| | '''0''' (<translate><!--T:108--> use media pool EOL</translate>) <br /> '''> 0''' (<translate><!--T:109--> specify the retention period in days, e.g., 3</translate>) || <translate><!--T:110--> Adjust the retention period (in days) for all ''non-filesystem'' (''non-Path'') [[Special:MyLanguage/SEP_sesam_Glossary#task_type|type]] backups, e.g., SAP Hana, Exchange Server, VMware vSphere etc.</translate> ||  4.4.3 ''Beefalo V2'' || <translate><!--T:111--> The only difference with the previous parameter (''eol_for_failed_backups'', see above) is that you can specify the desired length of the retention specifically for all ''non-filesystem'' (''non-Path'') [[Special:MyLanguage/SEP_sesam_Glossary#task_type|type]] backups. For example, 3 means that SEP sesam will automatically delete all failed ''non-filesystem'' backups after 3 days. 0 (default) means that all failed ''non-filesystem'' backups are retained according to the ''eol_for_failed_backups'' parameter if set to ''> 0'', or according to ''media pool EOL'' if none of the ''eol_for_failed...'' parameters is set (value 0).</translate>  
 
  |-
 
  |-
 
  |}
 
  |}
  
 
<translate><!--T:112-->
 
<translate><!--T:112-->
The screenshot shows the ''Defaults'' -> ''Settings'' table with EOL-related paramaters.
+
The screenshot shows the ''Defaults'' -> ''Settings'' table with the EOL-related paramaters.
 
   
 
   
 
[[image:EOL_keys-settings.jpg|500px|link=]]</translate>
 
[[image:EOL_keys-settings.jpg|500px|link=]]</translate>
Line 286: Line 286:
  
 
<!--T:114-->
 
<!--T:114-->
You can use the ''saveset tree view'' in GUI to determine dependencies and EOL of an FDI backup chain. Use this overview prior to manually changing EOL parameter to avoid breaking a backup chain.</translate>
+
You can use the ''saveset tree view'' in GUI to determine dependencies and EOL of an FDI backup chain. You should use this overview before you manually change the EOL parameter to avoid breaking the backup chain.</translate>
{{<translate><!--T:115--> tip</translate>|<translate><!--T:116--> Checking the saveset tree summary will provide instant information about location and status of available savesets for restore. By checking the summary, e.g., availability 5, you can search for the savesets that are not readily available, then migrate them to allow [[Special:MyLanguage/SEP_sesam_Glossary#XPRFS|mount]] and enable [[Special:MyLanguage/SEP_sesam_Glossary#selective_restore|selective restore]].</translate>}}
+
{{<translate><!--T:115--> tip</translate>|<translate><!--T:116--> Checking the saveset tree summary will provide instant information about the location and status of the available savesets for restore. By checking the summary, e.g., availability 5, you can search for savesets that are not readily available, and then migrate them to enable [[Special:MyLanguage/SEP_sesam_Glossary#XPRFS|mount]] and [[Special:MyLanguage/SEP_sesam_Glossary#selective_restore|selective restore]].</translate>}}
  
 
<translate><!--T:117-->
 
<translate><!--T:117-->
The saveset tree displays a saveset related details together with potential dependent savesets belonging to the same backup chain. The saveset details are read-only. By providing an overview of the backup chain, you get insight on restorability of backups.
+
The saveset tree displays details about a saveset together with potential dependent savesets that belong to the same backup chain. The saveset details are read-only. By providing an overview of the backup chain, you gain insight into the recoverability of backups.
  
 
<!--T:118-->
 
<!--T:118-->
Line 304: Line 304:
  
 
<translate><!--T:122-->
 
<translate><!--T:122-->
The saveset tree displays all savesets belonging to the same backup chain with the following details:
+
The saveset tree displays all savesets that belong to the same backup chain with the following details:
 
;saveset:SEP sesam unique identification assigned to a saveset.
 
;saveset:SEP sesam unique identification assigned to a saveset.
  
Line 311: Line 311:
  
 
<!--T:124-->
 
<!--T:124-->
;level:The backup level used for saveset: F (FULL), D (DIFF), I (INCR) or C (COPY).
+
;level:The backup level used for the saveset: F (FULL), D (DIFF), I (INCR) or C (COPY).
  
 
<!--T:125-->
 
<!--T:125-->
Line 321: Line 321:
  
 
<!--T:127-->
 
<!--T:127-->
;avail:The priority number, based on the location of the savesets. It is useful for identifying savesets that are readily available for restore. For example, a saveset in media pool DAY (data store) is migrated to another pool DeDup and then migrated to tape. The tape will have the lowest avail/priority because it is not readily available for restore. Check also the ''Availability'' in the ''Status'' at the end of the tree view, which is calculated from the avail of all displayed savesets. See below ''Availability'' for details.
+
;avail:The priority number, based on the location of the savesets. It is useful for identifying savesets that are readily available for restore. For example, a saveset in the media pool DAY (data store) is migrated to another pool DeDup and then migrated to tape. The tape will have the lowest avail/priority because it is not readily available for restore. Check also the ''Availability'' in the ''Status'' at the end of the tree view, which is calculated from the avail of all displayed savesets. See below ''Availability'' for details.
  
 
<!--T:128-->
 
<!--T:128-->
;reason:Explains the above ''avail'' – availability of individual savesets for restore. The following information shows the relation between the location and  ''avail/prio''. Priority is assigned numerically, with 1 being the lowest priority and 6 (or 7 if called with a specific pool) being the highest.</translate>
+
;reason:Explains the above ''avail'' – availability of individual savesets for restore. The following information shows the relation between the location and  ''avail/prio''. Priority is assigned numerically, where 1 is the lowest priority and 6 (or 7 if called with a specific pool) is the highest.</translate>
 
  TAPE_SINGLE = 0
 
  TAPE_SINGLE = 0
 
  TAPE_NOT_IN_LOADER = 1
 
  TAPE_NOT_IN_LOADER = 1
Line 343: Line 343:
  
 
<!--T:132-->
 
<!--T:132-->
;labels:Displays an internal identification of a saveset (a media pool name and a 5-digit number), a potential ''barcode'', ''prio'' (numerical representation of the availability, see above item), and comment.
+
;labels:Displays an internal identification of a saveset (a media pool name and a 5-digit number), a potential ''barcode'', ''prio'' (numerical representation of availability, see above item), and comment.
  
 
<!--T:133-->
 
<!--T:133-->
;status:Displays the summary of savesets availability – status, message on availability and a numerical representation. For example, as soon as 1 saveset is migrated to another pool and deleted from the original pool, the availability will be lowered.
+
;status:Displays the summary of the savesets availability – status, availability message and a numeric representation. For example, as soon as 1 saveset is migrated to another pool and deleted from the original pool, availability is lowered.
  
 
<!--T:134-->
 
<!--T:134-->

Revision as of 18:00, 2 December 2019

Other languages:
Deutsch • ‎English

Copyright © SEP AG 1999-2019. 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.

Draft.png WORK IN PROGRESS
This is a draft document for the SEP sesam upcoming 4.4.3 Beefalo V2 release. Note that the article is in the initial stage and may be updated, replaced or deleted at any time. It is inappropriate to use this document as reference material as it is a work in progress and should be treated as such.


Docs latest icon.png Welcome to the latest SEP sesam documentation version 4.4.3 Beefalo/4.4.3 Beefalo V2. For previous documentation version(s), check Documentation archive.


Overview

When configuring SEP sesam environment, you set up media pools and define the retention time. Media pool retention time is specified in days and defines how long the backed up data on media remains protected after the data is written to the medium. The retention time period starts with the date a saveset is written to the medium and lasts for the period defined by media pool's EOL. When the protection expires, SEP sesam can re-use the media for backups again. This is the basic principle and the simplest scenario.

However, to ensure restorability of the complete backup chain and to protect from data loss, SEP sesam provides dependency-based retention strategy performed by automated EOL adjustment.

What is dependency-based retention

For example, INCR backups require all previous savesets (FULL, DIFF and INCR) to be available for a successful restore. If the retention time is viewed only from the perspective of an individual backup, it can ensure restorability of data for this particular backup only. But to enable the complete restoration of data that was backed up in the backup chain, all dependent backup savesets must be tracked and their retention time must be managed according to their dependencies.

For example, INCR backup that was taken after the third INCR after the FULL, requires the FULL, the first, the second, and the third INCR to provide complete restore capability. If some saveset in the backup chain is missing, you will not be able to recover your data to a specific point in time. For this reason, SEP sesam maintains control over dependencies among the individual backup savesets and provides dependency-based automated retention.

SEP sesam also allows you to manually adjust EOL. You can adjust:

saveset EOL
You can change the expiration date of any individual saveset that is stored in the data store, see saveset EOL.
backup EOL
You can change the expiration date for all backup-related savesets. Unlike saveset EOL, which is applied individually to each selected saveset, changing the backup EOL always affects all dependent backup versions that are part of the same backup, see backup EOL.
tape media EOL
Some special rules apply to tape media since the expiry date of the tape corresponds to the maximum retention time (the longest EOL) identified on the tape, see tape media EOL.

Retention behavior and different EOL parameters

Typically, you specify a media pool retention time when creating a media pool. This retention time serves as a basis to determine EOL for backed up data.

Information sign.png Note
EOL 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 retention periods.

The EOL property can be managed for four object types:

Media pool EOL

Media pool EOL specifies the retention time (in days) for savesets written to the respective pool. The saveset EOL is calculated when the data is written to the medium: it starts with the date a saveset is created and lasts for the period defined by media pool's retention time. For example, a media pool retention time is 30 days, and the data is backed up to the medium on the 1st of January, therefore the saveset EOL is 31st of January.

Saveset EOL

This is the expiry date for each saveset. If a saveset is a part of a backup chain, its EOL follows the rules of dependency-based retention; EOL of a previous saveset in the chain must be the same or longer to enable the complete restoration of data.

For example, you specify a media pool retention parameter to 30 days and run a FULL backup. This FULL saveset will initially be kept for 30 days, for example, to the 31st of January. If any following INCR or DIFF saveset in the chain has longer EOL, for example, its expiry date is the 3rd of February, the EOL of all preceding savesets, including the FULL, will be adjusted to the longer expiry date. For details on dependency-based automated retention, see automated EOL adjustment. For details on manually adjusting EOL, see manual EOL adjustment.

Backup EOL

This is the expiry date for all data that belongs to the same backup. Backup EOL is determined based on the longest EOL of all savesets that belong to the same backup, including migrated and replicated savesets. For example, adjusting backup EOL of a particular saveset from the 3rd of February to the to 3rd of March results in changed EOL for all related backup data, i.e., original backup, migrated backup, replicated backup, as well as for all backups in a backup chain, if a saveset with adjusted backup EOL is a part of it. For details on dependency-based automated retention, see automated EOL adjustment. For details on manually adjusting EOL, see manual EOL adjustment.

Information sign.png Note
How SEP sesam manages failed backups depends on its version. In v. ≥ 4.4.3 Beefalo V2, SEP sesam keeps the failed backup according to the media pool EOL together with the last successful backup or migration saveset. This is the default backup retention behavior and can be changed by modifying retention-related keys, as shown in section Customizing retention policy. These keys may not be supported in earlier versions, where failed backups were automatically deleted after 3 days.

Tape media EOL

When a saveset is stored on tape, each stored saveset has its own saveset EOL, but this does not represent the actual expiration date of the tape. Its expiry date corresponds to the maximum retention time (the longest EOL) identified on tape. Only when all savesets on tape have expired and the tape is not locked (write-protected) is the entire tape eligible for re-use. For details on how manually extending EOL affects EOL of the tape media, see Manually extending EOL.

What happens when EOL is reached

Once a saveset's end of life is reached, its protection expires. 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 the longest possible time. The expired saveset can be re-used if the following conditions are met:

  • As a rule, there must be no other savesets that depend on this saveset. For details, see how SEP sesam handles EOL-related backup chain dependencies. You can override this condition by explicitly allowing the expiration date (EOL) of the whole backup chain to expire, thus deleting the backup data on all related savesets.
  • If a saveset is stored on tape, the EOL of all stored savesets must have expired.
  • SEP sesam Server automatically assigns the medium with the oldest EOL for re-use. The oldest medium is a medium with the oldest locked until (is backup day+ EOL) date in the media pool.
Information sign.png Note
If the saveset resides on tape media, the tape will not be re-used until all savesets on it have expired. Tape media EOL always corresponds to the maximum retention time (the longest EOL) identified on the tape. More precisely, a tape media EOL is the maximum EOL of all savesets stored on the tape, or the maximum EOL of DIFF/INCR savesets that refer to FULL/DIFF/INCR savesets stored on other media or even data stores. Only when the retention time of all savesets on tape has expired and the tape is no longer locked (write-protected) can the tape be re-used.

Automated EOL adjustment

In some cases, SEP sesam automatically adjusts EOL to retain the consistency of backed up data and ensures successful restore. Every time EOL is modified, the corresponding information is shown in the main log.

Managing EOL-related backup chain dependencies

When a new INCR or DIFF backup is run or an INCR or DIFF backup is migrated, SEP sesam automatically adjusts EOL of all related savesets in order to retain the backup data and keep the backup chain readily available for restore. In some special cases, SEP sesam also automatically increases the EOL of the whole FDI backup chain, thus preventing the backup chains from being orphaned. See below sections for details.

Increased EOL of a DIFF or INCR saveset

If the EOL parameter of a DIFF or INCR saveset is increased, SEP sesam will increase EOL of all dependent backups (FULL and other DIFF and INCR). This way SEP sesam ensures that EOL for the FULL backup and other related DIFF and INCR is not shorter than the potentially modified DIFF or INCR saveset's EOL.

Decreased EOL of a DIFF or INCR saveset

If EOL of a DIFF or INCR saveset is decreased, SEP sesam will decrease EOL of all dependent backups (FULL and other DIFF and INCR). If you use the Expire function to delete the unneeded saveset(s) or backup set(s), SEP sesam will issue a warning message, prompting you to confirm your decision to expire the entire backup chain.

SEP Warning.png Warning
Expiring the DIFF or INCR saveset(s) results in purging and overwriting the complete backup chain!

Too short EOL of DIFF/INC savesets

If DIFF/INCR backup detects that a saveset belonging to a FDI chain has too short EOL, then any consecutive DIFF/INCR backup that is running on a pool with longer EOL will increase the EOL of the saveset from the respective pool.

Information sign.png Note
If EOL of a saveset belonging to a FDI chain has already expired, it will not be extended. In this case, the DIFF/INCR backup will be executed as a FULL backup.
Example
The backup chain has the following retention specified: FULL on pool MONTH (EOL:32), DIFF on pool WEEK (EOL:15) and INCR on pool DAY (EOL:7). EOL of such FDI chain is sufficient, therefore EOL is not modified.

Allow extending retention period of another media pool for migrated savesets

Typically, a chain of backup savesets is migrated to one target media pool. You may want to migrate savesets of one backup chain (FULL/DIFF/INCR) to different media pools. There are two ways to change the retention period of migration savesets.

  • You can enable extended retention period for migration by using a specific GLBV: 'gv_adjust_eol_migration_increases_eol_on_other_pool'.
  • You can enable migration to increase EOL of the referenced savesets on other media pools (not only on the target media pool) by adding (or modifying) the following key in global settings in GUI:
    1. In the menu bar, click Configuration -> Defaults -> Settings.
    2. Click [+] to add the following key to global settings (or modify the key value, if it already exists): eol_adjust_migration_on_other_pool|1|sesam
      where value=1 means that the key is active and sesam is the user name. For more details about retention-related keys, see section Customizing retention policy.
    3. EOL adjust migration Beefalo.jpg


Last successful backup or migration is automatically retained

SEP sesam automatically retains the last successful backup or migration saveset when the next backup/migration fails. By extending the EOL of the previous 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 respective keys, eol_adjust_failed_backup and eol_adjust_failed_migration, to 0, as shown in section Customizing retention policy.

COPY backup fails

If a COPY backup fails, the EOL of the last successful or with warnings COPY backup is increased to the media pool EOL of the backup.

Example
COPY backup in pool MONTH (EOL: 32) fails. SEP sesam checks for previous successful COPY backup in the same pool and increases its EOL, unless the backup EOL is not sufficient, e.g., a migrated saveset exists in the pool YEAR (EOL: 375).

FULL/DIFF/INCR backup fails

If a FULL backup fails, the EOL of the last successful or with warnings FULL/DIFF/INCR backup is increased to the media pool EOL of the backup.

Example
FULL backup in the pool MONTH (EOL: 32) fails. SEP sesam checks for previous successful or with warnings FDI backup chain in the same pool and increases the EOL of the entire chain (FULL/DIFF/INCR backups), unless the backup EOL is not sufficient, e.g., a migrated FULL saveset already exists in the pool YEAR (EOL: 375).

Manual EOL adjustment

It is not recommended to manually adjust EOL. This will override the EOL that was defined by the retention time (in days) in the media pool configuration and was started on the date when a saveset is being written to the media. The following options should be used for special cases and exceptions, for example, to allow premature deletion of an individual saveset or to increase the retention time of a particular backup chain that is to be stored longer than specified by the current EOL.

  • You can modify saveset EOL for each individual saveset that is stored in a data store. The saveset EOL parameter is available under several views, for example, in the Media, Media Pools and Data Stores properties as Saveset EOL (e.g., Components -> Data Store -> Properties -> tab Savesets -> Saveset EOL). You can extend or shorten the saveset's retention time by setting the exact expiration date in the GUI calendar or directly expire the saveset by clicking the Expire button. If the adjusted saveset is a part of a backup chain, the whole chain might be affected.
  • Additionally, there is also the backup EOL parameter. This is the expiry date for all data belonging to the same backup, including migrated and replicated savesets. You can check and modify the backup EOL parameter by setting the exact expiration date in the GUI calendar by using the Savesets properties (e.g., Components -> Data Store -> Properties -> tab Savesets -> Backup EOL). If the adjusted saveset is part of a backup chain, the entire chain is affected.

For details, see the section how SEP sesam handles EOL-related backup chain dependencies.

SEP Tip.png Tip
As of ≥ 4.4.3 Beefalo V2, you can simply right-click the selected saveset for which you want to modify EOL and then select to either extend EOL or to expire the saveset (individual EOL) or backup (EOL of the entire backup set). But be careful with the expire function as the expired backups are irrevocably lost!

Right-click EOL.jpg

Manually reducing EOL

Note that reducing EOL may result in potential data loss due to the inability to restore from a backup.

  • If you are reducing backup EOL, it is adjusted only for the savesets with EOL longer than the newly given EOL, while the savesets with shorter EOL are not affected (their EOL remains unchanged). You cannot set the expiration date to a time in the past. However, you can expire backup sets that you no longer need by using the right-click Expire function in the Savesets view -> Backup EOL -> Expire. Expiring backup EOL terminates the selected backup and all related savesets based on the same backup, including migrated and replicated savesets. This means that all dependent saveset versions that are part of the expired backup are deleted during the next purge.
  • If you are reducing saveset EOL, the new expiry date is set immediately for the selected individual saveset. You cannot set the expiration date to a time in the past. However, you can expire any individual saveset(s) you no longer need by using the right-click Expire function in the Savesets view -> Saveset EOL -> Expire. In contrast to the backup EOL approach, expiring saveset EOL only terminates the selected saveset(s) (the selected saveset(s) with expired EOL are deleted with the next purge) unless this saveset is part of a backup chain; in the latter case, the entire backup chain is affected as described in Managing EOL-related backup chain dependencies.

Manually extending EOL

Extending EOL can be used for special cases, such as increasing the retention time of a particular backup data that has also been migrated and is stored on different media pools. How SEP sesam manages extending EOL depends on its version.

Manually extending EOL in v. ≥ 4.4.3 Beefalo:

  • If you are extending the backup EOL (expiration date), the EOL is adjusted only for the saveset that already has the longest EOL, while EOL of other backups is not affected. This behavior has changed compared to the previous versions, where extended backup EOL resulted in extended EOL for all savesets based on the same backup, i.e., original backup, migrated backup, replicated backup, as well as for all backups in a backup chain, if a saveset with adjusted backup EOL was part of it.

Manually extending EOL in v. 4.4.3 Grolar:

  • If you are extending the saveset EOL (expiration date) and one of the savesets is part of an FDI backup chain, then the EOL of the previous savesets in the chain will also be increased.
  • If you are extending the backup EOL (expiration date), the EOL is adjusted for all savesets based on the same backup, including migrated and replicated savesets. This can lead to unintentional extension of the EOL for backup savesets stored on a media pool with short EOL. If one of the backups is part of an FDI backup chain, then the EOL of the previous savesets in the chain will also be increased.
Information sign.png Note
  • Extending backup EOL of savesets stored on tape media may extend EOL of the tape media! For savesets stored on tape media, a specific retention time that would only apply to one of the stored savesets cannot be set. Each saveset that is stored on tape has its own EOL, but this does not represent the actual expiration date of the tape. Tape media EOL is the maximum EOL of all savesets stored on the tape or maximum EOL of DIFF/INCR savesets that refer to FULL/DIFF/INCR saveset stored on other media or even data store.
  • To reduce or increase the tape media EOL (shown as Locked until in the tape properties), you can adjust the media EOL (identified by tape label). Manually adjusted EOL applies to all savesets on tape.
  • If the tape media EOL date has been reached, but the tape should not be re-used, you can also lock the tape (by using write protection). This option overrides media EOL.

Customizing retention policy

The default backup retention behavior can be changed by inserting or modifying retention-related keys in the global settings in GUI: SEP sesam menu bar, click Configuration -> Defaults -> Settings. These keys may not be supported in earlier SEP sesam versions, for details check Managing EOL in versions 4.4.3-4.4.3 Grolar.

To change the retention policy, you can add or modify the following options.

Retention-related key Value Description Available from version Note
eol_adjust_migration_on_other_pool 1 (allow)
0 (disable)
Allow extending retention period of another media pool for migrated savesets 4.4.3 Beefalo
eol_adjust_failed_backup 1 (enable)
0 (disable)
Automatic retention of the last successful backup saveset 4.4.3.47 Tigon V2
eol_adjust_failed_migration 1 (enable)
0 (disable)
Automatic retention of the last successful migration saveset 4.4.3.47 Tigon V2
eol_for_failed_backups 0 (use media pool EOL)
> 0 (specify the retention period in days, e.g., 3)
Adjust the retention period (in days) for failed backups 4.4.3 Beefalo V2

By default, the backup retention policy (media pool EOL) is applied equally to successful and failed backups. A failed backup is retained for the number of days specified by the media pool EOL. If you want to free up space on the storage repository and shorten the number of days for retaining failed backups, specify the desired length of the retention for failed backups in days. For example, 3 means that SEP sesam will automatically delete all failed backups after 3 days. 0 (default) means that all failed backups are retained according to the media pool EOL.

eol_for_failed_not_file_system_backups 0 (use media pool EOL)
> 0 (specify the retention period in days, e.g., 3)
Adjust the retention period (in days) for all non-filesystem (non-Path) type backups, e.g., SAP Hana, Exchange Server, VMware vSphere etc. 4.4.3 Beefalo V2 The only difference with the previous parameter (eol_for_failed_backups, see above) is that you can specify the desired length of the retention specifically for all non-filesystem (non-Path) type backups. For example, 3 means that SEP sesam will automatically delete all failed non-filesystem backups after 3 days. 0 (default) means that all failed non-filesystem backups are retained according to the eol_for_failed_backups parameter if set to > 0, or according to media pool EOL if none of the eol_for_failed... parameters is set (value 0).

The screenshot shows the Defaults -> Settings table with the EOL-related paramaters.

EOL keys-settings.jpg

Checking backup chain dependencies

You can use the saveset tree view in GUI to determine dependencies and EOL of an FDI backup chain. You should use this overview before you manually change the EOL parameter to avoid breaking the backup chain.

SEP Tip.png Tip
Checking the saveset tree summary will provide instant information about the location and status of the available savesets for restore. By checking the summary, e.g., availability 5, you can search for savesets that are not readily available, and then migrate them to enable mount and selective restore.

The saveset tree displays details about a saveset together with potential dependent savesets that belong to the same backup chain. The saveset details are read-only. By providing an overview of the backup chain, you gain insight into the recoverability of backups.

You can open the saveset tree view by double-clicking the selected backup in the backup list:

  1. From Main Selection -> Job State -> Backups or from Main Selection -> Monitoring -> Last Backup State, double-click the selected backup.
  2. In the backup task properties window, open the tab Savesets.

Bck chain dependencies-Beefalo.jpg

The saveset tree displays all savesets that belong to the same backup chain with the following details:

saveset
SEP sesam unique identification assigned to a saveset.
starttime
The time when the backup was started.
level
The backup level used for the saveset: F (FULL), D (DIFF), I (INCR) or C (COPY).

More detailed information displayed for each saveset:

pool
The media pool to which the saveset belongs.
EOL
The time when the saveset's protection expires. For details, see section EOL-related backup chain dependencies.
avail
The priority number, based on the location of the savesets. It is useful for identifying savesets that are readily available for restore. For example, a saveset in the media pool DAY (data store) is migrated to another pool DeDup and then migrated to tape. The tape will have the lowest avail/priority because it is not readily available for restore. Check also the Availability in the Status at the end of the tree view, which is calculated from the avail of all displayed savesets. See below Availability for details.
reason
Explains the above avail – availability of individual savesets for restore. The following information shows the relation between the location and avail/prio. Priority is assigned numerically, where 1 is the lowest priority and 6 (or 7 if called with a specific pool) is the highest.
TAPE_SINGLE = 0
TAPE_NOT_IN_LOADER = 1
DISK_OFFLINE = 2
TAPE_ONLINE = 3
DISK_HARD = 4
DISK_STORE_CLONE = 5 
DISK_STORE = 6 
REQUESTED_POOL = 7 (shown if called with a specific pool, e.g., all savesets on the pool DAY and the saveset_tree was called with the target pool DAY)
drivegroup
Displays the name of the drive group related to the saveset's media pool.
drives
The number of the drive that was used for backup.
labels
Displays an internal identification of a saveset (a media pool name and a 5-digit number), a potential barcode, prio (numerical representation of availability, see above item), and comment.
status
Displays the summary of the savesets availability – status, availability message and a numeric representation. For example, as soon as 1 saveset is migrated to another pool and deleted from the original pool, availability is lowered.

Save set tree status.jpg