So läuft der Restore von verschlüsselten Backups auf ein Alternativ-System im Detail ab:
- Der Commandserver startet den Restore Job mit der Cross-Restore-Option auf dem Client
- Der Client kontaktiert den Backupserver und teilt ihm mit, dass er authorisiert ist, die Sicherung vom Original-Client zu restaurieren (Cross-Restore)
- Der Backupserver findet die Sicherung und überträgt den Header an den Client
- Der Client stellt anhand des Headers fest, dass die Sicherung verschlüsselt ist
- Aufgrund von 4. sucht der Client in seiner CONDEV nach cryptdir/cryptkey, um den Schlüssel einzulesen
- Der Client wendet Schlüssel auf den Header an und stellt fest, ob Decrypt möglich ist
- Wenn Decrypt möglich ist wird der Restore ausgeführt, ansonsten erscheint ein Decrypt Fehler
Der Commandserver kann nicht wissen, ob der Client einen CONDEV Eintrag hat, und ob dieser den korrekten Schlüssel für den spezifischen Restore enthält.
Eine adäquate Vorgehensweise, um Fehler in den Phasen 5. und 6. zu vermeiden, ist:
a. einmaliges Erstellen der Schlüsseldatei mit rangen.exe auf einem System
b. Eintrag der CONDEV Werte cryptdir/cryptkey auf allen Systemen
c. Ablage der Schlüsseldatei im Pfad cryptdir/cryptkey auf allen Systemen
Es ist unwesentlich, welches System die Schlüsseldatei erstellt hat, wichtig allein ist der Inhalt, der auf allen Windows Systemen von unserer Software als gleich angesehen wird. Damit haben alle Systeme den gleichen Schlüssel und Cross-Restores der verschlüsselten Backups auf alternative Systeme sind ohne Probleme möglich.