| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision |
| tsm-backup_mit_linux [2010/07/22 16:43] – Hinweis/Warnung "Vorgehen nach Platten-Crash" neu dazu bewi | tsm-backup_mit_linux [2010/07/22 17:49] – bewi |
|---|
| Es gibt auch noch die Funktionen **Archive** und **Retrieve**; der wesentliche Unterschied zu Backup und Restore besteht darin, dass ein Backup nach einem Sicherungslauf dem Benutzer die Möglichkeit geben soll, sein System wieder so herzustellen wie es zum Zeitpunk des Sicherungslaufs war. D.h. die Dateien werdem (mehr oder weniger) 1:1 abgebildet; gelöschte Dateien auf dem Knoten auch auf dem Server wieder gelöscht. Im Gegensatz dazu können nach dem Archivieren die lokalen Dateien auf dem Klienten gelöscht werden, die Archive verbleiben auf dem TSM-Server. | Es gibt auch noch die Funktionen **Archive** und **Retrieve**; der wesentliche Unterschied zu Backup und Restore besteht darin, dass ein Backup nach einem Sicherungslauf dem Benutzer die Möglichkeit geben soll, sein System wieder so herzustellen wie es zum Zeitpunk des Sicherungslaufs war. D.h. die Dateien werdem (mehr oder weniger) 1:1 abgebildet; gelöschte Dateien auf dem Knoten auch auf dem Server wieder gelöscht. Im Gegensatz dazu können nach dem Archivieren die lokalen Dateien auf dem Klienten gelöscht werden, die Archive verbleiben auf dem TSM-Server. |
| |
| Bei einem Sicherungslauf werden deshalb auf dem Knoten nicht mehr vorhanden Dateien auf dem TSM-Server ebenfalls gelöscht oder genauer als "inaktiv" markiert; erst nach einer gewissen Zeit (derzeit nach 30 Tagen) werden sie ganz entfernt. Innerhalb dieser Frist kann man sie also auch wieder restaurieren. | Bei einem Sicherungslauf (Backup) werden deshalb auf dem Knoten nicht mehr vorhandene Dateien auf dem TSM-Server ebenfalls gelöscht oder genauer als "inaktiv" markiert; erst nach einer gewissen Zeit (derzeit nach 30 Tagen) werden sie ganz entfernt. Innerhalb dieser Frist kann man sie also auch wieder restaurieren. |
| |
| <note important>**ACHTUNG: Vorsicht nach einem Platten-Crash oder versehentlichen Lösch-Aktionen !**</note> | <note important>**ACHTUNG: Vorsicht nach einem Platten-Crash oder versehentlichen Lösch-Aktionen !**</note> |
| Aus der zuvor beschriebenen TSM-Arbeitsweise ergibt sich folgene **WARNUNG**: | Aus der zuvor beschriebenen TSM-Arbeitsweise ergibt sich folgende **WARNUNG**: |
| Nach einem Platten-Crash oder nach versehentlichen Lösch-Aktionen sollte als allererste Reaktion jegliche automatisch oder manuell initiierte Sicherung unterbunden werden, damit der Zustand der letzten Sicherung auf dem TSM-Sicherungssystem nicht mehr verändert wird ! Also TSM-Scheduler oder TSM-relevante Cron-Jobs anhalten bzw. deaktivieren ! | |
| |
| | |
| | Nach einem Platten-Crash oder nach versehentlichen Lösch-Aktionen sollte als allererste Reaktion **jegliche** automatisch oder manuell initiierte **Sicherung unterbunden** werden, damit der Zustand der letzten Sicherung auf dem TSM-Sicherungssystem nicht mehr verändert wird ! Also TSM-Scheduler oder TSM-relevante Cron-Jobs anhalten bzw. deaktivieren ! |
| | |
| | Nicht vergessen: nach Restaurierung der Daten die automatische Sicherung wieder aktivieren. |
| | |
| | Bitte bedenken Sie auch die **Restaurierungszeit** größerer Datenmengen, und richten Sie die (lokale) Redundanz Ihrer Daten entsprechend der maximal akzeptierten Restaurierungsdauer ein. Bei einer 100-MBit-Netzwerkanbindung benötigt die Übertragung eines Gigabytes (10^9) |
| | ca. zwei Minuten, ein Terabyte (10^12) schon mehr als 32 Stunden .... und das auch nur bei optimalsten Bedingungen; d.h. unter der Voraussetzung, dass die (geteilten) Resourcen des TSM-Servers ausreichen, um Ihre Netzwerkverbindung auszulasten, wobei Letztere auch nicht immer exklusiv zur Verfügung stehen wird. |
| |
| |
