Technical Whitepaper

Backup und Restore einer DSM Infrastruktur

"Desaster Recovery"

Aktualisierung: 30.10.2012

Inhaltsverzeichnis
1

Haftungsausschluss

Einleitung und bersicht

Allgemeine Grundstze

3.1

Wiederherstellung testen

3.2

Datenkonsistenz zwischen Datenbank (DSMDB) und Depots sicherstellen

3.3

Den Cache der beteiligten Systeme aktualisieren

Sicherungsrelevante Daten

4.1

Datenbank des Business Logic Servers (DSMDB)

4.2

Central-Depot

4.3

Weitere Depots mit Quell-Repositories

4.4

Depots ohne Quell-Repositories

4.5

Management Points

4.6

Datenbank des Business Logic Proxys (BLP-Datenbank)

Sicherungsstrategie

5.1

Beispiel fr einen idealisierten Sicherungsplan

10

5.2

Kriterien fr die Anpassungen des idealisierten Sicherungsplans

10

Datenwiederherstellung

11

Ausfall einer der Systemkomponenten

11

7.1

Ausfall von Datenbank (DSMDB), Central-Depot oder Depot mit Quell-Repository

11

7.1.1 Auslsen einer Komplettsynchronisation des DSMDB-Caches aller Clients

13

7.1.2 System Crash zwischen Update der DSM-Umgebung und Datensicherung

13

7.2

Ausfall eines Depots ohne Quell-Repository

13

7.3

Ausfall eines Management Points

14

7.3.1 Wiederherstellen der Funktionalitt eines Business Logic Server (BLS)

14

7.3.2 Wiederherstellen der Funktionalitt eines Business Logic Proxy (BLP)

14

7.3.3 Wiederherstellen der Funktionalitt eines FrontRange Auxiliary Service

15

7.3.4 Wiederherstellen der Funktionalitt eines Patch Management Service

15

7.3.5 Wiederherstellen der Funktionalitt eines Client-Proxy

15

7.3.6 Wiederherstellen der Funktionalitt eines OSD-Proxy

15

7.3.7 Wiederherstellen der Funktionalitt Distributionsdienst

16

7.3.8 Wiederherstellen der Funktionalitt DSM Extended Reporting

16

Alternative Sicherungsmethoden
8.1

Cold Stand-by Systeme

17
17

Seite 3

8.2

Constant-Backup

17

8.3

Virtualisierung und Snapshotverfahren

17

8.4

Einsatz von Clusterlsungen oder HA-SAN-Lsungen

17

ber FrontRange Solutions

18

Seite 4

Haftungsausschluss
Copyright 2012 FrontRange Solutions USA Inc. Alle Rechte vorbehalten.
GoldMine, HEAT, NetInstall, DeviceWall und sonstige Produkte, Marken und Handelsmarken
von FrontRange Solutions sind Eigentum von FrontRange Solutions USA Inc. und/oder den
angeschlossenen Unternehmen in den Vereinigten Staaten und/oder anderen Lndern. Sonstige
Produkte, Marken und Handelsmarken sind das Eigentum der jeweiligen
Eigentmer/Unternehmen.
DIE BENUTZUNG DER IN DIESEM DOKUMENT BESCHRIEBENEN SOFTWARE UND DER
ZUGEHRIGEN BENUTZERDOKUMENTATION UNTERLIEGT DEN BESTIMMUNGEN DER
GELTENDEN ENDBENUTZER-LIZENZVEREINBARUNG (EULA).
Die Angaben in diesem Dokument erfolgen ohne Gewhr. FrontRange schliet, soweit
gesetzlich zulssig, jede ausdrckliche oder stillschweigende Garantiebernahme aus und
bernimmt keine Garantien fr Qualitt, Fehlerfreiheit, Marktgngigkeit, Eignung fr einen
bestimmten Zweck, gewerbliche Schutzrechte und deren Einhaltung; darber hinaus haften
FrontRange oder seine Lieferanten in keinem Fall fr Schden irgendeiner Art, einschlielich
direkter, indirekter, zuflliger Schden oder Folgeschden, Gewinnverlust, Datenverlust oder
spezieller Schden, auch bei Hinweis darauf, dass es zu derartigen Schden kommen kann.

Seite 5

Einleitung und bersicht

