Die Aufbewahrungsfristen sowie die Anzahl der aufzubewahrenden Versionen einer Datei wird von TSM durch vier Grössen bestimmt. Diese Grössen können nicht vom Benutzer beeinflusst werden. Sie werden ausschliesslich vom TSM-Systemadministrator vorgegeben.
Die nachfolgenden Ausführungen gelten nicht für Sicherungen mit den TDP-Clients.
Um die Parameter besser verstehen zu können, muss kurz erläutert werden, was TSM unter active bzw. inactive versions einer Datei versteht:
Die active version ist immer die aktuellste, d.h. die letzte Sicherungskopie einer Datei, wenn - und das ist sehr wichtig - die Originaldatei zum Zeitpunkt der letzten Sicherung noch auf der Platte des betreffenden Clients existiert hat. Die inactive versions sind alle Vorgängerkopien der active version und/oder alle Sicherungskopien, wenn - und das ist noch wichtiger - die Originaldatei nicht mehr zum Zeitpunkt der letzten Sicherung auf der Platte des betreffenden Clients existiert hat, also gelöscht worden ist.
Nun zu den vier angesprochenen Grössen:
VEREXIST = N sagt, dass max. N Sicherungskopien aufbewahrt werden.
(unser Wert: VEREXIST = 4)
RETEXTRA = N sagt, dass jede Sicherungskopie, mit Ausnahme der
active version, die nie verfällt, bis zu N Tage
aufbewahrt wird.
Wir sagen bis zu, weil die älteste Kopie immer auch
dann, unabhängig von RETEXTRA, sofort verfällt,
wenn VEREXIST überschritten wird.
(unser Wert: RETEXTRA = 60)
VERDEL = N sagt, dass nur noch die N-aktuellsten Sicherungskopien
weiter aufbewahrt werden, wenn TSM registriert hat, dass
die Originaldatei auf der Platte gelöscht wurde.
Achtung:
In diesem Fall wird dann auch die active version zu
einer inactive version!
(unser Wert: VERDEL = 1)
RETONLY = N sagt, wieviel Tage die aktuellste Sicherungskopie einer
Datei aufbewahrt wird, wenn TSM registriert hat, dass
die Originaldatei auf der Platte gelöscht wurde.
(unser Wert: RETONLY = 62)
Folgende 2 Fallstudien sollen das "Chaos" etwas aufhellen:
Es gelten folgende Parameter:
VEREXIST = 3
RETEXTRA = 45
VERDEL = 1
RETONLY = 62
1. Fallstudie - Originaldatei wird nicht gelöscht
Tag 1: Version 1 angelegt
Tag 5: Version 2 angelegt, Version 1 wird inactive und wird in
45 Tagen verfallen ( Tag 50 ).
Tag 10: Version 3 angelegt, Version 2 wird inactive und wird in
45 Tagen verfallen ( Tag 55 ).
Tag 11: Version 4 angelegt, Version 3 wird inactive und wird in
45 Tagen verfallen ( Tag 56 ).
Achtung: nun verfällt Version 1, weil VEREXIST sagt,
dass nur 3 Versionen gehalten werden, obwohl
Version 1 "normalerweise" erst am Tag 50
verfallen wäre!
Tag 55: Version 2 verfällt per RETEXTRA wie erwähnt.
Tag 56: Version 3 verfällt per RETEXTRA wie erwähnt.
Version 4 verfällt nie!
2. Fallstudie - Originaldatei wird gelöscht
Tag 1: Version 1 angelegt
Tag 5: Version 2 angelegt, Version 1 wird inactive und wird in
45 Tagen verfallen ( Tag 50 ).
Tag 10: Version 3 angelegt, Version 2 wird inactive und wird in
45 Tagen verfallen ( Tag 55 ).
Tag 11: Version 4 angelegt, Version 3 wird inactive und wird in
45 Tagen verfallen ( Tag 56 ).
Achtung: nun verfällt Version 1, weil VEREXIST sagt,
dass nur 3 Versionen gehalten werden, obwohl
Version 1 "normalerweise" erst am Tag 50
verfallen wäre!
Tag 15: Originaldatei wird gelöscht!
Version 4 wird inactive und wird in 62 Tagen ( Tag 77 )
verfallen.
Achtung: nun verfallen Version 2 und Version 3, obwohl
diese "normalerweise" erst am Tag 55 bzw. 56
verfallen wären, weil VERDEL sagt, dass nur
noch 1 Version weiter aufbewahrt wird, wenn
die Originaldatei gelöscht wurde.
Tag 77: Version 4, die letzte Version, verfällt per RETONLY
wie erwähnt.
Now, ALL are gone with the wind!
Alles klar? --- Wenn nicht, dann hilft vielleicht ein Cognac und ein Rechenschieber!
