Bandsalat, oder was der DPM 2010 mit den Bändern macht

Es sollte bekannt sein, das der System Center Data Protection Manager 2010 nicht nur auf HDD sichern kann, sondern auch auf Band. Und gerade das kann öfter mal etwas verwirrend sein. Begriffe wie “Offsite bereit”, “Data Co-Location”, “DataSets” und viele mehr. Da wollen wir doch nur wissen, was der DPM mit unseren Bändern macht und wann wir diese aus der Tape-Library nehmen dürfen.

Was auch sicherlich interessant sein dürfte, nach welchen Schema der DPM das nächste Band für die Sicherung auswählt. Fangen wir einfach an, zum Schluss sollten hoffentlich einiges klarer sein.

Data Co-Location

oder auch “Zusammenfassung von Daten auf Band” im deutschen genannt. Dies würde den DPM anweisen, mehrere Schutzgruppen auf ein Band zusammenzufassen, sofern dies möglich ist. Der Standardwert dieser Option ist deaktiviert, somit sichert kann der DPM nur eine Schutzgruppe aufs ein band sichern. Sofern dies jedoch nicht in die Sicherungsstrategie passt, kann man diese Option auch aktivieren um somit mehr Daten pro Band zu sichern.

Aktiviert wird diese Option mit dem folgenden PowerShell CMDlet:

Set-DPMGlobalProperty –DPMServerName Backup -OptimizeTapeUsage $True

In der DPM Konsole sollten wir dann auch die Veränderung sehen.

Sobald diese Option aktiviert wurde, sichert der DPM solange auf ein Band bis dies voll oder “Offsite bereit” ist, aber dazu etwas später mehr. um Data Co-Location zu nutzen, müssen auch einige Bedingungen erfüllt sein.

• Data Co-Location nicht pro Schutzgruppe aktiviert werden, sondern ist für den gesamten Server gültig
• Es können nur Schutzgruppen mit der selben “Beibehaltungsdauer” mittel Data Co-Location auf ein Band gesichert werden
• Verschlüsselte Datasets können nicht mit unverschlüsselten Datasets kombiniert werden

Auswahl der Bänder

Unser DPM Server sucht sich die Bänder nach einer ganz besonderen Reihenfolge aus, wobei sich diese mit aktivierter “Data Co-ocation” etwas ändert.

Standardauswahl

DPM benutzt freie Bänder bevor er auf abgelaufene Bänder zugreift. Die Reihenfolge entsteht aus der Slot Nummer in er das Band enthalten ist, dabei wir bei der höheren Nummer gestartet. Sollte also ein freies Band im Slot 8 und im Slot 5 liegen, wird zuerst das Band aus Slot 8 genommen.

mit aktivierter Data Co-Location

Da es mit dieser Option möglich ist mehrere Schutzgruppen auf ein Band zu schreiben, macht es die Auswahl etwas komplizierter. Es gibt 2 Faktoren die erfüllt werden müssen, damit eine aktuelle Sicherung ihre Datasets auf ein bereits beschriebenes Band, per Data Co-Location hinzufügt.

• Das Ablaufdatum (Ende der Beibehaltungsdauer) des zu sichernden Datasets befindet sich in der folgenden Zeitspanne
• Untere Grenze: ältestes Ablaufdatum aller Datasets am Band – (ältestes Ablaufdatum aller Datasets am Band – aktuelles Datum) * ExpiryToleranceRange
• Obere Grenze: ältestes Ablaufdatum aller Datasets am Band + (ältestes Ablaufdatum aller Datasets am Band – aktuelles Datum) * ExpiryToleranceRange

Rechenbeispiel: Wir nehmen an, das älteste Ablaufdatum eines Datasets am Band ist der 31.01.2012, das aktuelle Datum lautet 16.01.2012. Die ExpiryToleranceRange hat den Standardwert von 17 Prozent