Dieses Dokument beschreibt Grundstze und Vorgehensweisen fr das Backup und Restore
einer DSM-Infrastruktur. In diesem Dokument wird davon ausgegangen, dass sich CentralDepot, die Datenbank (DSMDB), sowie der Management Point mit dem Business Logic Server
(BLS) auf unterschiedlichen Servern befinden.
Der in diesem Dokument erluterte Sicherungsplan muss an die eigene DSM-Umgebung und
die Vorgaben des Managements individuell angepasst werden. Die Anforderungen ergeben
sich aus folgenden zwei Kernfragen: Wie schnell muss das System wiederhergestellt sein? Wie
gro darf der Datenverlust sein?
Aufgrund der Vielzahl an Mglichkeiten und Lsungen knnen wir hier nur grundlegende
Vorgehensweisen beschreiben, die sie auf ihre jeweils verfgbaren Tools und
Sicherungsmechanismen anpassen mssen.
Diese Vorgehensweise kann ab der Version DSM 7.1 angewendet werden.

Allgemeine Grundstze
Wir unterscheiden 3 Grnde, die zu einer Wiederherstellung fhren knnen:
Wiederherstellung eines frheren oder des letzten funktionierenden Datenstandes
(Datenbank und/oder Massendaten) nach einem Software- oder Hardwarefehler
Wiederherstellung einer DSM Infrastrukturkomponente (Depot, Management Point,
Datenbank) nach einem permanenten Systemausfall oder Neuinstallation des Systems
Rollback von Infrastruktur und Daten nach einer fehlgeschlagenen Systemnderung oder
Update
Die Sicherungsstrategie und Zeitplanung ist von entscheidender Bedeutung fr die Frage,
welche Menge an Daten sie im Falle eines Systemfehlers verlieren. Passen sie die weiter unten
beschriebenen Beispiel-Zeiten so an, dass ihre Anforderungen diesbezglich eingehalten
werden knnen. Vermeiden sie jedoch unntig kurze Sicherungsintervalle, da diese ihr System
vermehrt belasten und vor allem Datenmengen erzeugen, deren Speicherung ebenfalls
entsprechende Kosten verursachen.

3.1

Wiederherstellung testen
Obwohl regelmig darauf hingewiesen wird, ist es wohl einer der am meisten
vernachlssigten Grundstze im Betrieb einer IT-Infrastruktur: Ein Backup ist nur so gut wie
seine Wiederherstellung. Testen sie deshalb unbedingt ihr eingerichtetes Backup auf
Wiederherstellbarkeit der Datentrger und Funktionsfhigkeit ihres Restore Workflows!

Seite 6

3.2

Datenkonsistenz zwischen Datenbank (DSMDB) und Depots sicherstellen

Um eine konsistente Datenwiederherstellung nach einem Serverausfall oder Datenverlust zu
gewhrleisten, kommt es darauf an
regelmig die Datenbank (DSMDB) zu sichern, sowie zustzlich
den dazu passenden Stand der Massendaten aller Depots, die Quell-Repositories
enthalten.
Die in der Datenbank (DSMDB) gespeicherten Revisionsinformationen der Software-Pakete
mssen nmlich zum tatschlichen Revisions-Stand im Dateisystem passen.
Es ist deshalb zwingend notwendig, zu jedem Sicherungsstand der Datenbank (DSMDB) auch
einen mglichst zeitgleichen Sicherungsstand des Central-Depots und aller weiteren QuellRepositories vorzuhalten, da anderenfalls eine Wiederherstellung der Datenbank (DSMDB) zu
Inkonsistenzen im System und einem unerwarteten Verhalten bei der Distribution und
Installation fhren kann.

3.3

Den Cache der beteiligten Systeme aktualisieren

Verschiedene Komponenten der DSM Infrastruktur greifen nicht direkt auf die Daten von
DSMDB und Repositories zu, sondern verwenden lokale Zwischenspeicher. Der Cache dieser
Systeme muss nach einer Wiederherstellung auf den Stand der DSMDB gebracht werden. Dazu
ist nach jeder Wiederherstellung der DSMDB die DSMDB-Guid innerhalb der Datenbank zu
ndern, was eine vollstndige Synchronisation des Cache auslst.

Sicherungsrelevante Daten
4.1

Datenbank des Business Logic Servers (DSMDB)

Die gesamte Datenbank des BLS (DSMDB) ist zu sichern. Richten Sie dazu ein Backup der
Datenbank DSMDB auf Ihrem SQL-Server ein.

4.2

