Re: [Bacula-devel] 1.39 beta restored file differences (was: first impression)

[Kern S. <ke...@si...>]

On Thursday 31 August 2006 19:56, Arno Lehmann wrote:
> Ok, I've got some more information:
> 
> On 8/29/2006 12:15 PM, Arno Lehmann wrote:
> > Hi,
> > 
> > On 8/28/2006 11:49 PM, Kern Sibbald wrote:
> > 
> ...
> >>>Another thing I found which might be more serious (but I didn't do any 
> >>>investigation!) - can be seen here. Compare the two lines of output.
> >>>
> >>>balrog:/var/bacula/restore # ls -ld etc /etc
> >>>drwxr-xr-x 85 root root 7352 Aug 23 23:56 /etc
> >>>drwxr-----  3 lp   lp     72 Aug 28 21:57 etc
> >>>
> >>>Obviously, wrong ownership and permission. Might this be caused by the 
> >>>changed metadata coding in the catalog? The FD this was backed up from 
> >>>and restored to is a 1.38 one, BTW.
> >>
> >>
> >>The restore does not use any of the metadata in the catalog. The problem 
is 
> >>more likely that you backed up files from one client and restored to 
another 
> >>client.
> 
> First, I can confirm that backups and restores do seem to work correctly
> - I did some tests with backing up, restoring, diff'ing and manually
> comparing metadata. Seems all ok, except for the above.
> 
> For which have an explanation now, and I even think I vaguely recall
> some discussion on the mailing lists.
> 
> Note that I restored an incremental backup only. Now, look at the
> following output, listing the *only* file restored below /etc:
> 
> balrog:/var/bacula/restore # ll
> total 0
> drwxr-xr-x 11 root root  264 Aug 31 12:13 .
> drwxr-xr-x  4 root root   96 Aug 28 21:57 ..
> drwxr-xr-x  2 root root   48 Aug 28 00:46 dev
> drwxr-----  3 lp   lp     72 Aug 28 21:57 etc
> drwx------  3 jefe users  72 Aug 31 12:13 home
> drwxrwxrwx  3 root root   72 Aug 28 21:59 media
> dr-xr-xr-x  2 root root   48 Aug  1 21:51 proc
> drwx------  2 root root   80 Aug 28 21:59 root
> drwxr-xr-x  2 root root   48 Aug  1 21:51 sys
> drwxrwxrwt  2 root root   48 Aug 28 21:15 tmp
> drwxr--r--  8 ntp  root  192 Aug 28 21:59 var
> balrog:/var/bacula/restore # ll etc/cups/certs/0
> -r--r----- 1 lp lp 32 Aug 28 21:25 etc/cups/certs/0
> 
> You notice that the permissions assigned to the etc directory are
> identical to the ones of that file. The same is true for all the
> directories in between.

This is *exactly* what Bacula does when you restore a single file and the 
directory does not previously exist.  If you want the directory to be 
restored with correct permissions then you must explictly restore the 
directory, which is what "markdir" is for.  It allows you to mark a directory 
entry to be restored without marking everything below it.

> 
> I'd still consider this behaviour a bug, but not as serious as was my
> first impression.
> 
> The solution would be to to implicitly restore the directory entries
> before the files, in the correct order.

Bacula does not implictly restore directories if you have selected only a 
file, and I'm not sure it is really a good idea.  It is certainly a behavior 
that we can create. 

> 
> Since restoring a limited fileset (in my experience) indicates that
> you'll use the files to replace the existing copies, not also the
> directories, I'd consider this a minor problem. Others might think
> different.

Well, it probably is something that needs to be *clearly* explained in the 
manual, and is probably also the problem that a couple of users have seen in 
the past.  When someone reports that a directory is not restored correctly, I 
never (until now) have thought to ask if he/she actually restored the 
directory -- most of the time directories are restored because the whole 
directory is marked with all the files below it, or the directory already 
exists, so its permissions are already set correctly.

In any case, the behavior of 1.39.20 is no different from previous versions so 
from that angle, I wouldn't classify this as a 1.39.20 bug.  

Thanks for taking the time to dig into it.  I was awfully worried about your 
first report.

Regards, Kern