Sorry, but the bottom line is that I cannot do much about this. Your setup is
*way* too complicated for me to try to duplicate -- LVMs; restoring to
mounted directories; possibly not the original places; you say all the
directories were restored with permissions xxx, which was totally wrong, but
I don't have any before and after examples with names and real permissions.
I've done at least 20 or 30 bare metal restores successfully, so I think there
is something much more complicated going on here, possibly connected with LVM
and mounted volumes. One user has also reported some similar problems
concerning using wildcard excludes under similar OSconfigurations.
I'm sorry to say, but about the only solution I see is for you try this with a
really simple system, to see if the basic features work, or to go back to
using as you describe it "antiquated software like backup/restore that knows
how to do it correctly" (paraphrased).
On Wednesday 14 September 2005 16:33, Aleksandar Milivojevic wrote:
> Quoting Kern Sibbald <[EMAIL PROTECTED]>:
> > On Wednesday 14 September 2005 05:59, Aleksandar Milivojevic wrote:
> >> It is possible to correctly restore even with /etc/passwd (and/or
> >> /etc/group) file completely missing from the system. What for example
> >> if I delete /etc/passwd by mistake? Even pre-historic Unix dump/restore
> >> commands can do that. So yes, it is an issue with Bacula if it can't
> >> restore ownerships and permissions to their original (numeric) values.
> >
> > As I previously mentioned, this is exactly what Bacula does -- it
> > restores owenerships and permissions to their original numeric values.
> >
> >> You have UID, GID, and file mode (permissions). Simply restore them to
> >> their original values.
> >
> > It does that.
>
> Well, Bacula hasn't done it for me. Almost all directories were restored
> with permissions of 744 (rwxr--r--), user root, group root. Which was
> totaly wrong.
>
> My testing setup was rather simple. Bacula 1.36.3, PostreSQL 7.4.7 as
> database
> backend, two clients (backup server itself and one testing box). The
> fileset directive was same for both client:
>
> FileSet {
> Name = "Full Set"
> Include {
> Options { signature = SHA1; compression = GZIP; }
> File = /
> File = /boot
> File = /var
> File = /srv
> }
> Exclude {
> File = /proc
> File = /tmp
> File = .journal
> File = .autofsck
> File = /var/lib/pgsql
> }
> }
>
> I did one full backup of both clients. Then took another testbox (with
> empty discs), booted into rescue, recreated mirroring and LVM (md0 for
> /boot, md1 for
> physical volume for LVM, and all other file systems stored in logical
> volumes under LVM) and mounted partitions under /mnt/sysimage. Copied over
> copy of bacula-fd and bacula-fd.conf from first testbox (chaning client
> name in bacula-fd.conf), and run it as user root. From console on backup
> server, I initiated full restore of the client (relocating files to
> /mnt/sysimage and telling it to restore first testbox to second testbox).
> I ended up with screwed ownerships and screwed permissions on almost all
> directories. I think that not even all of the regular files were restored
> correctly (I should have done a better post-mortem analysis, sorry). But
> directories. They were almost
> all wrong.
>
> Next day I spent Googling around and reading some more docs. Google
> revealed that I was not the only one with the problem, but no answers or
> explanations. I was hoping I would find something in lists archives,
> but other then one or
> two emails from people experiencing same problem with bacula, there was
> nothing. I found rather unlogical requirement in docs that system's
> passwd and
> group files should be present before restoring. So I restored those files
> first, placing them into what bacula-fd would see as /etc directory (not to
> be confused with /mnt/sysimage/etc that would become /etc after reboot).
> Then did
> restore again (this time it had one full backup and one incremental to
> restore from), and this time everything was restored correctly.
>
> >> /etc/passwd and /etc/group files contain only relation between symbolic
> >> user and group names and UID and GID numbers.
> >
> > If I am not mistaken, this is a bit of a simplification of what actually
> > goes on.
>
> Well, yes. But just a bit. It's used whenever system interacts with
> humans (for example checking usernames and passwords). But internally,
> system uses UIDs only. After all, users does not need to be local to
> machine, file systems
> do not need to be local to machine, and kernel has no way of accessing
> databases
> such as LDAP or NIS (it's performed on user-level only). This is true
> for Unix.
> Windows NT (when using NTFS) is storing some crap based on actual usernames
> into file system's metadata, and access to actual user database is needed
> to correctly update NTFS metadata. That's the reason why it is bad idea to
> mount NTFS partition read/write under Linux (and also why WinXP refuses to
> access disc formatted as NTFS on some other WinXP box (unless in some
> specific cases when AD is used), and in case you wondered why Windows
> allows you to format removable media only as FAT/FAT32, or why by default
> NTFS support under Linux is read-only with read/write being highly
> discouraged compile time option -- you can seriously screw NTFS by writing
> to it from anything but exact instance of WinXP that created it).
> Linux/Unix file systems such as BSD UFS, and Linux ext2 and ext3 are clean
> in this regard, and always were, because metadata contains only UIDs and
> GIDs, so you can freely move them from one system to another (or format
> removable media with them).
>
> > I am probably wrong on this, but it is my understanding that ACLs are
> > based on
> > userids and groups rather than the numeric values.
>
> Nope. Numeric values. I would be very surprised to find otherwise. You
> can use user and group names as arguments for setfacl command, just like
> you can use them for chown and chgrp commands. But I strongly beleive
> actual file system metadata is numeric only. You can even use UIDs and
> GIDs directly as arguments for setfacl command.
>
> > You haven't offered any reasonable explanation that would lead me to
> > believe that Bacula is doing something wrong. Please be specific and
> > point to the broken code, or submit a patch. This way we could resolve
> > the problem.
>
> See the description on my restore problem. What Bacula did on restore was
> wrong. It had all information needed to restore correctly, but it
> didn't. Sorry, I haven't had a look at the code yet (and would need
> some time to get
> familiar with it enough anyhow). But I do believe I did a fairly good
> description of the problem for somebody who is familiar with the code to do
> couple of quick checks.
>
> > Personally, I suspect that for a full bare metal restore, which I have
> > done a number of times on a standard RH rescue disk, the file ownerships
> > will appear to be screwed up after the restore as long as one is booted
> > into the rescue system. Which may have been what you saw. Once one boots
> > up the restored system, the ownerships should take on a normal
> > appearance.
>
> I haven't even looked at them while booted into rescue mode. I looked at
> them after I booted restored system and some services (that run as
> non-root) started
> complaining about unreadable files (they were unreadable becouse
> directories they were residing in were incorrectly restored as user/group
> root:root, file mode 744).
>
> > For ACLs (and
> > SELinux), I'm not sure though. The other possibility is that you were
> > not running the FD as root.
>
> I was running FD as root.
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