Central-Depot
Fr das Central-Depot ist der Inhalt des DSM-Shares (\\Servername\DSM$) zu sichern.
Wenn das Quell-Repository als Work\Install in der Konfigurationsdatenbank eingestellt
wurde(Voreinstellung), muss das Verzeichnis .\Install\Repository-Name\ nicht gesichert
werden. Es wird durch den Distributionsdienst nach einer Datenwiederherstellung neu
befllt.
Wenn das Quell-Repository als Install\Install in der Konfigurationsdatenbank eingestellt
wurde, muss zustzlich das Verzeichnis .\Install\Repository-Name\ gesichert werden.
Quell-Repositories sind diejenigen Repositories, in denen die Massendaten abgelegt
werden, die bei der Paketierung von Software anfallen.

Seite 7

4.3

Weitere Depots mit Quell-Repositories

Die Work-Verzeichnisse der Quell-Repositories sind zu sichern. Sie befinden sich auf dem
zugeordneten Depot-Share (\\Servername\DSM$) im Unterverzeichnis .\Work\Repository-Name\.
Wenn das Quell-Repository als Work\Install in der Konfigurationsdatenbank eingestellt
wurde(Voreinstellung), muss das Verzeichnis .\Install\Repository-Name\ nicht gesichert
werden. Es wird durch den Distributionsdienst nach einer Datenwiederherstellung neu
befllt.
Wenn das Quell-Repository als Install\Install in der Konfigurationsdatenbank eingestellt
wurde, muss zustzlich das Verzeichnis .\Install\Repository-Name\ gesichert werden.

4.4

Depots ohne Quell-Repositories

Depots ohne Quell-Repositories mssen nicht gesichert werden. Alle relevanten Daten werden
nach dem Neueinrichten des Depots durch den Distributionsdienst neu befllt.

4.5

Management Points
Management Points und deren Applikationen bentigen keine Datensicherung. Sie knnen
nach einem Ausfall des entsprechenden Servers mitsamt ihrer Applikationen neu installiert
werden.

4.6

Datenbank des Business Logic Proxys (BLP-Datenbank)

Die Datenbank des BLP bentigt keine Datensicherung, da Sie nach dem Ausfall des BLS oder
BLPs in jedem Falle mit dem Backup der DSMDB wieder hergestellt werden muss.

Sicherungsstrategie
Ausgangspunkt ist ein Vollbackup von Datenbank, Central Depot und aller Depots mit QuellRepositories.
Ein Backup des Transaktionsprotokolls erfordert, dass das Recovery Model der
Datenbank auf "Full" gestellt ist. Neuinstallationen vor enteo v6.2 wurden
standardmig mit Recovery Model "Full" aufgesetzt. Seit der Version v6.2 oder hher
wird das Recovery Model "Simple" verwendet. Daher ist es notwendig, dass Sie das
Recovery Model auf "Full" umstellen.
Die folgende Grafik erlutert Ihnen das prinzipielle Schema einer Sicherungsstrategie anhand
eines wchentlichen Sicherungsplans.

Seite 8

Abbildung 1:Sicherung von Daten vor SystemCrash

Seite 9

5.1

Beispiel fr einen idealisierten Sicherungsplan

Voll-Backup: Wchentlich (z.B. Sonntags 22:00 Uhr)
Datenbank (DSMDB)

Backup des Transaktionsprotokolls mit Abschneiden des

Transaktionsprotokolls
Direkt im Anschluss danach ein Vollbackup der DSMDB

Central-Depot

Vollbackup des Central-Depots \\SERVER\DSM$ ohne 'InstallVerzeichnis'

alle Depots mit QuellRepositories

Vollbackup der Quell-Repository-Verzeichnisse

\\SERVER\DSM$\Work\Repository-Name\

Differenzielles Backup: Tglich (oder je nach Bedarf alle 2-3 Tage; z.B. Montag Samstag 22:00
Uhr)

Datenbank (DSMDB)

Backup des Transaktionsprotokolls mit Abschneiden des

Transaktionsprotokolls
Direkt im Anschluss danach ein differenzielles Backup der
DSMDB

Central-Depot

Backup* des Central-Depots \\SERVER\DSM$ ohne 'InstallVerzeichnis'

alle Depots mit QuellRepositories

Backup* der Quell-Repository-Verzeichnisse

\\SERVER\DSM$\Work\Repository-Name\

