11-14-2003 04:18 AM
Using DP5.1, I tried to restore 3 directories objects on WinFS client. I got two bad things.
[Warning] From: RSM@bkp "" Time: 13.11.2003 16:58:53
Following trees from "host, session 2003/02/26-7
were not found in database:
Whole object will be read to perform restore.
[Warning] From: RSM@bkp "" Time: 13.11.2003 16:58:54
Some of the restore devices are occupied. Session is waiting for all the devices to get free.
1. Why information was not found in database if data had valid protection and file tree could be browsed?
2. Why DP is waiting for a device that is free. I saw 3 pending objects in the recovery session window.
# /opt/omni/sbin/omnidbutil -show_locked_devs
The session hangs for hours!
Thanks in advance for more comments!
11-16-2003 04:12 AM
It seems to be a rather unusual problem, I have only found it in two more threads and no of them has a solution or a explanation of the problem.
And, as there is no document with error message descriptions avialable for end users (as far as I know). Maybe there is something in the online error message file (omni.cat) but this file is not readable, I can find the message string in the file but can't get the link to a description.
If I should guess something I belive there is some problem with the positions, the information about what is backed up is OK but not where on the media it is located. Therefore DP must search from the beginning until it find something to restore. But, it is only a guessing.
Maybe you should open a support call to HP, there must be documents for internal use where the problem is described.
I have seen this error when there has been processes hanging from failed/aborted sessions.
11-17-2003 02:06 PM
The whole object will be read statement is straight-forward enough, maybe. Did you do a manual add in the Restore Summary? Or did you checkmark the items in the browser window?
12-03-2003 03:21 AM
I think it is when you backup part of a filesystem in one datalist and back up another part of the filesystem in different one. But, when you try to restore, you forget that and try and restore the wrong part of the fileystem from the session (the first session will have backed up the directory for the second session so you can select the wrong one). DP can, of course still browse it all OK because it does have all the information but not as part of the session you are trying to restore.
This all comes about if you have no way of linking an object to a session, for example if you never use the Description field but let DP use it's default of the filesystem name.
I hope this makes some sense because when we stopped doing this, we stopped getting the errors.
One of our solutions was to have virtual hosts for each part of a filesystem we were backing up thus the "restore sessions" would have this virtual host name in it's description. This was before it suddenly became obvious that you could just start using the description field itself.