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