Inkrementelles Backup: Im Intervall von n Stunden zwischen den tglichen Sicherungen

Datenbank (DSMDB)

Backup des Transaktionsprotokolls ohne Abschneiden des

Transaktionsprotokolls

Central-Depot

Backup* des Central-Depots \\SERVER\DSM$ ohne 'InstallVerzeichnis'

alle Depots mit QuellRepositories

Backup* der Quell-Repository-Verzeichnisse

\\SERVER\DSM$\Work\Repository-Name\

* Volles/Differenzielles/Inkrementelles Backup je nach nderungsrate im Depot / verwendeter

Backup-Software

5.2

Kriterien fr die Anpassungen des idealisierten Sicherungsplans

Da in der Regel ein groer Teil des Inhalts des Central-Depots sowie der Repositories statisch
ist, berwiegend Daten (neue Pakete oder Revisionen) hinzukommen und nur wenige Dateien
kontinuierlich verndert werden, ist ein Vollbackup in greren Abstnden (je nach
nderungsaktivitt in der Paketierung im Abstand von 1 bis 3 Wochen) ausreichend.
Mit jeder Vollsicherung der Datenbank (DSMDB) sollte ein gleichzeitiges differenzielles Backup
des Central-Depots, sowie aller Quell-Repositories erstellt werden.

Seite 10

Sind krzere Wiederherstellungsintervalle erforderlich, ist ein inkrementelles Backup des

Central-Depots und aller Repositories zeitgleich mit der Sicherung des DSMDB Transaktionslogs
zu empfehlen.
Die zu sichernde Datenmenge wird durch diese Strategie deutlich reduziert und garantiert
trotzdem eine Wiederherstellungsmglichkeit in einem entsprechend kurzen Intervall.

Datenwiederherstellung
Abhngig vom ausgefallenen System ist eine Wiederherstellung von Daten notwendig. Im
Nachfolgenden ist fr jede Einzelkomponente ein Vorgehen beschrieben, welches das
Gesamtsystem wieder in einen konsistenten Zustand bringt.

Abbildung 2: Wiederherstellung von Daten nach System Crash

Ausfall einer der Systemkomponenten

7.1

Ausfall von Datenbank (DSMDB), Central-Depot oder Depot mit QuellRepository

Bei einem Ausfall einer dieser Systemkomponenten ist grundstzlich eine Wiederherstellung
aller dieser Systeme vorzunehmen. Nur dies gewhrleistet eine Konsistenz zwischen den
Paketinformationen der Datenbank und den Paketinformationen in den Massendaten.

Seite 11

Und so fhren Sie eine konsistente Datenwiederherstellung durch:

1. Stoppen Sie die Distributionsdienste, die auf die Depots mit Quell-Repositories oder auf
das Central-Depot zugreifen.
2. Stoppen Sie alle FrontRange DSM-Dienste und Management-Point Webseiten auf allen
BLS und den ggf. vorhandenen BLPs.
3. Ermitteln Sie die letzten zeitgleichen Sicherungen der Systemkomponenten
Datenbank (DSMDB)
Central-Depot und
aller Depots mit Quell-Repositories
4. Stellen Sie die Daten der Datenbank-Sicherung (DSMDB) wieder her. In Bezug auf den
Beispielsicherungsplan restaurieren Sie dazu:
Die letzte erfolgreiche Vollsicherung der Datenbank.
Die letzte erfolgreiche differenzielle Sicherung der Datenbank nach der
Vollsicherung und vor dem Ausfall des Systems.
Alle Sicherungen der Transaktionsprotokolle ab der letzten erfolgreichen
differenziellen Sicherung bis zum Zeitpunkt der letzten Sicherung der Massendaten
vor dem Ausfall des Systems.
5. Lschen Sie die Repository-Verzeichnisse (.\work\Repository-Name\und ggf. .\install\RepositoryName\) des Central-Depots, sowie aller Depots mit Quell-Repositories (s. Abschnitt
Sicherungsrelevante Daten).
6. Restaurieren Sie die Dateien des Central-Depots (s. Abschnitt Sicherungsrelevante Daten).
Benutzen Sie dazu die Daten des gleichen Zeitpunkts, welchen Sie fr die DSMDB
gewhlt haben. In Bezug auf den Beispielsicherungsplan restaurieren Sie dazu:
Die letzte erfolgreiche Vollsicherung des Central-Depots.
Die letzte erfolgreiche differenzielle Sicherung des Central-Depots nach der
Vollsicherung und vor dem Ausfall des Systems.
Alle inkrementellen Sicherungen des Central-Depots ab der letzten erfolgreichen
differenziellen Sicherung bis zum Ausfall des Systems.
7. Restaurieren Sie die Repository-Verzeichnisse (.\work\Repository-Name\und ggf.
.\install\Repository-Name\) aller Depots mit Quell-Repositories. Restaurieren Sie dazu die Daten
des gleichen Zeitpunkts, welchen Sie fr die DSMDB gewhlt haben. In Bezug auf den
Beispielsicherungsplan restaurieren Sie dazu:
Die letzte erfolgreiche Vollsicherung des Repository-Verzeichnisses.
Die letzte erfolgreiche differenzielle Sicherung des Repository-Verzeichnisses nach
der Vollsicherung und vor dem Ausfall des Systems.
Alle inkrementellen Sicherungen des Repository-Verzeichnisses ab der letzten
erfolgreichen differenziellen Sicherung bis zum Ausfall des Systems.
8. Starten Sie die Distributionsdienste.
9. Aktualisieren Sie die Client-Binaries, indem Sie die Depots in Ihrer DSM-Umgebung mit
Hilfe des NIVerChk aktualisieren.

