Hi,
17.07.2007 19:22,, Ryan Novosielski wrote::
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Arno Lehmann wrote:
>> Hi,
>>
>> 17.07.2007 10:10,, Mair Wolfgang-awm013 wrote::
>>> Hello,
...
>>> 17-Jul 11:40 linux-install-fd: RestoreFiles.2007-07-17_09.35.44 Error:
>>> create_file.c:312 Could not hard link /part2/bin/cpio ->
>>> /part2/var/ftp/bin/cpio: ERR=No such file or directory 17-Jul 11:40
>> This is probably more of a problem. I think Bacula tries to restore
>> the hard link only, but the original file does not exist. This can
>> happen if you selectively restore, and in your selection are only file
>> entries detected as hard links by bacula, but the file data itself is
>> not restored and does no longer exist on disk. In my opinion, Bacula
>> should restore the complete file... I'm not sure if an upgrade to a
>> more current (beta) version fixes this, but I'm not even sure this is
>> the problem :-)
>>
>> [more hard link problems]
>
> This, unless you know more than I do, I'd have to disagree on. A hard
> link in UNIX is, if I understand this correctly, the equivalent of a
> cross-linked file in DOS. That is, the file is on disk, and there are
> multiple places pointing at it. The file is no more one of them than any
> other.
Yes. One set of data, multiple directory entries pointing to it. The
directory entries are all equal, there's not one that points to the
original file and other marked as links.
> A symlink is like a shortcut, and there the file is on disk in
> one place with a pointer at another place. Seems to me, backing up any
> one copy of a hard linked file should be enough. The question then is
> how does it handle multiple file locations? Maybe you are speaking to
> Bacula's handling.
Yes... I recall there being a discussion about this some time ago.
If I'm not mistaken, Bacula stores the file when it encounters it
first, but stores only the directory entry when it re-encounters the
same data from another directory entry again (data being identified by
device number and inode id).
The problem Wolfgang encountered might result from the way Bacula
restores: The restored file collection probably did not include the
file itself, only the hard link information.
I suppose that Bacula, in the version Wolfgang is running, is not
smart enough to notice that the data for this hard link is not
restored in the same job, so it tries to re-create the hard link
(directory entry) only.
The question is - what would be the best approach when restoring hard
linked files?
a) always restore the file data, thus creating unnecessary data on
disk when you actually only want the link restored?
b) always only restore the link (which is what happens now, if I guess
right), which will fail when the data is no longer present on disk,
and which will probably not be what the user wants?
c) be a little clever: Restore the data if it no longer exists on
disk, otherwise only recreate the hard link?
d) be really clever: Recreate the link only, when the file data still
exists on disk and is unchanged relative to the backed up data, and
restore the file if it's gone from disk, and restore the file as a
"complete" file if the data has changed.
I'll try to illustrate:
Backup time:
Data on device X, inode Y Link 1 Link2
123456 DataX/Y DataX/Y
b, d)
Situation at restore time, data still exists.
Link2 selected for restore
DataX/Y Link2
123456 DataX/y
recreated as a hard link
b)
Data gone, Link2 selected for restore
Link2
DataX/Y
failure to create link because data does not exist
c)
Data gone, Link2 selected for restore
DataX/Y Link2
123456 DataX/Y
recreated as a file with contents and directory entry
c)
Data modified, Link2 selected for restore
DataX/Y Link2
987654 DataX/Y
this is probably not what the user expects because, after
restore, the contents of Link2 is not identical to what it was at
backup time. The file system structure is the same, though.
d)
Other possibility:
DataX/Z Link2
123456 DataX/Z
file is recreated with the contents at backup time, but the
file system structure is different.
I think the most reasonable approach is d) as there, the restored file
contents will be identical to what you backed up, independent of file
changes in between. Obviously, that's the most difficult approach...
whenever Bacula tries to restore a file known as hard-linked, the FD
would have to decide if the data area still exists and has the same
contents as was backed up.
> I don't really know.
I don't, too - the above is mainly guesswork, based on vague
recollections of an earlier discussion :-)
I'll ask Kern :-)
Arno
--
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
