5 0 0:Automatisches Aufbewahrungsmanagement (EOL)
Übersicht
|
Siehe auch: Changing Retention (EOL) – Backup Chain Dependencies – Backup Strategy Best Practices – Tape Management – Backup Strategy Best Practices |
|
SEP sesam Videos und Aufzeichnungen anschauen. |
|
Unter FAQ finden Sie Antworten auf die häufigsten Fragen. |
|
Im Problemfall nutzen Sie den Troubleshooting Guide. |
Data retention is the amount of time a backup is kept by SEP sesam. When you create a 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 full backup, followed by differential and incremental backups, a backup metadata file, and may also include other dependent backups, such as migrated and replicated backups. Some INCR backups use CBT (changed block tracking).
Was sind Aufbewahrungszeit und EOL (End of Lifetime)?
Die Aufbewahrungszeit gibt den Zeitraum an, für den Sicherungsdaten nach dem Schreiben auf das Medium geschützt werden, damit die Sicherungssätze erhalten bleiben und für eine Wiederherstellung zur Verfügung stehen. Die Datenaufbewahrung ist wichtig, um sicherzustellen, dass alle Vorschriften und Aufbewahrungsfristen eingehalten werden. Wie lange Sie die Daten aufbewahren sollten, hängt von der Art Ihres Unternehmens sowie von behördlichen, rechtlichen und anderen Anforderungen ab.
- Die Aufbewahrungszeit wird auf der Ebene eines Medienpools eingerichtet und in Tagen angegeben.
- Die Aufbewahrungsfrist beginnt mit dem Datum, an dem ein Saveset auf das Medium geschrieben wird (zum Endzeitpunkt der ersten Sicherung) und definiert somit das Verfallsdatum des Savesets – EOL (End of Lifetime). Zum Beispiel, die Aufbewahrungszeit eines Medienpools beträgt 30 Tage und die Daten werden am 1. Januar auf dem Medium gesichert, daher ist das "Saveset EOL" der 31. Januar. Es gibt drei verschiedene EOL-Typen, die mit den Objekttypen verbunden sind und auch von den verwendeten Speichermedien abhängen; für Details siehe den Abschnitt EOL-Typen (Aufbewahrung).
- Wenn der Schutz (EOL) abläuft, kann SEP sesam das Medium wieder für Backups verwenden. Für weitere Details, siehe im Abschnitt Was passiert, wenn die Aufbewahrungszeit ausläuft?.
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 Changing Retention (EOL).
|
Anmerkung |
| EOL (Aufbewahrungszeit) bezieht sich nur auf Sicherungen und zugehörige migrierte und replizierte Sicherungssätze bezieht.
SEP sesam Logdateien, Lesbarkeitsprüfprotokolle, Kalenderblatteinträge und Wiederherstellungsaufträge haben separate Aufbewahrungsparameter. Siehe Aufbewhrungsfristen für weitere Details. |
What are backup chain dependencies
A backup chain consists of full, differential and 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.
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.
- 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.
- For example, for INCR backups all previous savesets (FULL, DIFF and INCR) must be present for a successful restore.
- If 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 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.
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.
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 Backup Chain Dependencies.
Example of a 14-day retention scenario
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 purged. If the backup data is stored on tape, its protection expires when the 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.
Automatic EOL adjustment
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.
There are six main rules that lead to an adjusted EOL.
Rules for the automatically adjusted retention time
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.
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.
Rule #1: Full backups do not expire as long as dependent DIFF/INCR exist
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.
Rule #2: An increased EOL of a DIFF/INCR saveset results in an increased EOL of all dependent savesets
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.
Rule #3: A decreased EOL of a DIFF/INCR saveset leads to reduced EOL of all dependent savesets
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).
|
Achtung |
| {{{1}}} |
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.
|
|
Anmerkung |
| {{{1}}} |
Rule #5: A new or migrated DIFF/INC backup results in an 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 preserve the backup data.
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.
|
|
Anmerkung |
| {{{1}}} |
What happens when the saveset expires
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:
- 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.
- If a saveset is stored on tape, the EOL of all stored savesets must have expired.
- The media must not be write-protected (locked).
- 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 backup day+ retention time) date in the media pool.
Tracking the adjusted EOL
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 Audit Logging.
Verschiedene EOL-Typen
|
|
Anmerkung |
|
Die EOL-Eigenschaft kann für drei Objekttypen verwaltet werden:
Sicherungssatz-EOL
Das Ablaufdatum für einen einzelnen Sicherungssatz:
Das Datum, an dem die Daten auf den Datenträger geschrieben wurden + die Aufbewahrungszeit des Medienpools
Wenn ein Sicherungssatz Teil einer Sicherungskette ist, folgt seine EOL den Regeln der abhängigkeitsbasierten Aufbewahrung. Die EOL eines vorherigen Sicherungssatzes in der Kette muss gleich oder länger sein, um eine vollständige Rücksicherung der Daten zu ermöglichen.
Beispiel
- Medienpool-Aufbewahrungszeit = 30 Tage.
- Eine FULL-Sicherung wird ausgeführt -> FULL-Sicherungssatz wird 30 Tage lang aufbewahrt (z.B. 31. Januar <YYYY>).
- Wenn ein nachfolgender INCR- oder DIFF-Sicherungssatz in der Kette eine längere EOL hat (z.B. 3. Februar <JJJJ>), wird die EOL des FULL-Sicherungssatzes (und aller vorhergehenden Sicherungssätze) an die längere EOL angepasst (z.B. 3. Februar).
- Verlängern der Aufbewahrung
- Wenn Sie die Sicherungssatz-EOL manuell verlängern und einer der Sicherungssätze Teil einer FDI-Sicherungskette ist, wird die EOL der vorherigen Sicherungssätze in der Kette automatisch erhöht. Das Verlängern der EOL von Sicherungssätzen, die auf Bandmedien gespeichert sind, kann die EOL des Bandmediums verlängern! Siehe unten Bandmedien EOL.
- Verkürzen der Aufbewahrung
- Die Verkürzung des Sicherungssatz-EOL führt zu einem neuen Ablaufdatum, das nur für den ausgewählten individuellen Sicherungssatz gilt.
- Löschen eines Sicherungssatzes
- (siehe auch: Löschen von Sicherungssätzen, Sicherungen und Daten auf Bandmedien)
- Rechtsklick auf den Sicherungssatz -> Sicherungssatz -> Sicherungssatz löschen löscht ausgewählte Sicherungssätze, es sei denn, der Sicherungssatz ist Teil einer Sicherungskette. Im letzteren Fall ist die gesamte Sicherungskette betroffen. Das Löschen kann sofort erfolgen oder bis zur nächsten Bereinigung verzögert werden.
Sicherungs-EOL
Das Ablaufdatum für alle Daten, die zur selber Sicherung gehören, einschließlich migrierter und replizierter Sicherungssätze.
|
|
Anmerkung |
| Wie SEP sesam fehlerhafte Sicherungen verwaltet, hängt von der jeweiligen Version ab. Ab V. ≥ 4.4.3 Beefalo V2 behält SEP sesam die fehlerhaften Sicherung gemäß der Aufbewahrungzeit des Medienpools zusammen mit dem letzten erfolgreichen Sicherungs- oder Migrationssicherungssatz. Dies ist das standardmäßige Verhalten bei der Aufbewahrung von Sicherungen und kann durch Setzen der EOL- bezogenen Parametern in den Vorbelegungen geändert werden, wie in Benutzerdefinierte Regeln für die Aufbewahrung beschrieben. Diese Vorbelegungen werden möglicherweise in früheren Versionen nicht unterstützt, wo fehlgeschlagene Sicherungen nach 3 Tagen automatisch gelöscht wurden. |
Beispiel
- Die EOL eines zur Sicherungskette gehörenden Sicherungssatzes wird vom 3. Februar <JJJJ> auf den 3. März <JJJJ> verlängert.
- Alle zugehörigen Sicherungsdaten, d.h. Original-, migrierte und replizierte Sicherungen sowie alle Sicherungen in einer Sicherungskette, haben nun eine Sicherungs-EOL, die auf den 3. März gesetzt ist.
- Verlängern der Aufbewahrung
- Wenn Sie die Sicherungs-EOL verlängern, erhöht SEP sesam automatisch die EOL aller abhängigen Sicherungssätze (FULL und andere DIFF und INCR).
- Verkürzen der Aufbewahrung
- Die Verkürzung der Sicherungs-EOL passt nur die EOL der Sicherungssätze an, die eine längere EOL als das neu gesetzte Datum haben, während die Sicherungssätze mit einer kürzeren EOL nicht betroffen sind (ihr EOL bleibt unverändert).
- Löschen einer Sicherung
- (siehe auch: Löschen von Sicherungssätzen, Sicherungen und Daten auf Bandmedien)
- Ein Rechtsklick auf den Sicherungssatz -> Sicherung-> Sicherung löschen löscht alle Daten, die zur selben Sicherung gehören (die gesamte Sicherungskette), die sofort oder mit der nächsten Bereinigung gelöscht werden.
Band-Medien-EOL
Die Zeit, bis zu der gesicherte Daten auf Band geschützt bleiben. Sie bezieht sich auf Bandmedien und basiert auf der längsten EOL aller verschiedenen auf Band gespeicherten Sicherungssätze:
Das Verfallsdatum des Bandes = maximale EOL auf dem Band
Eine bestimmte Aufbewahrungszeit, die nur für einen der auf dem Band gespeicherten Sicherungssatz gelten würde, kann nicht festgelegt werden.
Die EOL des Bandmediums kann auch von abhängigen FULL/DIFF/INCR-Sicherungssätzen abhängen, die auf anderen Medien oder sogar in Datenspeichern gespeichert sind.
Erst wenn alle Sicherungssätze auf dem Band abgelaufen sind und das Band nicht gesperrt (schreibgeschützt) ist, kann das Band wieder verwendet werden.
Beispiel
- Band-Medien-EOL = 3. Februar <YYYY>
- Die Sicherungs-EOL eines Sicherungssatzes auf Band wird auf den 3. März <YYYY> verlängert. Wenn dies die längste Aufbewahrungsfrist aller Sicherungssätze auf dem Band ist, wird die Medien-EOL (Datum Gesperrt bis in den Bandeigenschaften) automatisch auf den 3. März verlängert. Andernfalls bleibt die Medien-EOL des Bandes unverändert.
- Verlängern der Aufbewahrung
- Das Verlängern der Medien-EOL führt zu einem neuen Ablaufdatum, das für alle Sicherungssätze auf dem Band gilt.
- Verkürzen der Aufbewahrung
- Das Verkürzen der Band-Medien-EOL gilt für alle Sicherungssätze auf dem Band.
- Ablaufen lassen der Aufbewahrung
- (siehe auch: Löschen von Sicherungssätzen, Sicherungen und Daten auf Bandmedien)
- Wenn das Band in das Laufwerk oder die Bibliothek eingelegt ist, können Sie die Daten auf dem Band löschen. Klicken Sie mit der rechten Maustaste auf die Funktion Ablaufen lassen in der Medienansicht oder zeigen Sie die Bandeigenschaften an und klicken Sie auf Medium ablaufen lassen. Diese Aktion wirkt sich auf das gesamte Band aus. Die Metadaten des Bandes werden entfernt und das Band wird neu initialisiert. Die Löschung kann sofort erfolgen oder bis zur nächsten Bereinigung verzögert werden.
Wo in der GUI
Über die GUI können Sie den EOL-Parameter auf verschiedene Weise ändern:
- Sicherungs- & Sicherungssatz-EOL
-
- Job State -> Backups -> double-click a backup task -> task properties – Info 1 -> in the Storage location table: Saveset EOL
- Components -> Media -> select the saveset 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
- (Band)-Medien-EOL
-
- Components -> Media -> select one or more tapes -> right-click and select Change Media EOL
- Components -> Media -> select the tape to open its properties -> Locked until
Write protection for tape media
This special option allows you to set additional software protection for tape media. You can write-protect selected tape media by setting this option ON manually: Main Selection window -> Components -> Media -> column Write Protection (On/Off).
This option overrides the media pool retention time and any individually adjusted EOL values and sets a permanent protection for savesets on tape. Write-protected media cannot be used until write protection is activated (the media are locked). It can be turned off manually at any time. When the media are no longer write-protected, the retention time of the media pool applies.
Locking a backup
You can also lock your backups in the GUI and SEP sesam Web UI to prevent them from being deleted after the retention time has expired.
|
|
Anmerkung |
| {{{1}}} |
In GUI
There are several ways how to lock a backup in the GUI:
- Job State -> Backups -> double-click a backup task -> task properties – Info 1 -> above the Storage location table on the right select the check box Lock state
- Components -> Media -> select the saveset and open properties -> Savesets tab -> search for the column Locked and click the Off property, then select On
- Components -> Media Pools -> select a media pool and expand it to open the media -> double-click to open the Media properties -> Media properties – Properties 1 -> tab Savesets: search for the column Locked and click the Off property, then select On
- Components -> Data Stores -> double-click the selected data store to open the properties -> Savesets tab -> look for the column Locked and click the Off property, then select On
In Web UI
You can access the Web UI in one of the following ways:
- via the GUI: by clicking the Dashboard icon in the toolbar or
- under menu bar -> Activities -> Dashboard or via Main Selection -> Monitoring -> Dashboard
- or from Activities -> Restore Assistant
- or by entering the following address in the browser bar: http://[sesamserver]:11401/sep/ui/restore/.
|
|
Anmerkung |
| {{{1}}} |
- In Web UI, select Monitoring from the side menu to open a submenu, then go to Last backup state or Backups and click the link of the backup task you want to lock.
- A new view with Details is displayed. Scroll down and select the red button Lock this backup next to Lock state.