Seite 12

10. Veranlassen Sie eine Komplettsynchronisation aller Clients bezglich des DSMDB-Caches.
(siehe Kapitel "Auslsen einer Komplettsynchronisation des DSMDB-Caches aller Clients")
11. Bei Einsatz von BLPs mssen diese mit einem neuen Dump (einer aktuellen Sicherung) der
DSMDB neu installiert werden. Andernfalls wird die Datenbankreplikation der BLPs nicht
mehr funktionieren. Hierzu steht Ihnen die Featurebeschreibung in der Online
Dokumentation zur Verfgung.
12. Starten Sie alle FrontRange DSM-Dienste und Management-Point Webseiten auf allen BLS
und den ggf. vorhandenen BLPs.
13. berprfen Sie den Replikationsstatus der BLPs.

7.1.1 Auslsen einer Komplettsynchronisation des DSMDB-Caches aller Clients

Nach einer Wiederherstellung der Datenbank (DSMDB) ist es notwendig, alle Clients zu einer
Komplettsynchronisierung ihres DSMDB-Caches zu zwingen. Dazu muss der Wert des Eintrages
CmdbGuid in der Tabelle CMSY_LOCALCONFIG der DSMDB auf eine neu erstellte GUID
gesetzt werden.
Zur Erstellung einer neuen GUID knnen Sie z.B. die Webseite http://createguid.com/ benutzen.
Beachten Sie beim Eintragen der GUID, dass diese im Format {12345678-1234-1234-1234123456789012} eingegeben werden muss.

7.1.2 System Crash zwischen Update der DSM-Umgebung und Datensicherung

Gehen Sie in diesem Fall wie folgt vor:
Daten wiederherstellen (s.o.)
Primary BLS auf dem zugehrigen Build-Stand neu aufsetzen
Update der DSM-Umgebung wiederholen
Wenn zum Beispiel das Backup der Datenbank/Depot auf Stand 1635, der Management Point
jedoch bereits auf 1645 aktualisiert ist, und dann die Datenbank crashed, dann muss zuerst der
Management Point neu aufgesetzt werden (zurck auf 1635) um danach das Update der
Binaries erneut einzuspielen.
Die Konsequenz ist, dass nach jedem erfolgreichen Produkt-Update / Patch / Hotfix ein
erfolgreiches Datenbank- und Depot-Backup durchgefhrt werden muss.

7.2

Ausfall eines Depots ohne Quell-Repository

Ein Depot ohne Quell-Repository enthlt nur Daten bergeordneter Repositories, sowie die
Client-Binaries. Ein solches Depot kann nach einem Ausfall ohne Datenverlust neu eingerichtet
werden, es ist keinerlei Zugriff auf Backup-Medien erforderlich.
1. Stellen Sie die Serverfunktionalitt wieder zur Verfgung und richten Sie die Freigabe
des Depot-Verzeichnisses wieder ein.
2. ber die DSMC mssen Sie die Client-Dateien des Depots aktualisieren.
Markieren Sie das entsprechende Depot im Bereich Manage Infrastructure.
Drcken Sie auf Dateien aktualisieren auf der Registerkarte Tasks.

