Achtung: Bis einschließlich CMS Fiona 6.7.3 dürfen auf produktiv genutzten Systemen keinen Daten aus partiellen Dumps wiederhergestellt werden, da dies zu Datenverlust führen kann.
Starten Sie die Datenwiederherstellung nur dann, wenn währenddessen mit Sicherheit keine schreibenden Zugriffe auf den Datenbestand stattfinden, da andernfalls existierende oder importierte Daten zerstört würden. Stellen Sie daher sicher, dass während der Ausführung des Befehls der CM nicht als Server läuft und keine anderen CMs im Single-Modus gestartet werden oder laufen.
Bitte beachten Sie Folgendes, wenn Spiegeldateien gesichert und wiederhergestellt werden: Im Dump müssen die Originaldateien der Spiegeldateien enthalten sein und im Zielsystem zusammen mit den Spiegeldateien auch wiederhergestellt werden können.
Um den Datenbestand wiederherzustellen, gehen Sie bitte folgendermaßen vor:
Melden Sie sich als CMS-Administrator am Betriebssystem an. Der CMS-Administrator ist der Benutzer, der bei der Installation angegeben wurde.
Fahren Sie den Content Management Server herunter.
Wechseln Sie ins bin
-Verzeichnis der
betreffenden Instanz und führen Sie den folgenden Befehl in einer
Shell aus:
CM -restore dumpDir targetPub \ [{entity ident}| file deffile] \ [-batch [{(entity | all) conflictStrategy}]]
Geben Sie als dumpDir
bitte das Verzeichnis an, in dem sich die gesicherten CMS-Daten befinden. Ein relativer Pfad bezieht sich auf das aktuelle Verzeichnis.
Werden die optionalen Teile der Kommandozeile komplett weggelassen, so nimmt der Content Manager an, dass alle in der Sicherung enthaltenen Daten wiederhergestellt werden sollen.
Mit targetPub
wird ein Zielordner für die wiederherzustellenden Dateien angegeben.
Geben Sie als entity
eines der Schlüsselwörter object
, objectTree
, attribute
, workflow
oder objClass
an.
Wenn entity
gleich object
oder objectTree
ist, geben Sie als ident
eine Datei-ID oder einen Dateipfad, bei allen anderen Entitäten ihren Namen an.
Mit der Option file
deffile
können Sie die wiederherzustellenden Entitäten in einer Definitionsdatei (deffile
) angeben, anstatt sie auf der Kommandozeile aufzuführen. In einer solchen Definitionsdatei muss je Zeile ein Entitäten-Typ entity
, gefolgt vom Namen ident
(bzw. Pfad oder ID bei Dateien) angegeben werden. Kommentare können auf separate Zeilen mit einem Doppelkreuz als erstem Zeichen geschrieben werden.
Mit der Option -batch
lässt sich die interaktive Konfliktbehandlung (siehe unten) abschalten. Wenn -batch
angegeben wurde, kann je Entitätentyp eine der folgenden Konfliktlösungsstrategien angegeben werden:
w
= Immer überschreibena
= Immer unter einem automatisch generierten Namen wiederherstellenk
= Entität immer überspringen.Sie können all
als Entitätenbezeichner vewenden, um die Strategie für alle Entitäten-Typen zu setzen. Die Voreinstellung für die Konfliktlösungsstrategie ist w
(immer überschreiben). Ab CMS Fiona 6.0.0 wird jedoch eine CMS-Datei in einem partiellen Dump grundsätzlich nicht wiederhergestellt, wenn sie im Zielsystem bereits existiert, unabhängig von der gewählten Konfliktlösungsstrategie.
Wie bei der vollständigen Wiederherstellung gibt es die Möglichkeit, eine abgebrochene partielle Wiederherstellung wieder aufzunehmen. Hierfür dient die Option resume
:
CM -restore dumpDir resume
Beispiel: Mit der folgenden Kommandozeile werden Daten aus dem Dump im Verzeichnis myDir
im Zielordner mit der ID 4812
wiederhergestellt. Es sollen die Ordnerhierarchien /de
und 12345
sowie die Dateivorlage newsdoc
wiederhergestellt werden:
CM -restore myDir 4812 objectTree /de objectTree 12345 objClass newsdoc
Im Gegensatz zur Wiederherstellung einer kompletten Sicherung werden bei der partiellen Wiederherstellung von Dateien nicht die ursprünglichen Datei-IDs verwendet. Dies würde zu Konflikten führen, wenn es bereits Dateien mit der gleichen ID gibt. Dateien werden daher stattdessen unter Verwendung der nächsten freien ID angelegt.
Dennoch kann es bei der Wiederherstellung partiell gesicherter Daten zu Namenskonflikten kommen, wenn nämlich Dateien, die in den gesicherten Daten enthalten sind, im Zielordner unter dem gleichen Namen bereits vorhanden sind. In diesem Fall wird eine Fehlermeldung ausgegeben und der Wiederherstellungsvorgang abgebrochen. Sind Entitäten der anderen Typen (beispielsweise Felder und Workflows) bereits vorhanden, wird eine Konfliktbehandlung durchgeführt, d. h. Sie können entscheiden, wie weiter verfahren wird.
Wenn die interaktive Konfliktbehandlung nicht mit -batch
abgeschaltet wurde, müssen Konflikte interaktiv gelöst werden. Existiert eine Entität bereits, so bietet Ihnen der Content Manager die folgenden Optionen an:
o
= Überschreiben (ersetzt die vorhandene Entität durch die gesicherte).w
= Immer überschreiben (wie o
, jedoch auch für alle anderen Entitäten des gleichen Typs).r
= Umbenennen (die Entität unter einem anderen, anzugebenden Namen wiederherstellen).a
= Wie r
, jedoch mit automatisch generiertem neuen Namen und auch für alle anderen Entitäten des gleichen Typs.s
= Überspringen (die Entität wird nicht wiederhergestellt).k
= Immer überspringen (wie s
, jedoch auch für alle anderen Entitäten des gleichen Typs).Ab CMS Fiona 6.8.0 können mit dem partiellen Dump/Restore-Verfahren auch Spiegeldateien wiederhergestellt werden. Auch und vor allem hierbei können Situationen auftreten, die einer gesonderten Behandlung bedürfen, etwa wenn im Dump zwar Spiegeldateien, nicht jedoch deren Originale enthalten sind. Im interaktiven Modus (wenn -batch
nicht angegeben wurde), erhält der Benutzer die Gelegenheit, den weiteren Verlauf der Wiederherstellung von Spiegeldateien zu beeinflussen, indem er die vom Content Manager gestellten Fragen beantwortet. Im Batch-Modus dagegen kann das gewünschte Verhalten des CM mit zwei weiteren Schlüsselwörtern für entity
vorab festgelegt werden:
unrestorableMirrors
: Wenn Spiegeldateien
grundsätzlich nicht wiederhergestellt werden können (weil vom
Zielordner mindestens ein Spiegelordner existiert), kann der
Restore-Vorgang mit der Konfliktlösungsstrategie q
(Voreinstellung) abgebrochen werden. k
setzt den Vorgang
fort, lässt Spiegeldateien jedoch unberücksichtigt.
replaceOriginal
: Wenn das Original einer
Spiegeldatei nicht im Dump enthalten ist, jedoch unter dem Pfad des Originals
dieser Spiegeldatei eine Originaldatei existiert, wird mit der
Strategie a
die Spiegeldatei wiederhergestellt.
k
(Voreinstellung) setzt den Vorgang fort, lässt
solche Spiegeldateien jedoch unberücksichtigt.
Im Batch-Modus wird der Restore-Vorgang also abgebrochen, wenn der Dump Spiegeldateien enthält, diese jedoch grundsätzlich nicht wiederherstellbar sind. Sind sie dagegen wiederherstellbar, werden Spiegeldateien, zu denen es im Dump keine Originale gibt, dennoch nicht wiederhergestellt. Dies ist das voreingestellte Verhalten.
Im folgenden Beispiel werden Spiegeldateien, deren Originale nicht im Dump enthalten sind, unter Verwendung der Originale im Zielsystem wiederhergestellt und ansonsten – wenn auch das Zielsystem die Originale nicht enthält – ausgelassen.
CM -restore sourceDir /target/folder -batch replaceOriginal a
Die wiederherstellbaren Daten einer partiellen Sicherung lassen sich bequem mit der Option -listDump
ausgeben:
CM -listDump dumpDir [entity]
dumpDir
bezeichnet das Verzeichnis, in dem sich die gesicherten Daten befinden. Die Ausgabe lässt sich durch Angabe eines Entitäten-Typs entity
auf die Dateien dieses Typs beschränken. Beispiel:
CM -listDump dumpDir object
Den Stand des Sicherungsvorgangs speichert der Content Manager in der Datei dumpstate.xml
im jeweiligen Dump-Verzeichnis.
Für den Fall, dass ein Wiederherstellungsvorgang unterbrochen wird, speichert der Content Manager den aktuellen Stand der Wiederherstellung in der Datei restorestate.xml
im Verzeichnis tmp
unterhalb des Instanzenverzeichnisses sowie in der Datenbank. Es kann je Instanz nur einen nicht abgeschlossenen Wiederherstellungsvorgang geben.