| Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:services:storage_services:backup:tsm:anleitungen:memoryefficient [2016/06/14 10:16] – angelegt bnachtw | de:services:storage_services:backup:tsm:anleitungen:memoryefficient [2023/05/09 13:52] (aktuell) – [Abhilfe] bnachtw |
|---|
| | ====== Backup-Optimierung mit MEMORYEFficientbackup ====== |
| | ===== Hintergrund ===== |
| | TSM^H ISP macht in der Regel eine inkrementelle Sicherung. Hierzu muss der Client die lokal vorhandenen Daten mit jenen, die bereits auf dem Server gesichert sind vergleichen. Dies geschieht dadurch, dass der Client vom Server eine Liste aller gesicherten Dateien abfordert (Excurs: daher passiert häufig am Anfang einer Sicherung scheinbar auch nichts: der Server überträgt diese Daten zum Client). Durch den //incremental forever//-Ansatz erstellt der Server die Liste so, als wäre das letzte Backup eine Vollsicherung gewesen, um dem Clienten den direkten Vergleich ohne Betrachtung der tatsächlichen Sicherungszeitpunkte zu ermöglichen. |
| |
| | Aus dieser Liste baut der Client einen //virtuellen// Dateibaum des Backups auf und vergleicht diesen mit dem tatsächlichen, auf den lokalen Platten vorhanden Dateibaum. **In der Regel wird dieser virtuelle Dateibaum im Hauptspeicher erstellt und benötigt entsprechend viel RAM**. Gerade bei sehr großen Dateisystemen und/oder bei mehreren lokalen Platten/Partitionen kann der Hauptspeicherbedarf so groß werden, dass der Rechner die Auslagerungsdatei nutzt (Windows) bzw. zu swappen beginnt (Unices). Dabei wird die **Leistung / der Durchsatz erheblich reduziert**. |
| | |
| | ===== Abhilfe ===== |
| | TSM^H ISP bietet Möglichkeiten, die Leistung zu optimieren, neben allgemeinen Empfehlungen (z.B. RAM aufstocken, mittels //Exclude.Dir// die Anzahl der Datei zu reduzieren) auch Optionen, die den virtuellen Dateibaum teilen und/oder diesen auf Festplatte auslagern -- und dabei wesentlich effizienter als das Swappen sind. |
| | |
| | Die Optimierung wird über die Option //MEMORYEFficientbackup [Yes|DISKCACHEMethod]// gesteuert (einzutragen in die //dsm.sys// bzw. //dsm.opt//) und erlaubt zwei Varianten: |
| | * ''MEMORYEFficientbackup Yes''\\ sofern mehrere //FILESPACES// existieren, werden die virtuellen Dateibäume nacheinander aufgebaut und somit weniger Hauptspeicher gleichzeitig genutzt.\\ __ABER__: Diese Einstellung macht die Nutzung von mehreren parallelen Datenströmen zunichte, da immer nur ein Filespace (und damit ein Datenstrom) bearbeitet wird. Sie ist auch **wirkungslos, wenn nur ein Filespace** existiert. |
| | * ''MEMORYEFficientbackup DISKCACHEMethod'' und ''DISKCACHELocation <PFAD>''\\ Der virtuelle Dateibaum wird in einen -- mit dem Parameter //DISKCACHELocation// angegebenen -- Pfad ausgelagert. Dieser sollte |
| | * selbst nicht gesichert werden. Also per //exclude.dir <PFAD>// ausgeschlossen werden, am besten sogar auf eine eigene Festplatte ausgelagert werden, mindestens aber in eine eigene Partition gelegt werden. |
| | * auf eher performantem Speicher liegen, also nicht auf einem NFS-/CIFS-Share vom //"alten, längst abgeschriebenem Fileserver"//. |
| | * z.B.\\ ''DISKCACHELocation "D:TSMCache\NodeX\"''\\ ''MEMORYEFficientbackup DISKCACHEMethod'' |
| | * **Hinweis:** Bei Windows-Clients ggf. den Pfad mittels ''"'' maskieren |
| | |
| | **WICHTIG**:\\ |
| | Der Platzbedarf für die Auslagerung des Dateibaumes kann erheblich sein, also bitte anfangs und auch regelmäßig prüfen, ob der zur Verfügung gestellte Platz ausreicht! |