Seite 13

3. Die fehlenden Paketdateien werden durch den zustndigen Distributionsdienst neu

bereitgestellt.

7.3

Ausfall eines Management Points

Je nach installierter Applikation innerhalb des betroffenen Management Points sind die
unterschiedlichen Voraussetzungen auf dem Serversystem wiederherzustellen (IIS, .netFramework). Die Reinstallation der Management-Applikationen wird im Folgenden einzeln
beschrieben.
Es empfiehlt sich, vor Konfigurationsarbeiten eine manuelle Sicherung der Dateien
nicfglcl.ncp und nicfgsrv.ncp aus dem Share des Central-Depots vorzunehmen, so dass eine
Fehlkonfiguration schnellstmglich wieder rckgngig gemacht werden kann.

7.3.1 Wiederherstellen der Funktionalitt eines Business Logic Server (BLS)

Die Wiederherstellung der BLS-Funktionalitt entspricht einer Neuinstallation des kompletten
Management Points, welcher die Applikation Business Logic Server enthlt. Bitte halten Sie
deshalb alle Konfigurationswerte, welche sie zur Installation bentigen bereit. Die
Ausfhrungen in diesem Abschnitt gelten nicht, wenn Sie das Multi-BLS-Feature einsetzen.
Einzelheiten zu diesem Fall finden Sie in der Online-Hilfe.
1. Melden Sie sich an dem Server an, welcher die Applikation BLS wieder erhalten soll.
2. Starten Sie die DSMC von einem Depot-Share.
3. In der Infrastruktur-Ansicht sperren Sie den Zugriff auf die Konfiguration.
4. Entfernen Sie den Management Point, welcher die Management-Applikation BLS enthlt.
(Im Root der Infrastruktur-Konfiguration)
5. Der Assistent entfernt nun noch ggf. vorhandene Applikationen vom Server.
Fehlermeldungen knnen dabei erscheinen, wenn die Applikationen nicht mehr auf dem
Server vorhanden sind. Diese Fehlermeldungen knnen in diesem Fall ignoriert werden.
6. Speichern sie die Konfiguration.
7. Kontrollieren Sie den Wert des Tabelleneintrages InstallationMode in der Tabelle
CMSY_LOCALCONFIG der Datenbank (DSMDB) und setzen Sie ihn auf True.
8. Fgen Sie einen neuen Management Point in der Organisationsebene hinzu und whlen
Sie die Applikationen aus, welche der zuvor gelschte Management Point besa. (u.a. die
Applikation DSM Business Logic Server fr die Funktionalitt BLS)
9. Der Assistent fhrt sie durch die Neuinstallation der Management-Applikationen.
10. Sichern und entsperren Sie die Infrastrukturkonfiguration.

7.3.2 Wiederherstellen der Funktionalitt eines Business Logic Proxy (BLP)

Die Wiederherstellung eines BLPs entspricht der Neuinstallation des Management Points mit
der Applikation DSM Business Logic Proxy. Lschen Sie den Management Point aus der
Infrastrukturkonfiguration und installieren Sie danach den Management Point neu.
Sollte eine Wiederherstellung der Datenbank (DSMDB) des BLPs notwendig sein, so mssen
diese BLPs mit einem neuen Dump (einer aktuellen Sicherung) der DSMDB neu installiert
werden. Andernfalls wird die Datenbankreplikation der BLPs nicht mehr funktionieren.

Seite 14

Hierzu steht Ihnen die Featurebeschreibung "Backup und Restore eines Business Logic Proxy
(BLP)" in der Online Dokumentation zur Verfgung.

7.3.3 Wiederherstellen der Funktionalitt eines FrontRange Auxiliary Service

1. Starten Sie die DSMC von einem Depot-Share
2. In der Infrastruktur-Ansicht sperren Sie den Zugriff auf die Konfiguration
3. ffnen Sie die Eigenschaften des vom Ausfall betroffenen Management Points, welcher
die Management Point Applikation FrontRange Auxiliary Service enthlt.
4. Deinstallieren Sie die Management Point Applikation FrontRange Auxiliary Service
5. Der Assistent entfernt nun noch ggf. vorhandene Applikationen vom Server.
Fehlermeldungen knnen dabei erscheinen, wenn die Applikationen nicht mehr auf dem
Server vorhanden sind. Diese Fehlermeldungen knnen in diesem Fall ignoriert werden.
6. Installieren Sie die Management Point Applikation FrontRange Auxiliary Service.
7. Sichern und entsperren Sie die Infrastrukturkonfiguration.

