Führt für den angegebenen Storage Cluster einen manuellen Failback vom Secondary zurück zum Primary Storage-System durch.
Voraussetzung: Nach einem Failover ist das Primary Storage-System wieder verfügbar und die interne Re-Synchronisation vollständig.
Das Kommando wird immer am Primary Storage-System ausgeführt.
Syntax
|
Parameter
–cluster clustername
Wählt die SCO-Gruppe (Storage Cluster-Gruppe) für den Failback anhand des angegebenen Namens.
Return-Codes
Fehlercode | Name | Fehlerart |
0 |
| Funktion erfolgreich |
2 |
| Funktion nicht vollständig |
3 |
| Version wird nicht unterstützt |
7 |
| Ungültige Parameter angegeben |
13 |
| Fehler in der StorMan Kommunikation zwischen Client und Server |
16 |
| Unerwarteter Fehler in der Funktion |
18 |
| Keine passenden Objekte verfügbar |
21 |
| StorMan SubCode |
22 |
| Provider oder Datenbank nicht verfügbar |
36 |
| Benutzer / Kennwort für StorMan nicht gültig |
37 |
| Fehlerrückgabe durch Provider StorMan SubCode |
Fehler-Subcodes von STORMAN_SUB_SCO_ADD_INFO
:
Untercode | Fehlerart |
0 | Erfolg |
1 | Nicht unterstützt |
2 | Unbekannt |
3 | Timeout |
4 | Fehlgeschlagen |
5 | Ungültiger Parameter |
32768 | Keine Lizenz gefunden |
32768 | Ungültiger TFO (Transparent Failover) Gruppenphase |
32768 | Kein FTV-Volumentyp in TFO-Gruppe |
32768 | TFO-Gruppenstatus inkonsistent im Primary Storage |
32768 | TFO-Gruppenstatus inkonsistent im Secondary Storage |
32768 | Ungültige TFO-Gruppenaktivierung für Secondary storage spezifiziert (Failover) |
32768 | Ungültige TFO-Gruppenaktivierung für Secondary storage spezifiziert (Failback) |
32768 | REC-Pfade deaktiviert |
32768 | Ungültige TFO-Gruppenbedingung |
Beispiel
storcluster –failback –cluster DX500_1-DX500_2