My attention the other day was caught by post on ENC named Getting wrong path doing recover using the Browse tab, Search tab works. I read what Gustavo B. Schenkel wrote and I immediately remembered I noticed something similar in the past from CLI as well. I think bingo was spot on in his answer, but it felt more like this is covering GUI and details about CLI escaped me. I had a sort of partial memory that it depended on location from which I was running restore of how it was selected, but I wasn't sure. So I decided to make some tests.
In my tests I used one small backup server which I used as client as well. It is based on Linux with NetWorker version being 188.8.131.52 (build 821). For the sake of the test, CLI wise, I will focus on following:
So, I will deal with /usr/man/man8 folder and some 4 files inside. Let's see what happens if I use recover from CLI and try to dump this onto some location (eg. /nsr/recover/test1) when using -a option. Here is the screenshot of test:
There is nothing strange or unexpected here. I have path to I wanted to restore (/usr/man/man8) and I said I want this to be dumped into /nsr/recover/test1. I would expect to see man8 and everything below in that destination and that happened. Nothing worth excitement here.
In above example we saw ssid so while we are here, let's see what happens with ssid restore:
Here we have different picture, but it make sense. To grasp this, let me explain what I did and then we will come to point why it came out the wait it did. I instructed recover to do so called ssid restore (where you specify ssid) and said dump it onto /nsr/recover/test2. On top of that, I said I want only /usr/man/man8. What I got into test2 was not just man8 but also parent folder structure. Why is that? Well, ssid recover reads whole ssid so whenever you are doing restore, you are restoring whole structure as it was. Your selection is ssid which means your selection is also parent folder structure. What about selection I made (/usr/man/man8)? In case of ssid restore, this acts as a filter as to what recover will pass to be written and rest is discarded (but read by nsrmmd). I like to draw parallel to grep here (or findstr if on Windows). To illustrate this, observe following:
In above example, I did ssid restore of / and I said I with to get /etc/hosts, but I did get much more as - just as in example with grep - I got everything matching the pattern.
With this in mind, let's do now restore from recover prompt itself. Here is one approach:
Again, nothing to get exciting here. What you select - that is what you get. So, what if do selection from /usr in recover window? Will that make anything more exciting?
For a moment I thought things will be a bit different here as in selection phase you see both /usr/man and /usr/man/man8 mentioned, but you can see from restore log that only man8 (as selected) is used to build folder tree. So, no big surprises there.
Let's see how this works with files. Repeating two tests with files gives you pretty much the same picture:
This is expected and logical. Doing it from recover prompt is no different than before:
Let's go to GUI now. As per Gustavo he used Recover wizard thingy - something I never did so far so this was learning curve for me as well. Important to notice, Gustavo used recover process and not NetWorker User. What he noticed was that there is difference in structure recovered depending if he was browsing or searching for file. So, I decided to do the same.
I initiated new recover via recover tab and this is what I did:
Just to be safe, I fired up following too:
Result here is pretty much expected:
Above suggests that selected file was restored to test9 and indeed - that is true:
If I check my little process capture logging I see:
So, in short... task called Test9 is created and execute and that runs recover from CLI with input option where input is file selection which NW will feed recover process as standard input. As this is done via task, log (same as in GUI) is available via /nsr/logs/recover too:
Let's do this again, but this time I will use search instead. This showed me following:
This little experiment showed me I had two copies of files (one in tmp and one in /usr/man/man8 - which is pretty much right as I usually scp this file to /tmp with my own userid and from them I cp it to final destination with altered privileges). For fun, I selected both. Recovery list here contains absolute paths, but so it did in previous attempt.
Well, this looks like ssid restore where parent folder structure is made. Indeed, structure is there:
However, if you check process capture list then nothing suggests this was ssid restore:
Well, one thing is different: I restored two identical files from different locations. If they went onto same folder, they would overwrite each other (at least one of them would do that). So, back to the basis and let's use GUI search, but this time only we restore same file as before without the one from /tmp. We get:
OK, so with one file we only get file without parrent infrastructure created. Again, since I used in Test 10 identical files, it still may be too early to draw any conclusion so I will now go back to CLI and run few more tests which will answer the open questions.
Simplest test to try is the one where we select two files from the same folder. That should be business as usual and it is:
Now, let's repeat this test by selecting files from two different folder on the same partition (/usr). Here is what happened:
So, we tried to restore /usr/man/man8/nsrcli.8 and /usr/share/man/man8/nsrpush.8 and we see those restore from first different folder as from their common parent. This is why we do not see /usr here.
Finally, let's try to restore 2 different files from two different partitions. We get:
While these are different files, they are also on different partitions so full paths are used:
So, I could not really see what Gustavo reported (or I could not reproduce it or perhaps I even didn't understood well what he said), but structure in which files are restored depends on:
- which restore method you use
- where data selected for restore belongs (where differentiating factor might arise from different partitions or different folder paths on same partition)