7.3.4 Wiederherstellen der Funktionalitt eines Patch Management Service

1. Starten Sie die DSMC von einem Depot-Share
2. In der Infrastruktur-Ansicht sperren Sie den Zugriff auf die Konfiguration
3. ffnen Sie die Eigenschaften des vom Ausfall betroffenen Management Points, welcher
die Management Point Applikation FrontRange Patch Management Service enthlt.
4. Deinstallieren Sie die Management Point Applikation FrontRange Patch Management
Service
5. Der Assistent entfernt nun noch ggf. vorhandene Applikationen vom Server.
Fehlermeldungen knnen dabei erscheinen, wenn die Applikationen nicht mehr auf dem
Server vorhanden sind. Diese Fehlermeldungen knnen in diesem Fall ignoriert werden.
6. Installieren Sie die Management Point Applikation FrontRange Patch Management
Service
7. Sichern und entsperren Sie die Infrastrukturkonfiguration.

7.3.5 Wiederherstellen der Funktionalitt eines Client-Proxy

1. Starten Sie die DSMC von einem Depot-Share
2. In der Infrastruktur-Ansicht sperren Sie den Zugriff auf die Konfiguration
3. ffnen Sie die Eigenschaften des vom Ausfall betroffenen Management Points, welcher
die Management Point Applikation Client Proxy enthielt.
4. Deinstallieren Sie die Management Point Applikation DSMClient Proxy
5. Der Assistent entfernt nun noch ggf. vorhandene Applikationen vom Server.
Fehlermeldungen knnen dabei erscheinen, wenn die Applikationen nicht mehr auf dem
Server vorhanden sind. Diese Fehlermeldungen knnen in diesem Fall ignoriert werden.
6. Installieren Sie die Management Point Applikation DSMClient Proxy
7. Sichern und entsperren Sie die Infrastrukturkonfiguration.

7.3.6 Wiederherstellen der Funktionalitt eines OSD-Proxy

1. Starten Sie die DSMC von einem Depot-Share
2. In der Infrastruktur-Ansicht sperren Sie den Zugriff auf die Konfiguration

Seite 15

3. ffnen Sie die Eigenschaften des vom Ausfall betroffenen Management Points, welcher
die Management Point Applikation OSD Proxy enthielt.
4. Deinstallieren Sie die Management Point Applikation OSD-Proxy Core Components
5. Der Assistent entfernt nun noch ggf. vorhandene Applikationen vom Server.
Fehlermeldungen knnen dabei erscheinen, wenn die Applikationen nicht mehr auf dem
Server vorhanden sind. Diese Fehlermeldungen knnen in diesem Fall ignoriert werden.
6. Installieren Sie die Management Point Applikation OSD-Proxy Core Components
7. Sichern und entsperren Sie die Infrastrukturkonfiguration.

7.3.7 Wiederherstellen der Funktionalitt Distributionsdienst

1. Starten Sie die DSMC von einem Depot-Share
2. In der Infrastruktur-Ansicht sperren Sie den Zugriff auf die Konfiguration
Merken Sie sich die Stellen in der Infrastrukturkonfiguration, in welcher dieser
Distributionsdienst als zustndiger Distributionsdienst eingetragen ist. Nach der
Deinstallation sind diese Stellen nicht zugeordnet und mssen ggf. nach der
Neuinstallation neu zugeordnet werden.
3. ffnen Sie die Eigenschaften des vom Ausfall betroffenen Management Points, welcher
die Management Point Applikation FrontRange DSM Distribution Service enthielt.
4. Deinstallieren Sie die Management Point Applikation FrontRange DSM Distribution
Service
5. Der Assistent entfernt nun noch ggf. vorhandene Applikationen vom Server.
Fehlermeldungen knnen dabei erscheinen, wenn die Applikationen nicht mehr auf dem
Server vorhanden sind. Diese Fehlermeldungen knnen in diesem Fall ignoriert werden.
6. Installieren Sie die Management Point Applikation FrontRange DSM Distribution
Service
7. Kontrollieren Sie, ob der neu installierte Distributionsdienst wieder an den richtigen
Stellen in der Infrastrukturkonfiguration eingetragen ist
8. Sichern und entsperren Sie die Infrastrukturkonfiguration.