Untere Grenze: 31.1.2012 – ( 31.1.2012 – 16.01.2012 ) * 17% = 31.1.2012 – 15 * 17% = 31.1.2012 – 2,55 = ca. 28.1.2012 12:00 Uhr
Obere Grenze: 31.1.2012 + ( 31.1.2012 – 16.01.2012 ) * 17% = 31.1.2012 + 15 * 17% = 31.1.2012 + 2,55 = ca. 3.2.2012 12:00 Uhr

Jetzt das ganze nochmals in Worte, um die Verwirrung etwas zu mindern. Das älteste Datum ist der 31.1.2012, wir nehmen an es wäre um 23:59. Das Ergebnis zeigt uns eine Differenz von 2,55 Tage, somit ca. 2 1/2 Tage vorher und 2 1/2 Tage danach ist die Zeitspanne. Sollte sich also das Ablaufdatum unseres zu sichernden Datasets in dieser Zeitspanne befinden, wird es mittel Data Co-Location auf diese Band gesichert, vorausgesetzt die nächste Punkt trifft auch noch zu.

• Aktuelle Zeit sollte geringer sein als die jüngste Sicherungszeit eines Datasets am Band + TapeWritePeriodRatio * RetentionRangeOfFirstDatase

Rechenbeispiel: Wir nehmen an das aktuelle Datum lautet 16.1.2012 und die jüngste Sicherungszeit ist 2.1.2012. Die RetentionRangeOfFirstDataset (Beibehaltungsdauer des jüngsten Datasets) ist 1 Woche, also 168 Stunden. TapeWritePeriodRatio hat einen Standardwert von 0,15 (wird in Tagen angegeben und kann 0 – 1 als Wert aufweisen, 015 = 3,6 Stunden)

2.1.2012 + 3,6 * 168 = 2.1.2012 + 604 (ca. 25 Tage) = 27.1.2012

Da wir heute den 16.1 2012 haben, würde es in diesem Beispiel mit der Data Co-Location nicht klappen.

Beide Faktoren müssen eintreten um eine Data Co-Location zu erreichen.

TapeWritePeriodRatio – Gibt eine Anzahl an Tage an, und kann einen Wert zwischen 1 und 0 haben. Standardmäßig ist der Wert 0.15 (3,6 Stunden) vergeben. Der Wert kann per PowerShell CMDlet gesetzt werden

Set-DPMGlobalProperty -DPMServerName backup -TapeWritePeriodRatio 0.01

ExpiryToleranceRange – Zeigt einen Schwellwert in Format einer Zeitspanne, welche den Ablauf eines Wiederherstellungspunktes definiert. dieser Wert ist Standardmäßig auf 17% gesetzt und kann mittels Registry geändert werden, Eintrag muss erstellt werden.

DWORD: HKLM\Software\Microsoft\Microsoft Data Protection Manager\1.0\Colocation

Offsite bereit

Der Wert “Offsite bereit “oder “Offsite ready” betitelt ein Band das aus der Station entfernt und archiviert werden kann, auch hier gibt es einige Faktoren die diesen Status auslösen können.

• Das Band ist voll
• Eines der Datasets ist abgelaufen
• Write-Period Ratio wurde erreicht (jüngste Sicherungszeit eines Datasets + TapeWritePeriodRatio)
• Bei nicht aktivierter Data Co-Location ist ein Band nach erfolgter Sicherung “Offsite ready”

 

Eines noch zum Schluss, dieser Beitrag hat sehr viel Arbeit gekostet, da diese Information nur in Englisch zur Verfügung stehen, und vor allem ohne Rechenbeispiele. Ich hoffe hier keine Fehler gemacht zu haben, jedoch klingen die Ergebnisse für mich logisch, somit kann nicht sehr viel falsch sein.

Hier noch ein paar Quellen: http://technet.microsoft.com/en-us/library/cc964296.aspx, http://technet.microsoft.com/en-us/library/cc627336.aspx, http://social.technet.microsoft.com/Forums/en-US/dataprotectionmanager/thread/0fb0e976-2dce-4bae-950b-f50e43d09309

Michael Seidl