4 4 3 Beefalo:Media Strategy: Difference between revisions

From SEPsesam
mNo edit summary
(Beefalo V2-related update (EOL).)
Line 108: Line 108:
;<translate><!--T:75-->
;<translate><!--T:75-->
Backup EOL: The parameter '''''Backup EOL''''' (Components -> Data Store -> Properties -> tab Savesets -> Backup EOL) enables you to adjust EOL for all savesets containing the same data. This backup-related EOL is applied to all savesets with the same data, including migrated and replicated save sets.<br /> For example, adjusting EOL of a migrated saveset from 2.12.2016 to 12.12.2017 results in changed EOL for all related backup data, i.e., original backup, replicated backup, as well as for all backups in a backup chain, if a saveset with adjusted EOL is a part of it.</translate>
Backup EOL: The parameter '''''Backup EOL''''' (Components -> Data Store -> Properties -> tab Savesets -> Backup EOL) enables you to adjust EOL for all savesets containing the same data. This backup-related EOL is applied to all savesets with the same data, including migrated and replicated save sets.<br /> For example, adjusting EOL of a migrated saveset from 2.12.2016 to 12.12.2017 results in changed EOL for all related backup data, i.e., original backup, replicated backup, as well as for all backups in a backup chain, if a saveset with adjusted EOL is a part of it.</translate>
{{<translate><!--T:136--> Tip</translate>|<translate><!--T:137--> By default, SEP sesam deletes the failed backups after 3 days automatically to release the storage space. If you want to keep such backups for a longer time, you may manually extend the backup EOL (expiration date) of a particular saveset. For details, see [[Special:MyLanguage/Managing_EOL#manual_extend|Manually extending EOL]].</translate>}}
{{<translate><!--T:136--> Tip</translate>|<translate>How SEP sesam manages failed backups depends on its version. As of v. ≥ [[Special:MyLanguage/SEP_sesam_Release_Versions|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 described in [[Special:MyLanguage/4_4_3_Beefalo:Managing_EOL#keys|Customizing retention policy]]. These keys may not be supported in previous versions, where failed backups were deleted automatically after 3 days.</translate>}}
;<translate><!--T:76-->
;<translate><!--T:76-->
{{anchor|backup_chain}}EOL-related backup chain dependencies: You can extend or reduce the retention period for an individual saveset or backup-related saveset, as described above. Keep in mind that increasing EOL of a DIFF or INCR save set will result in increased EOL of all dependent backups (FULL and other DIFF and INCR) in order to retain the backup data. This keeps the backup chain readily available for restore. On the other hand, decreasing EOL of a DIFF or INCR saveset to a date in the past will result in a warning message prompting you to confirm your decision to set the whole backup chain to already passed time. By setting EOL for DIFF or INCR savesets to expired time results in purging and overwriting the complete backup chain.</translate>
{{anchor|backup_chain}}EOL-related backup chain dependencies: You can extend or reduce the retention period for an individual saveset or backup-related saveset, as described above. Keep in mind that increasing EOL of a DIFF or INCR save set will result in increased EOL of all dependent backups (FULL and other DIFF and INCR) in order to retain the backup data. This keeps the backup chain readily available for restore. On the other hand, decreasing EOL of a DIFF or INCR saveset to a date in the past will result in a warning message prompting you to confirm your decision to set the whole backup chain to already passed time. By setting EOL for DIFF or INCR savesets to expired time results in purging and overwriting the complete backup chain.</translate>

Revision as of 16:15, 15 November 2019

Other languages:
<<<Back
Grouping of SEP sesam Components
User Manual
Next>>>
SEPuler - an event calendar


Media management

Information sign.png Note
In order to improve usability, SEP sesam GUI has been redesigned to be more user-friendly without significantly changing the interface logic. SEP sesam documentation update (such as screenshots) to reflect these changes is being done in a phased manner, therefore the screenshots may still show the GUI from previous versions.

SEP sesam media management provides simple and efficient management of a large number and different types of media. Among its powerful features are:

  • Efficient management of large sets of media.
  • Protection against accidental overwrites.
  • Spare pools prevent failed backups due to missing media.
  • Recording and tracking of all media and their status: used capacity, EOL, user-defined write protection, etc.
  • Barcode support on loaders.

Media pools

Media used by SEP sesam are administered in media pools using non-ambiguous labels. The labels consist of the pool name and a five-digit number assigned by SEP sesam within the pool. For this reason, a media pool name may never end with five (5) digits. In the GUI, a new media pool is created under Main Selection -> Components -> Media Pools -> New Media Pool. For details, see Configuring a Media Pool.

Media

Media should be fully utilized and written on until the EOM (end of media). No entry for EOM is necessary – SEP sesam will request a new medium from the corresponding media pool automatically when the medium or tape is full.

Media event

Media selection is triggered by setting events, which execute the strategies for media selection, reinitialize the media and prepare the media for the scheduled backups.

GET_OLDEST strategy

When there is a single media pool linked to a media event or schedule, the GET_OLDEST policy is always applied. This preserves the data on the media for the longest possible time.

If the media event includes a specific label, the system will attempt to find it and load it into a drive. The autoloader magazine must be accessible to SEP sesam or the backup will be blocked.

The GET_OLDEST strategy determines which medium is to be used next. Preference is given to media according to the following criteria:

  • Media whose EOL has expired. (If a saveset is stored on tape, the EOL of all stored savesets must be expired.)
  • The oldest medium – medium with the oldest locked until (is backup day+ media EOL) date in the media pool.
  • Media that is not write-protected (locked).

For more details on protecting and reusing media, see below section Savesets Protection: Retention time and EOL.

Spare pools

Blocked backups can be prevented by using SPARE pools. Spare pools are used by media events when media from the actual pool are inaccessible. A medium is moved from the compatible spare pool to the pool currently being accessed by the backup. From here, the spare media migrate to the working pools, resulting in a dynamic increase of media pool size, depending on the amount of data being backed up.

Unused media are inserted and kept for later use. For each type of drive, a compatible spare pool with free media should be created.

SPARE pools can be used to automatically insert new media into working media pools. The media are then migrated as necessary to the working pools on the production system.

The name of a spare pool starts with SPARE_.

Media utilization can be regulated by:

  • Locking the time limits of a media pool.
  • Setting write-protection in a media archive.
  • Media events in the SEPuler.
  • Modifying the locking date of media in an archive to exceed the EOL and executing a media event.

Archive adjustment

Archive adjustment makes a comparison between media in the loader carousel or magazine and the SEP sesam media archive database. It is mandatory whenever the contents of a loader carousel have been altered. Typically, it must be performed after inserting new media or used media that have not yet been registered (initialized) by SEP sesam.

Select the Automatic New Entry option to enter the new media automatically.

To start the adjustment using the GUI, select Main Selection -> Components -> Loader -> Archive Adjustment. For details, see Setting up Archive Adjustment.

Information sign.png Note
When selecting the option Archive Adjustment, make sure that the autoloader being realigned is selected in the GUI window, i.e. that the target device is at the top of the adjustment task. When using the command line, the task must include the name of the target autoloader or tape device.

Savesets protection: Retention time and EOL

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.

SEP sesam allows you to adjust EOL for individual saveset (saveset EOL) or for all backup-related savesets (backup EOL).

As of v. 4.4.3 Grolar, modified EOL is recorded in main log.

Saveset EOL
This 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). It enables you to change EOL for each individual saveset, stored on the respective medium. You can extend or reduce its retention time. If the adjusted saveset is a part of a backup chain, the whole chain is affected. See EOL-related backup chain dependencies.
Information sign.png Note
Every saveset that is stored on tape has its own EOL, but this does not represent the actual expiration date of the tape. Its expiration date corresponds to the maximum retention time (the longest EOL) identified on tape. Only when all of the savesets on tape have their retention time expired and the tape is no longer locked (write-protected), the entire tape is eligible for re-use.
  • The tape designated for re-use can then be initialized, deleting all data contained on it and preparing it for use again. If the tape is removed from the loader and then re-inserted, archive adjustment must be performed before SEP sesam can re-use the tape.
  • If a tape should be re-used (init) or deleted before the current EOL is reached, the media EOL (identified by tape label) can be manually reduced (note that the reduced EOL is valid for all savesets on tape). If the media EOL date has been reached, but the tape should not be re-used, the media EOL can be increased or the tape can be locked (write-protected).
Backup EOL
The parameter Backup EOL (Components -> Data Store -> Properties -> tab Savesets -> Backup EOL) enables you to adjust EOL for all savesets containing the same data. This backup-related EOL is applied to all savesets with the same data, including migrated and replicated save sets.
For example, adjusting EOL of a migrated saveset from 2.12.2016 to 12.12.2017 results in changed EOL for all related backup data, i.e., original backup, replicated backup, as well as for all backups in a backup chain, if a saveset with adjusted EOL is a part of it.
SEP Tip.png Tip
How SEP sesam manages failed backups depends on its version. As of 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 described in Customizing retention policy. These keys may not be supported in previous versions, where failed backups were deleted automatically after 3 days.
EOL-related backup chain dependencies
You can extend or reduce the retention period for an individual saveset or backup-related saveset, as described above. Keep in mind that increasing EOL of a DIFF or INCR save set will result in increased EOL of all dependent backups (FULL and other DIFF and INCR) in order to retain the backup data. This keeps the backup chain readily available for restore. On the other hand, decreasing EOL of a DIFF or INCR saveset to a date in the past will result in a warning message prompting you to confirm your decision to set the whole backup chain to already passed time. By setting EOL for DIFF or INCR savesets to expired time results in purging and overwriting the complete backup chain.
Information sign.png Note
The storage space of each saveset can be re-used when the following conditions are met:
  1. Its EOL has expired. (If a saveset is stored on tape, the EOL of all stored savesets must be expired.)
  2. If a saveset is stored on tape, it must not be write-protected (locked).
  3. Typically, there must be no other savesets that depend on this saveset. You can override this condition by explicitly allowing the EOL for the whole backup chain to be set to expire, thus deleting backup data on all related savesets.


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.