7.3.8 Wiederherstellen der Funktionalitt DSM Extended Reporting

1. Starten Sie die DSMC von einem Depot-Share
2. In der Infrastruktur-Ansicht sperren Sie den Zugriff auf die Konfiguration
3. ffnen Sie die Eigenschaften des vom Ausfall betroffenen Management Points, welcher
die Management Point Applikation DSM Extended Reporting enthielt.
4. Deinstallieren Sie die Management Point Applikation DSM Extended Reporting
5. Der Assistent entfernt nun noch ggf. vorhandene Applikationen vom Server.
Fehlermeldungen knnen dabei erscheinen, wenn die Applikationen nicht mehr auf dem
Server vorhanden sind. Diese Fehlermeldungen knnen in diesem Fall ignoriert werden.
6. Installieren Sie die Management Point Applikation DSM Extended Reporting
7. Sichern und entsperren Sie die Infrastrukturkonfiguration.

Seite 16

Alternative Sicherungsmethoden
Die oben aufgefhrte Strategie zu Backup und Wiederherstellung des Gesamtsystems beruht
auf Standard Backup-Mechanismen und ist ausgelegt auf ein konsistentes Gesamtsystem. Wenn
ihre Anforderungen an die zeitliche Wiederverfgbarkeit der Systeme grer ist, als sie es mit
den oben genannten Mechanismen abdecken knnen, kann man es in Betracht ziehen
alternative Sicherungsmethoden zu verwenden. Im Folgenden sind einige Ideen aufgelistet:

8.1

Cold Stand-by Systeme

Zentrale, einzigartige Systeme (wie z.B. den Business Logic Server) knnten beispielsweise
regelmig mit einer Imaginglsung gesichert werden. Nach einem Hardwareausfall des LiveSystems knnte man ein solches Image in einer virtuellen Maschine weiter betreiben, bis es von
dort wieder auf die physische Hardware zurckgespielt werden kann. (mgliche Probleme:
Rechnername und Domnenmitgliedschaft des Rechners).

8.2

Constant-Backup
Datenbanken kann man mithilfe des Transaktionsprotokolls hufig bis auf wenige
Millisekunden genau an den letzten Stand vor den Ausfall eines Systems wiederherstellen. Es
gibt Backuplsungen, die dies auch fr Dateitransaktionen beherrschen. Ein Datenverlust und
ein Informationsverlust ist damit nahezu ausgeschlossen.

8.3

Virtualisierung und Snapshotverfahren

Durch virtualisierte Rechner mit regelmigen Snapshots ist die Wiederherstellung auch vieler
Systeme zu einem genau definierten Zeitpunkt deutlich vereinfacht und beschleunigt.

8.4

Einsatz von Clusterlsungen oder HA-SAN-Lsungen

Die Datenbank kann auch auf einem Cluster gehostet werden, die Massendaten auf einem
hochverfgbaren SAN. Die potentielle Vermeidung von Hardwareausfllen und deren
Auswirkungen fhrt in der Summe zu einer deutlich gesteigerten Verfgbarkeit des DSM
Gesamtsystems.

Seite 17

ber FrontRange Solutions

Das 1989 gegrndete Unternehmen ist der fhrende Anbieter fr IT-Service- und ClientLifecycle-Management fr mittelstndische und verteilte Unternehmen. Front Range Solutions
bietet eine einzigartige Kombination aus Innovation und Automatisierung, basierend auf
Standards zur Vereinfachung der Geschftsprozesse.
Neben den beiden Lsungen FrontRange Service Management und FrontRange ITAsset Management
umfasst das Produktportfolio Lsungen fr Customer Relationship-, Sales Force-, sowie IT Assetund Lizenzmanagement. Alle Produkte von FrontRange Solutions sind dabei ber die FrontRange
Foundation ineinander integriert.
Durch den tglichen Einsatz der Softwarelsungen und Services von FrontRange Solutions
gelingt es wachsenden Unternehmen, ihre Produktivitt, Servicequalitt und
Kundenzufriedenheit signifikant zu steigern.
Mehr als 150.000 der weltweit bekanntesten Unternehmen nutzen das Angebot von
FrontRange Solutions um die Zusammenarbeit mit externen und internen Kunden zu
optimieren und somit bessere Geschftsergebnisse zu erzielen.
Weitere Informationen finden Sie unter www.frontrange.de

Seite 18