You usually restore from a clone by specifying the cloneid along with the ssid like
recover .... -S ssid/cloneid
By default (if you only use the ssid) NW would access the first (oldest) instance of the backup, which usually resides on a backup media, not on a clone media.
This is how you do it with a 'standard file backup'. In our case this applies to SQL backups as well, as we export the databases so we treat them as files. I am not sure how the NMM/SQL allows you to specify that. In this case, the second method will solve the issue:
Set the instance on the backup medium as 'suspect' : nsrmm -o suspect -S ssid/cloneid
After applying this command, NW sees the specified instance as 'defect' and will automatically select another instance (if you have clones at all ;- )
If you have a different storage node managing the device that mounts the clone volume then try using that storage node in the clients 'Recover Storage Node' setting.
bingo.1
2.4K Posts
0
August 7th, 2019 04:00
You usually restore from a clone by specifying the cloneid along with the ssid like
recover .... -S ssid/cloneid
By default (if you only use the ssid) NW would access the first (oldest) instance of the backup, which usually resides on a backup media, not on a clone media.
This is how you do it with a 'standard file backup'. In our case this applies to SQL backups as well, as we export the databases so we treat them as files. I am not sure how the NMM/SQL allows you to specify that. In this case, the second method will solve the issue:
Set the instance on the backup medium as 'suspect' : nsrmm -o suspect -S ssid/cloneid
After applying this command, NW sees the specified instance as 'defect' and will automatically select another instance (if you have clones at all ;- )
crazyrov
4 Operator
•
1.3K Posts
0
August 7th, 2019 08:00
If you have a different storage node managing the device that mounts the clone volume then try using that storage node in the clients 'Recover Storage Node' setting.