Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Issue in HP Data Protector restore script #386

Closed
revog opened this issue Apr 2, 2014 · 3 comments
Closed

Issue in HP Data Protector restore script #386

revog opened this issue Apr 2, 2014 · 3 comments
Assignees
@gdha
Labels
bug The code does not do what it is meant to do
Milestone
Rear v1.16

Comments

@revog
Copy link
Contributor

revog commented Apr 2, 2014

Hi there

Currently I'm implementing ReaR in relation to HP Data Protector on CentOS 6 machines.
Generation of ISO worked fine. During reverse engineering of failed disaster recovery process I got stuck on the restore/../40_restore_with_dp.sh script.

I've seen, that we iterate through available sessions, backuped hosts and file systems. After they get stored under /tmp/(dp_)*.

Within the script verify/../50_select_dp_restore.sh on line 30 we query the available filesystems and store them in /tmp/dp_list_of_fs_objects:

${OMNIDB} -filesystem | grep "${HOST}" | cut -d"'" -f -2 > /tmp/dp_list_of_fs_objects

But in a later step (40_restore_with_dp.sh) we read in the file /tmp/list_of_fs_objects which contains ALL available filesystems of all backuped servers. This leads to the fact, that rear tries to restore the first in the list (which does not belong to the client beeing restored in my example) and fails.

Am I doing something wrong or shouldn't the 40_restore_with_dp.sh script take the /tmp/dp_list_of_fs_objects list instead of /tmp/list_of_fs_objects?

Thanks for helping.

Regards
@gdha gdha added the bug label Apr 2, 2014
@gdha gdha added this to the Rear v1.16 milestone Apr 2, 2014
@gdha
Copy link
Member

gdha commented Apr 2, 2014

@revog it looks your re-engineering work was the nail on the head ;-)
looking forward to your pull request. Thanks for the debugging.

revog added a commit to revog/rear that referenced this issue Apr 3, 2014
@revog
Fix for rear#386 (usage of wrong filesystem list)
2fe3362 
Wrong fs list used during restore process. Current code uses '/tmp/list_of_fs_objects' which contains all fs of all backuped servers in the DP environment. This is wrong.
Must use the "filtered" list '/tmp/dp_list_of_fs_objects' which contains only the fs for the specific server. 
File is beeing generated in prior script (verify/../50_select_dp_restore.sh).
gdha added a commit that referenced this issue Apr 3, 2014
@gdha
Merge pull request #388 from revog/patch-1
aacb1c1 
Fix for #386 (usage of wrong filesystem list)
@gdha gdha self-assigned this Apr 3, 2014
@gdha
Copy link
Member

gdha commented Apr 3, 2014

@revog could you verify it works well and close the issue if possible?

@revog
Copy link
Contributor Author

revog commented Apr 3, 2014

Thx @gdha for your prompt support and merge. Just tested and it works like a charm! cheers

@revog revog closed this as completed Apr 3, 2014
Florent38 pushed a commit to Florent38/rear that referenced this issue Apr 23, 2014
@gdha
Fix the wrong grub executable being used on SLES/OpenSuSe (grub vs gr…
77864b7 
…ub2). Using now BOOTLOADER variable if present. Linked to issues rear#182 and rear#386
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gdha gdha

Labels
bug The code does not do what it is meant to do
Projects
None yet
Milestone
Rear v1.16
Development

No branches or pull requests
2 participants
@gdha @revog