Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Kern Sibbald]

On Wednesday 13 December 2006 08:49, Oliver Lehmann wrote:
a Kern Sibbald writes: 
 
  
  patch-src-findlib-attribs.c
when restoring a symlink, use lchflags to restore the file flags
defined for the symlink (new feature)
when restoring a hardlink, don't call chmod, chown, utime because it is
a hardlink and don't  have such attributes (as far as I know, if 
someone
with more FS-foo can step up and confirm this?). Changing this
attributes will change the sourcefiles attributes which is probably not
what is wanted here anyway
  
  I'll have to think about this a bit more.  However, I don't think it is 
  correct to skip setting the attributes.  To understand hardlinks, the 
first 
  thing is to realize that the name is slightly misleading.  A hard link is 
not 
  really a link.  The data for the two files the attributes are one and the 
  same.  The situation is very different from a softlink where there is a 
  separate directory entry that points to an existing file.   
  
  Thus to properly restore a hardlink you must also reset the attributes or 
you 
  could potentially end up with incorrect attributes (owner, modes, ...).
 
 Ok, but from my understanding setting attributes on a hardlink changes the 
 attributes of the inode the hardlink is pointing to, like for normal files 
 which are technically hardlinks too. 

There is no such think as a hardlink.  There is a hardlink operation.  It is 
very different from a softlink, and if you think about them the same way, you 
will never get it right.  Two files that are hardlinked (really poor 
terminology) *are* one and the same file.  The two files share the same 
inode, so there is no hardlink with separate attributes that points to an 
inode (as is the case for a softlink, which is a pointer).   For hardlinked 
files, there is only one set of data and one set of attributes.

 So changing attributes for n objects  
 pointing to the same inode is like changing the attributes n times for the 
 same object or is this wrong?

There are n filenames that share the same data and attributes true, and if you 
are doing a full restore, it is possible Bacula will set those attributes to 
the same thing n times since each of Bacula's n representations of the 
hardlinked files contains the attributes (there is only one copy of the data 
though).  Ideally, Bacula would set the attributes only once when it restores 
the data, but I would have to look at the code (which I don't have the time 
to do) to remember exactly what Bacula does.

 If you think attributes for hardlinks have to be restored as well, the fix 
 for src/findlib/attribs.c has to be redone. I can do so but I still 
 think ;)

Ideally as I mentioned above, the attributes are only kept with the data and 
thus are only set one time.  Then when a second filename is found it would 
simply be hardlinked to the first file (i.e. become one and the same) and it 
would not then be necessary to re-set the attributes.  If this is what your 
patch does, then it is probably OK.  If not, we need to re-think it.  In any 
case, this could be a rather fundamental change to how the low level part of 
Bacula works, and I am a bit worried about trying to include it in version 
1.40.0.

Regards,

Kern

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Kern Sibbald]

Hello,

I've now taken a look at these patches and though they might be going in the 
right direction, I cannot consider them for inclusion in version 1.40 for 
several reasons:
1. They are not relative to the current CVS.
2. They are a significant change from the current code, which is not a problem 
during the development cycle, but *is* a major problem at this point.
3. They seem to change non-FreeBSD code -- perhaps not the functionality but 
by adding a switch().

On the other hand, I would suggest that you work with Jeremy Reed as his patch 
once it is appropriately tweaked is something that I could see adding to 1.40 
because:
1. It is relative to the CVS 
2. It makes the mininum necessary changes
3. For the most part the changes seem to be FreeBSD specific

His patch only addresses one of the two problems mentioned, so perhaps there 
is more work to be done.

Regards,

Kern

On Wednesday 13 December 2006 07:54, Oliver Lehmann wrote:
 Kern Sibbald wrote:
 
  Please fix it up correctly, then send it to me in the same diff format 
versus 
  the current CVS, but please send it as an attachment to avoid the 
possibility 
  of word wrap.  I'll then take a look at putting it in the code.  If you 
send 
  it in the next few days, it will probably become part of 1.40.0 ...
 
 I've attached 2 patches (will both apply with some offset)
 
 patch-src-findlib-create_file.c
   Try to unset file flags of the sourcefile when the hardlink failed.
   Retry to hardlink then. If the hardlink fails then again, restore the
   file flags of the sourcefile. If the hardlink was created w/o errors,
   restore the fileflags of the sourcefile.
 
 patch-src-findlib-attribs.c
   when restoring a symlink, use lchflags to restore the file flags
   defined for the symlink (new feature)
   when restoring a hardlink, don't call chmod, chown, utime because it is
   a hardlink and don't  have such attributes (as far as I know, if someone
   with more FS-foo can step up and confirm this?). Changing this
   attributes will change the sourcefiles attributes which is probably not
   what is wanted here anyway
 
 
 -- 
  Oliver Lehmann
   http://www.pofo.de/
   http://wishlist.ans-netz.de/
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlin ks to schg secured files on FreeBSD on restore

[Oliver Lehmann]

Kern Sibbald writes: 

 There is no such think as a hardlink.  There is a hardlink operation.  It is 
 very different from a softlink, and if you think about them the same way, you 
 will never get it right.  Two files that are hardlinked (really poor 
 terminology) *are* one and the same file.  The two files share the same 
 inode, so there is no hardlink with separate attributes that points to an 
 inode (as is the case for a softlink, which is a pointer).   For hardlinked 
 files, there is only one set of data and one set of attributes. 
 

I think here is a misunderstanding because that was exactly
what I was trying to say? There are only hardlinks and
softlinks in UNIX. There is no difference between a file
and a hardlink it is technically the same - a pointer
to an inode nothing more or less. regular files are
always hardlinks in UNIX(-like systems). 

 Ideally as I mentioned above, the attributes are only kept with the data and 
 thus are only set one time.

Which is not the case in bacula. It tries to set attributes
for all files it restores. So it handles setting attributes
for each file. Even if it is just another pointer to the same
inode already processed. In FreeBSDs restore, At first the
attributs are set for the inodes, and after that the hardlinks
which are pointing to the inodes are created. So there is no
double (or more) setting of the same attributes over and over
like it is the case in bacula.
This can easly be fixed in bacula by setting the attributes
only once:
  for the regular file (1st hardlink to an inode) the
  attributes are set. All other - later - hardlinks
  (FT_LNKSAVED) ignore their stored attributes because
  the inode attributes are already set by the 1st hard-
  link. 

 Then when a second filename is found it would 
 simply be hardlinked to the first file (i.e. become one and the same) and it 
 would not then be necessary to re-set the attributes.  If this is what your 
 patch does, then it is probably OK.

That is what the patch does. Sets the attributes for the 1st
hardlink (type != FT_LNKSAVE) and ignores setting attributes
for all other hardlinks to the same inode (type == FT_LNKSAVE). 


Greetings, Oliver

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlin ks to schg secured files on FreeBSD on restore

[Oliver Lehmann]

Hi Kern, 

Kern Sibbald writes: 

 1. They are not relative to the current CVS.

Hm, they are applying to it, or? At least I tried that.. 

 2. They are a significant change from the current code, which is not a 
 problem 
 during the development cycle, but *is* a major problem at this point.

This I understand and I agree fully here. when 1.40 is at the end of the 
release cycle this change is too sweeping to include. But maybe for a later 
release it is ok. For so long it can be kept as local patches... 


 3. They seem to change non-FreeBSD code -- perhaps not the functionality but 
 by adding a switch().

If that is a problem, it can also be done by using if() but I found switch() 
more suitable here. 

 On the other hand, I would suggest that you work with Jeremy Reed as his 
 patch 
 once it is appropriately tweaked is something that I could see adding to 1.40 
 because:
 1. It is relative to the CVS 
 2. It makes the mininum necessary changes
 3. For the most part the changes seem to be FreeBSD specific

patch-src-findlib-create_file.c is based on his patch. I just added the 
restore of the file flags on failure, and error messages in case of 
failures. What is the problem with it and the CVS version?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] multitape-changer issue

[Alessio Mineni]

Thanks Arno, you are a Saint :)

Alle 20:50, martedì 12 dicembre 2006, Arno Lehmann ha scritto:
 Hello,

 On 12/12/2006 11:59 AM, Alessio Mineni wrote:
  Hi all,
 
  I have 3 DAT drives and I want to group this drives into one autochenger
  virtual device via multitape-changer script.

 There was some discussion about multitape-changer recently. Use some of
 the list archives to see if there is relevant information for you...
  [...]
 I don't think this is how multitape-changer works. I never actually used
 it, but I think it simulates a one-drive autochanger with a number of
 slots equal to the number of drives you have.

Me silly! You are right! I correct it leaving only one tape device named 
changer0. I've found the thread you are talking about but, it use a 
configuration like old mine (with one autochanger and three tape device 
configured in sd.conf).

This is the new:

bacula-sd.conf

AutoChanger {
  Name = multitape0
  Device = vtape0
  Changer Command = /usr/libexec/bacula/multitape-changer %c %o %S %a %d
  Changer Device = /dev/sg0
}

Device {
  Name = vtape0
  Drive Index = 0
  Media Type = 4mm
  Archive Device = /dev/changer0
  AutomaticMount = yes
  AlwaysOpen = no
  RemovableMedia = yes
  RandomAccess = no
  AutoChanger = yes
  LabelMedia = no
}

and bacula-dir.conf

Storage {
  Name = changer0
  Address = 192.168.0.20
  SDPort = 9103
  Password = P00io9
  Device = multitape0
  AutoChanger = yes
  Media Type = 4mm
  Maximum Concurrent Jobs = 1
}

  [...]

  [...]
 
  1 - no automatic startup link has done by bacula, I have to link
  /dev/nstx to /dev/changer0 manually

 Sure, Bacula doesn't create device nodes for you.

  2 - no automatic change has done by bacula

 So the autochanger setup didn't work. What does btapes test command tell
 you?

Why not? Using multitape-changer in command line it create the right 
simlink /dev/changer0 -- /dev/nst1|2|3.

If I tell bacula to update slots it will virtually change the tapes in the 
library changing the simlink, and read, one by one, the tapes header.

 So the multitape-changer setup is not correct. See that thread I
 mentioned for more information.

 Or hope to find someone who actually uses that... (or pay me :-)
 seriously, I didn't get the impression that the suggested multichanger
 script is easy to use).

 Arno

Take a look at this output:

chronos dev # bconsole
Connecting to Director chronos:9101
1000 OK: chronos-dir Version: 1.38.5 (18 January 2006)
Enter a period to cancel a command.
*update slots
Using default Catalog name=MyCatalog DB=bacula
The defined Storage resources are:
[...]
 3: changer0
[...]
Select Storage resource (1-10): 3
Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
3306 Issuing autochanger slots command.
Device multitape0 has 3 slots.
Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
3301 Issuing autochanger loaded drive 0 command.
3302 Autochanger loaded drive 0, result: nothing loaded.
3306 Issuing autochanger list command.
Volume 1 not found in catalog. Slot=1 InChanger set to zero.
Volume 2 not found in catalog. Slot=2 InChanger set to zero.
Volume 3 not found in catalog. Slot=3 InChanger set to zero.
*label
The defined Storage resources are:
[...]
 3: changer0
[...]
Select Storage resource (1-10): 3
Enter new Volume name: extra01-0001
Enter slot (0 or Enter for none): 0
Defined Pools:
[...]
13: extra01
[...]
Select the Pool (1-13): 13
Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
Sending label command for Volume extra01-0001 Slot 0 ...
3301 Issuing autochanger loaded drive 0 command.
3302 Autochanger loaded drive 0, result: nothing loaded.
3301 Issuing autochanger loaded drive 0 command.
3302 Autochanger loaded drive 0, result: nothing loaded.
3912 Failed to label Volume: ERR=dev.c:672 Rewind error on vtape0 
(/dev/changer0). ERR=Inappropriate ioctl for device.

It call the loaded command but I'v found in docs that it will have to call the 
load command! Why?

--  
Alessio Mineni

WaveGroup
Via Benaco 34/b
25081 Bedizzole BS

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] multitape-changer issue

[Alessio Mineni]

Alle 20:50, martedì 12 dicembre 2006, Arno Lehmann ha scritto:
 Hello,

 On 12/12/2006 11:59 AM, Alessio Mineni wrote:
  Hi all,
 
  I have 3 DAT drives and I want to group this drives into one autochenger
  virtual device via multitape-changer script.

 There was some discussion about multitape-changer recently. Use some of
 the list archives to see if there is relevant information for you...

... look at this too ...

chronos dev # ln -sf nst1 changer0
chronos dev # bconsole
Connecting to Director chronos:9101
1000 OK: chronos-dir Version: 1.38.5 (18 January 2006)
Enter a period to cancel a command.
*label
Using default Catalog name=MyCatalog DB=bacula
The defined Storage resources are:
 3: changer0
Select Storage resource (1-10): 3
Enter new Volume name: extra01-0001
Enter slot (0 or Enter for none): 0
Defined Pools:
13: extra01
Select the Pool (1-13): 13
Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
Sending label command for Volume extra01-0001 Slot 0 ...
3301 Issuing autochanger loaded drive 0 command.
3991 Bad autochanger loaded drive 0 command: ERR=Child exited with code 3.
3000 OK label. Volume=extra01-0001 Device=vtape0 (/dev/changer0)
Catalog record for Volume extra01-0001, Slot 0  successfully created.
Requesting to mount multitape0 ...
3301 Issuing autochanger loaded drive 0 command.
3991 Bad autochanger loaded drive 0 command: ERR=Child exited with code 3.
3001 Mounted Volume: extra01-0001
3001 Device vtape0 (/dev/changer0) is already mounted with 
Volume extra01-0001

No load command in the log, but the manual show the load command in a some 
examples.

-- 
Alessio Mineni

WaveGroup
Via Benaco 34/b
25081 Bedizzole BS

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Kern Sibbald]

Hello,

On Wednesday 13 December 2006 10:11, Oliver Lehmann wrote:
 Hi Kern, 
 
 Kern Sibbald writes: 
 
  1. They are not relative to the current CVS.
 
 Hm, they are applying to it, or? At least I tried that.. 
 
  2. They are a significant change from the current code, which is not a 
problem 
  during the development cycle, but *is* a major problem at this point.
 
 This I understand and I agree fully here. when 1.40 is at the end of the 
 release cycle this change is too sweeping to include. But maybe for a later 
 release it is ok. For so long it can be kept as local patches... 
 
 
  3. They seem to change non-FreeBSD code -- perhaps not the functionality 
but 
  by adding a switch().
 
 If that is a problem, it can also be done by using if() but I found switch() 
 more suitable here. 
 
  On the other hand, I would suggest that you work with Jeremy Reed as his 
patch 
  once it is appropriately tweaked is something that I could see adding to 
1.40 
  because:
  1. It is relative to the CVS 
  2. It makes the mininum necessary changes
  3. For the most part the changes seem to be FreeBSD specific
 
 patch-src-findlib-create_file.c is based on his patch. I just added the 
 restore of the file flags on failure, and error messages in case of 
 failures. What is the problem with it and the CVS version?

I would like to put in a fix for the hardlink failure problem and possibly for 
the attiributes update errors problem, but I need as I said before:

1. A simple patch (or two if you want) that is the absolute minimal change and 
if at all possible modifies only FreeBSD code.

2. The diff must be done against the current CVS not against a file named 
xxx.orig which I have no idea where it came from or what version it is.  Look 
at Jeremy Reed's diff, you will see that it is done against the cvs and thus 
packed with all kinds of additional information that I need.  You may feel 
that I am being a bit picky here, which is probably the case, but this is 
documented in the Developer's manual and *really* helps to make communication 
of patch files and their integration *much* more smooth and sure.

3. A really minor point is that the patch should be an attachment (as you 
did), but it should be named xxx.patch  e.g. chflag.patch  or 
findlib-attribs.patch or create_file.patch.  What you are sending me is not 
a .c file, so shouldn't be named that way.  It makes reading it harder -- 
since then my email reader knows what the content is and calls the correct 
viewing program when I open it.

Regards,

Kern
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlin ks to schg secured files on FreeBSD on restore

[Oliver Lehmann]

Hi Kern, 

it is ok when you want me to deliver the patch in a defined format. I've no 
problems with that. I must say that I didn't read the developer manual 
before I sent the patch, but I hope the patch does now comply to the rules.
I've changed the indention from my former patch so you can see that 
everything which changed/was added was done inside the ifdef preprocessor 
directives.
This is a first step. The problems with the attribues can be fixed later. 
With this patch at least the links are getting created which is better than 
before. 


Greetings, Oliver
Index: src/findlib/create_file.c
===
RCS file: /cvsroot/bacula/bacula/src/findlib/create_file.c,v
retrieving revision 1.56
diff -u -r1.56 create_file.c
--- src/findlib/create_file.c   21 Nov 2006 20:14:46 -  1.56
+++ src/findlib/create_file.c   13 Dec 2006 10:53:22 -
@@ -289,9 +289,46 @@
  Dmsg2(130, Hard link %s = %s\n, attr-ofname, attr-olname);
  if (link(attr-olname, attr-ofname) != 0) {
 berrno be;
+#ifdef HAVE_CHFLAGS
+struct stat s;
+
+/*
+* If using BSD user flags, maybe has a file flag
+* preventing this. So attempt to disable, retry link,
+* and reset flags.
+* Note that BSD securelevel may prevent disabling flag.
+   */
+
+if (stat(attr-olname, s) == 0  s.st_flags != 0) {
+   if (chflags(attr-olname, 0) == 0) {
+  if (link(attr-olname, attr-ofname) != 0) {
+ /* restore original file flags even when linking failed */
+ if (chflags(attr-olname, s.st_flags)  0) {
+Qmsg2(jcr, M_ERROR, 0, _(Could not restore file flags 
for file %s: ERR=%s\n),
+  attr-olname, be.strerror());
+ }
+#endif /* HAVE_CHFLAGS */
 Qmsg3(jcr, M_ERROR, 0, _(Could not hard link %s - %s: ERR=%s\n),
   attr-ofname, attr-olname, be.strerror());
 return CF_ERROR;
+#ifdef HAVE_CHFLAGS
+  }
+  /* finally restore original file flags */
+  if (chflags(attr-olname, s.st_flags)  0) {
+ Qmsg2(jcr, M_ERROR, 0, _(Could not restore file flags 
for file %s: ERR=%s\n),
+attr-olname, be.strerror());
+  }
+   } else {
+ Qmsg2(jcr, M_ERROR, 0, _(Could not reset file flags for file 
%s: ERR=%s\n),
+   attr-olname, be.strerror());
+   }
+} else {
+  Qmsg3(jcr, M_ERROR, 0, _(Could not hard link %s - %s: 
ERR=%s\n),
+attr-ofname, attr-olname, be.strerror());
+  return CF_ERROR;
+}
+#endif /* HAVE_CHFLAGS */
+
  }
  return CF_CREATED;
 #endif
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Postgres slow because of autocommit

[Gabriele Bulfon]

Hello,
I stumbled upon some pages that confirm a suspect I had about using postgres 
with bacula:
- Postgres has autocommit by default, slowing down a lot any Bacula operation 
because Bacula does not use any transaction during write.
If this is truedo I have any way to set up just the Bacula database (not 
the other ones I have) to have no autocommit?
Is there any pre-script to set the bacula connection without auto commit?
Gabriele.
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] restore data saved from windows into a linux

[Marco Strullato]

Hello!
I have to restore data saved from windows into a linux box but I get
this error:Error: Win32 GZIP data stream not supported on this Client.

How shoud I do?

Thanks

Marco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] restore data saved from windows into a linux

[Ger Apeldoorn]

You've got to restore it to a Windows box. 

The compression algorithm is different.

Ger.

Op woensdag 13 december 2006 14:33, schreef Marco Strullato:
 Hello!
 I have to restore data saved from windows into a linux box but I get
 this error:Error: Win32 GZIP data stream not supported on this Client.

 How shoud I do?



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Postgres slow because of autocommit

[Bill Moran]

In response to Gabriele Bulfon [EMAIL PROTECTED]:
 Hello,
 I stumbled upon some pages that confirm a suspect I had about using
 postgres with bacula:
 - Postgres has autocommit by default, slowing down a lot any Bacula
 operation because Bacula does not use any transaction during write.
 If this is truedo I have any way to set up just the Bacula database
 (not the other ones I have) to have no autocommit?
 Is there any pre-script to set the bacula connection without auto commit?

There is no way (that I'm aware of) to disable autocommit.

By definition, any database that's not being fed transactions is in
autocommit mode (PostgreSQL actually calls this unchained mode).
It makes sense: without an explicit transaction, how would the DB
server know when to commit the data?  I don't know of any DB that
does it any differently.

That being said, the Bacula team has been working hard at adding
transaction support and other performance improvements -- if you
search the list archives, you'll see lots of discussions.  I think
some of the improvements are slated to appear in the next version.

That being said, PostgreSQL runs just fine even without the transactions.
Everything I run uses PostgreSQL (I manage 4 directors).  Two of them
manage large data sets using beefy hardware (of 25 servers, 1 of them
has 1,500,000 files/12G compressed)  Another one is my laptop, and the
fourth is a medium-grade machine backing up about 20G of servers and
desktops.  None of them are experiencing any performance problems.

-- 
Bill Moran
Collaborative Fusion Inc.

[EMAIL PROTECTED]
Phone: 412-422-3463x4023

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Jeremy C. Reed]

 patch-src-findlib-create_file.c
   Try to unset file flags of the sourcefile when the hardlink failed.
   Retry to hardlink then. If the hardlink fails then again, restore the
   file flags of the sourcefile. If the hardlink was created w/o errors,
   restore the fileflags of the sourcefile.

Why do the chflags(attr-olname, s.st_flags) restore the fileflags of the 
sourcefile twice?

Also the first reset of the chflags() should probably have error checking 
and debugging there too (specific for that). (That's what I have added to 
my own code.)

 patch-src-findlib-attribs.c
   when restoring a symlink, use lchflags to restore the file flags
   defined for the symlink (new feature)
   when restoring a hardlink, don't call chmod, chown, utime because it is
   a hardlink and don't  have such attributes (as far as I know, if someone
   with more FS-foo can step up and confirm this?). Changing this
   attributes will change the sourcefiles attributes which is probably not
   what is wanted here anyway

I don't understand this but may look closer at your code.

A hardlink is just a normal file -- it does have mode, ownership and 
access and modification times. (I think maybe you just typed wrong word 
above and didn't mean that.)

Also a symlink has a mode (which can be changed but probably on all BSDs 
it isn't even honored), ownership and modification time (time of symlink 
creation) and change time (time of last file status change). I can see all 
of this easily. (I am not sure if access time ever changes as I didn't 
look at source and never saw that.)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Kern Sibbald]

On Wednesday 13 December 2006 12:01, Oliver Lehmann wrote:
 Hi Kern, 
 
 it is ok when you want me to deliver the patch in a defined format. I've no 
 problems with that. I must say that I didn't read the developer manual 
 before I sent the patch, but I hope the patch does now comply to the rules.
 I've changed the indention from my former patch so you can see that 
 everything which changed/was added was done inside the ifdef preprocessor 
 directives.

Yes, nice.  Thanks.  That is a big help. :-)

 This is a first step. The problems with the attribues can be fixed later. 
 With this patch at least the links are getting created which is better than 
 before. 

Many thanks.  Your patch looks perfectly fine to me.  I'll integrate it 
shortly.

 
 Greetings, Oliver
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] FD service repeatedly crashing on Windows Server 2003

[Michal Winsor]

Thanks for your reply Robert.

I will make the change and see how it works.

- Michal

-- 
Michal J. Winsor, ISP
Information Technology Analyst

Open Systems Canada Limited
1627 Broad Street
Regina, SK S4P1X3
Tel.: 306.359.6725
http://www.oscl.ca



Robert Nelson wrote:
 Short Answer:

   Don't do that.

 Long Answer:
   Bacula-fd is an interactive service (it interacts with the desktop
 user) it must be run using the System account.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Michal
 Winsor
 Sent: Tuesday, December 12, 2006 7:48 AM
 To: bacula-users@lists.sourceforge.net
 Subject: [Bacula-users] FD service repeatedly crashing on Windows Server
 2003

 Hello,

 I have a multi machine Bacula setup.  The Director and Storage Daemons 
 are running on Linux.  Two File Daemons are running on Windows Server 
 2003 SP1.

 The file daemon services on WS2K3 seem to crash on a regular basis.  I 
 setup service recovery (restart) after 15 minutes, but the end result is 
 that the service is not running and backups are failing.

 The file daemon services are running under a special sys_backup user 
 identity which is a member of the Backup Operators group and has read 
 permissions to the folders to be backed up.

 Has anyone seen this?

 Thanks for your help in advance.

 - Michal

   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Postgres slow because of autocommit

[Gabriele Bulfon]

I came across the performance problem with SPARC Sun280R machines, at first, 
because they have a slower processor then modern AMD or x86 machines.
On sparc machines large backups cannot be managed, because the transfer rate of 
the LTO is slowed down up to 1Mb/s or lower, because of the slow performance of 
Postgres on the same machine.
Moving the DB on another x86 / amd machine solve the problem, but I anyway can 
reach a maximum rate of 8-10Mb/sec, that is not the maximum transfer rate I may 
have on those LTO drives (that may run from 15 to 60 to 120 Mb/s depending on 
the version).
On x86/amd machines, the transfer is higher and acceptable, but yet not using 
the full potential of the scsi library or tape drive, that is anyway lower than 
it may be, always because postgres is slowing down the bacula process.
I am happy to know that we're gonna have a release with transactions, and see 
what happens.
Thanx a lot,
Gabriele.
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
--
Da: Bill Moran [EMAIL PROTECTED]
A: Gabriele Bulfon [EMAIL PROTECTED]
Cc: bacula-users@lists.sourceforge.net
Data: 13 dicembre 2006 15.09.50 CET
Oggetto: Re: [Bacula-users] Postgres slow because of autocommit
In response to Gabriele Bulfon [EMAIL PROTECTED]:
 Hello,
 I stumbled upon some pages that confirm a suspect I had about using
 postgres with bacula:
 - Postgres has autocommit by default, slowing down a lot any Bacula
 operation because Bacula does not use any transaction during write.
 If this is truedo I have any way to set up just the Bacula database
 (not the other ones I have) to have no autocommit?
 Is there any pre-script to set the bacula connection without auto commit?
There is no way (that I'm aware of) to disable autocommit.
By definition, any database that's not being fed transactions is in
autocommit mode (PostgreSQL actually calls this unchained mode).
It makes sense: without an explicit transaction, how would the DB
server know when to commit the data?  I don't know of any DB that
does it any differently.
That being said, the Bacula team has been working hard at adding
transaction support and other performance improvements -- if you
search the list archives, you'll see lots of discussions.  I think
some of the improvements are slated to appear in the next version.
That being said, PostgreSQL runs just fine even without the transactions.
Everything I run uses PostgreSQL (I manage 4 directors).  Two of them
manage large data sets using beefy hardware (of 25 servers, 1 of them
has 1,500,000 files/12G compressed)  Another one is my laptop, and the
fourth is a medium-grade machine backing up about 20G of servers and
desktops.  None of them are experiencing any performance problems.
--
Bill Moran
Collaborative Fusion Inc.
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Attila Fülöp]

Folks,

just to dropping  into this discussion.

Kern Sibbald wrote:
 On Wednesday 13 December 2006 08:49, Oliver Lehmann wrote:
 a Kern Sibbald writes: 
 patch-src-findlib-attribs.c
   when restoring a symlink, use lchflags to restore the file flags
   defined for the symlink (new feature)

This is right, but only part of a bigger problem. FreeBSD, as opposed to
other OSes allows symlinks to have own permissions ACL etc and offers
appropriate syscalls. Specifically this are lchmod, lutimes, lchflags
acs_set/get_link_np.

I have written a patch witch addresses this issue. So this patch will
interfere with my changes. I would prefer not to have above mentioned
new feature in the CVS since this will surely give me conflicts on
next cvs update.

I'm in the process of writing the regression scripts for my patches.
Since my patch addresses other stuff (mostly ACL code, and some minor
fixes) and the writing of regression scripts isn't that well documented
this may take some time. Nonetheless I hope to have the testing done
until next Monday.

I will look into the other new patches this evening to see if they
interfere with my changes and report back tomorrow.

Attila

   when restoring a hardlink, don't call chmod, chown, utime because it is
   a hardlink and don't  have such attributes (as far as I know, if 
 someone
   with more FS-foo can step up and confirm this?). Changing this
   attributes will change the sourcefiles attributes which is probably not
   what is wanted here anyway
 I'll have to think about this a bit more.  However, I don't think it is 
 correct to skip setting the attributes.  To understand hardlinks, the 
 first 
 thing is to realize that the name is slightly misleading.  A hard link is 
 not 
 really a link.  The data for the two files the attributes are one and the 
 same.  The situation is very different from a softlink where there is a 
 separate directory entry that points to an existing file.   

 Thus to properly restore a hardlink you must also reset the attributes or 
 you 
 could potentially end up with incorrect attributes (owner, modes, ...).
 Ok, but from my understanding setting attributes on a hardlink changes the 
 attributes of the inode the hardlink is pointing to, like for normal files 
 which are technically hardlinks too. 
 
 There is no such think as a hardlink.  There is a hardlink operation.  It is 
 very different from a softlink, and if you think about them the same way, you 
 will never get it right.  Two files that are hardlinked (really poor 
 terminology) *are* one and the same file.  The two files share the same 
 inode, so there is no hardlink with separate attributes that points to an 
 inode (as is the case for a softlink, which is a pointer).   For hardlinked 
 files, there is only one set of data and one set of attributes.
 
 So changing attributes for n objects  
 pointing to the same inode is like changing the attributes n times for the 
 same object or is this wrong?
 
 There are n filenames that share the same data and attributes true, and if 
 you 
 are doing a full restore, it is possible Bacula will set those attributes to 
 the same thing n times since each of Bacula's n representations of the 
 hardlinked files contains the attributes (there is only one copy of the data 
 though).  Ideally, Bacula would set the attributes only once when it restores 
 the data, but I would have to look at the code (which I don't have the time 
 to do) to remember exactly what Bacula does.
 
 If you think attributes for hardlinks have to be restored as well, the fix 
 for src/findlib/attribs.c has to be redone. I can do so but I still 
 think ;)
 
 Ideally as I mentioned above, the attributes are only kept with the data and 
 thus are only set one time.  Then when a second filename is found it would 
 simply be hardlinked to the first file (i.e. become one and the same) and it 
 would not then be necessary to re-set the attributes.  If this is what your 
 patch does, then it is probably OK.  If not, we need to re-think it.  In any 
 case, this could be a rather fundamental change to how the low level part of 
 Bacula works, and I am a bit worried about trying to include it in version 
 1.40.0.
 
 Regards,
 
 Kern
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/bacula-devel
 
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through 

[Bacula-users] about the 1.40 version release

[Jaime Ventura]

Hello,
   I've read a few messages ago that the new stable version of 
bacula would be released 'till the end of 2006. Does this sting stand?
   On The Current State of Bacula -- 1.39.29 (01 December 2006) 
its says Configurable TLS (SSL) communications encryption 
http://www.bacula.org/dev-manual/Bacula_TLS_Communication.html#CommEncryption 
between each component
   Does the w32 client supports such feature or just the *nix?
   Thanks.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] GNUAutconf IPV6 Testing Strategy (WAS: [Fwd: [Bacula-devel] GNU autconf macro for HAVE_IPV6 check on NetBSD])

[Brian A. Seklecki]

It seems that there are actually several permutations of systems by
which the IPv6 checks needs to take into account:

- Systems that don't support ipv6 (Minix)
- Systems that support ipv6 and have both kernel and userland support
  compiled in and headers present
- Systems that shipped/installed with ipv6 userland/kernel, but the
  administrator disabled ipv6 during the _kernel_ profiling process
- Systems that shipped/installed with ipv6 userland/kernel, but the
  administrator disabled ipv6 during the _kernel profiling process_ AND
  recompiled the entire _user-land_ (a la, libc) w/ NO_IPV6=true in
  mk.conf(5) / make.conf(5) but the ipv6 headers/libraries remain 
  although no binaries are linked into them.
- Systems that support ipv6 in the kernel/userland but lack headers
  (Which would be just about every distribution of Linux by default
   since install every package never seems to imply ($1)-devel.*
  RPMs.)

The current macro/test simply tries instantiate an ipv6 addr struct; but
doesn't actually try to move between userland and kernel to validate
functionality.

That's what is causing the breakage here in NetBSD. The problem is that
the symbol in question is not contained within libc after a recompile.
In my case, the system has been profiled.

Perhaps additional macros could could be instituted which not only try
to instantiate copies of inet6 address structures but actually utilize
them (perhaps try to bind(2) or connect(2)

The work-around here is to declare:

USE_INET6=no
MKINET6=no
NO_INET6=no
HAVE_IPV6=no

in mk.conf(5)

As for Pkgsrc and buildlink3 magic, it would be nice if:
PKG_DEFAULT_OPTIONS+=-inet6
PKG_OPTIONS.bacula= -inet6

...somehow tricked configure[.sh] about the availability
of /usr/include/netinet6/*

Bacula could help facilitate by implementing a --without-ipv6 or
--disable-ipv6 GNU autoconf flag.

I've filed a bug at http://bugs.bacula.org/ Mantis.  Although this is
not actually a Bacula Code Bug, this is an excellent opportunity to
improve and feed-back more aggressive ipv6 test macros to the
GNUAutoconf people (who really don't have a bug management system)

TIA,

~BAS

-- 
Brian A. Seklecki [EMAIL PROTECTED]
Collaborative Fusion, Inc.
---BeginMessage---
[not sure if this is a user-@ or devel-@ topic -- the last/only ipv6
discussion I saw was to -users, so when you respond, please choose the
appropriate]

All:

The GNU autoconf macro below is what we use to test for IPv6 in 1.38.10.
It tries simply to instantiate a number of ipv6 structures.

However, on my platform (NetBSD/sparc 3_STABLE), it seems that it's
possible to confuse or mitigate/bypass this test ( I haven't tested
OpenBSD/FreeBSD for his behavior yet, because I know NetBSD does some
special IPV4 to IPV6 address mapping, and has some special IPV6
sysctls).

The IPV6 netinet6 socket family includes can be  in
/usr/include/netinet6 , configure will find them, compile conftest.c
just fine, and pass this test, however the system can be built without
IPV6 support (removed from all of the userland binaries) and the Kernel.

The result is that Bacula compiles and links against IPV6 headers fine,
but when it runs, it fails to compile later on during the build:

== Entering
directory /usr/pkgsrc/sysutils/bacula-clientonly/work/bacula-1.38.10/src/console

[SNIP]

/usr/pkgsrc/sysutils/bacula-clientonly/work/.wrapper/bin/c++ -L/usr/lib
-Wl,-R/usr/lib -pthread -Wl,-R/usr/pkg/lib  -L../lib -L../cats -o
bconsole console.o console_conf.o authenticate.o conio.o   -ltermcap
-lbac -lm -pthread  -lintl   

../lib/libbac.a(address_conf.o)(.text+0x35c): In function
`IPADDR::set_addr_any()':
: undefined reference to `in6addr_any'
../lib/libbac.a(address_conf.o)(.text+0x360): In function
`IPADDR::set_addr_any()':
: undefined reference to `in6addr_any'
../lib/libbac.a(address_conf.o)(.text+0x364): In function
`IPADDR::set_addr_any()':
: undefined reference to `in6addr_any'
*** Error code 1

The work around is to interrupt the build process and manually define
HAVE_INET6 0 in src/config.h in the mean time.

So what we may need  to do is:

A) A more-aggressive ipv6 support test.  
B) A --without-ipv6 or --disable-ipv6 argument that explicity defines
   HAVE_IPV6 0
C) Or I may need to put a work-around in place for NetBSD (Bad)


The way some packages do it (Zebra) is:

# Check whether --enable-ipv6 or --disable-ipv6 was given.
if test ${enable_ipv6+set} = set; then
  enableval=$enable_ipv6
fi;

- MACRO 

echo $as_me:$LINENO: checking for IPv6 support 5
echo $ECHO_N checking for IPv6 support... $ECHO_C 6
if test ${ac_cv_ipv6_support+set} = set; then
  echo $ECHO_N (cached) $ECHO_C 6
else
  cat conftest.$ac_ext _ACEOF
/* confdefs.h.  */
_ACEOF
cat confdefs.h conftest.$ac_ext
cat conftest.$ac_ext _ACEOF
/* end confdefs.h.  */
 #include sys/types.h
#include sys/socket.h
#include netinet/in.h
int
main ()
{
struct sockaddr_in6 s; struct in6_addr t=in6addr_any; int i=AF_INET6; s;
t.s6_addr[0] =
 0;
  ;
  return 0;
}
_ACEOF
rm 

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Kern Sibbald]

On Wednesday 13 December 2006 16:07, Attila Fülöp wrote:
 Folks,
 
 just to dropping  into this discussion.
 
 Kern Sibbald wrote:
  On Wednesday 13 December 2006 08:49, Oliver Lehmann wrote:
  a Kern Sibbald writes: 
  patch-src-findlib-attribs.c
when restoring a symlink, use lchflags to restore the file flags
defined for the symlink (new feature)
 
 This is right, but only part of a bigger problem. FreeBSD, as opposed to
 other OSes allows symlinks to have own permissions ACL etc and offers
 appropriate syscalls. Specifically this are lchmod, lutimes, lchflags
 acs_set/get_link_np.
 
 I have written a patch witch addresses this issue. So this patch will
 interfere with my changes. I would prefer not to have above mentioned
 new feature in the CVS since this will surely give me conflicts on
 next cvs update.
 
 I'm in the process of writing the regression scripts for my patches.
 Since my patch addresses other stuff (mostly ACL code, and some minor
 fixes) and the writing of regression scripts isn't that well documented
 this may take some time. Nonetheless I hope to have the testing done
 until next Monday.
 
 I will look into the other new patches this evening to see if they
 interfere with my changes and report back tomorrow.

I would be very happy if you will provide a patch.  However, there is almost 
zero chance that it will go in before 1.40.0 is released.  The only fixes 
that I am accepting at the moment are important bug fixes that do not disrupt 
the code too much.  I suggest you simply pull down the new file after I have 
integrated the patch and adjust your code to work with it.  This is, 
unfortunately, something that developers must do quite often.

Concerning all these differences on FreeBSD:  if the changes needed to make 
things work correctly on FreeBSD are extensive and require a bit of 
#ifdefing, we are going to have to re-think how we do it.  The code is 
already a bit messy and adding more non-standard system dependent code will 
push it over my tolerance of messyness.  As a consequence, we will need to 
look at ways of making it cleaner --- e.g. moving some of the code, possibly 
the system dependent code into subroutines ...

 
 Attila
 
when restoring a hardlink, don't call chmod, chown, utime because it 
is
a hardlink and don't  have such attributes (as far as I know, if 
  someone
with more FS-foo can step up and confirm this?). Changing this
attributes will change the sourcefiles attributes which is probably 
not
what is wanted here anyway
  I'll have to think about this a bit more.  However, I don't think it is 
  correct to skip setting the attributes.  To understand hardlinks, the 
  first 
  thing is to realize that the name is slightly misleading.  A hard link 
is 
  not 
  really a link.  The data for the two files the attributes are one and 
the 
  same.  The situation is very different from a softlink where there is a 
  separate directory entry that points to an existing file.   
 
  Thus to properly restore a hardlink you must also reset the attributes 
or 
  you 
  could potentially end up with incorrect attributes (owner, modes, ...).
  Ok, but from my understanding setting attributes on a hardlink changes 
the 
  attributes of the inode the hardlink is pointing to, like for normal 
files 
  which are technically hardlinks too. 
  
  There is no such think as a hardlink.  There is a hardlink operation.  It 
is 
  very different from a softlink, and if you think about them the same way, 
you 
  will never get it right.  Two files that are hardlinked (really poor 
  terminology) *are* one and the same file.  The two files share the same 
  inode, so there is no hardlink with separate attributes that points to 
an 
  inode (as is the case for a softlink, which is a pointer).   For 
hardlinked 
  files, there is only one set of data and one set of attributes.
  
  So changing attributes for n objects  
  pointing to the same inode is like changing the attributes n times for 
the 
  same object or is this wrong?
  
  There are n filenames that share the same data and attributes true, and if 
you 
  are doing a full restore, it is possible Bacula will set those attributes 
to 
  the same thing n times since each of Bacula's n representations of the 
  hardlinked files contains the attributes (there is only one copy of the 
data 
  though).  Ideally, Bacula would set the attributes only once when it 
restores 
  the data, but I would have to look at the code (which I don't have the 
time 
  to do) to remember exactly what Bacula does.
  
  If you think attributes for hardlinks have to be restored as well, the 
fix 
  for src/findlib/attribs.c has to be redone. I can do so but I still 
  think ;)
  
  Ideally as I mentioned above, the attributes are only kept with the data 
and 
  thus are only set one time.  Then when a second filename is found it would 
  simply be hardlinked to the first file (i.e. become one and the same) and 
it 
 

[Bacula-users] Backups Successful - Restores Fail

[jpg]

Need some guidance on how to restore a single file.

Successfully configured and did a full backup of filesystem
spanning 4 tapes in autochanger.

Renamed a test file from 'ob' to 'ob.orig'. Then requested a
restore of the file 'ob'.

Restore said it completed successfully, however the 'ob' file
was NOT restored.

Help.
-jpg


Screen dump of bacula-console-gnome.
=
restore

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
 1: List last 20 Jobs run
 2: List Jobs where a given File is saved
 3: Enter list of comma separated JobIds to select
 4: Enter SQL list command
 5: Select the most recent backup for a client
 6: Select backup for a client before a specified time
 7: Enter a list of files to restore
 8: Enter a list of files to restore before a specified time
 9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Cancel
Select item:  (1-12): 1
+---+-+-+--+--++
| JobId | Client  | StartTime   | JobLevel | JobFiles | JobBytes
   |
+---+-+-+--+--++
| 4 | hpcvsjpg-fd | 2006-12-12 18:00:03 | F| 118  | 72050657
   |
| 3 | hpcvsjpg-fd | 2006-12-12 07:31:08 | F| 128292   | 17876337782 
   |
| 1 | hpcvsjpg-fd | 2006-12-11 12:24:08 | F| 127416   | 17776636886 
   |
+---+-+-+--+--++
To select the JobIds, you have the following choices:
 1: List last 20 Jobs run
 2: List Jobs where a given File is saved
 3: Enter list of comma separated JobIds to select
 4: Enter SQL list command
 5: Select the most recent backup for a client
 6: Select backup for a client before a specified time
 7: Enter a list of files to restore
 8: Enter a list of files to restore before a specified time
 9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Cancel
Select item:  (1-12): 7
Automatically selected Client: hpcvsjpg-fd
Enter file names with paths, or  to enter a filename
containing a list of file names with paths, and terminate
them with a blank line.
Enter full filename: /home/jpg/ob9
Enter full filename: 
Bootstrap records written to /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr

The job will require the following Volumes:
   
   TapeDiff0003


1 file selected to be restored.

Run Restore job
JobName:RestoreFiles
Bootstrap:  /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr
Where:  /tmp/bacula-restores
Replace:always
FileSet:HomeDirs
Client: hpcvsjpg-fd
Storage:SureStore12000e
When:   2006-12-13 07:42:43
Catalog:hpcvsjpgCatalog
Priority:   10
OK to run? (yes/mod/no): yes
Job started. JobId=5
13-Dec 07:42 hpcvsjpg-dir: Start Restore Job RestoreFiles.2006-12-13_07.42.55
13-Dec 07:42 hpcvsjpg-sd: 3301 Issuing autochanger loaded drive 0 command.
13-Dec 07:42 hpcvsjpg-sd: 3302 Autochanger loaded drive 0, result is Slot 3.
13-Dec 07:44 hpcvsjpg-sd: Ready to read from volume TapeDiff0003 on device 
SureStore12000e (/dev/nst0).
13-Dec 07:44 hpcvsjpg-sd: Forward spacing to file:block 3:0.
13-Dec 07:46 hpcvsjpg-sd: End of Volume at file 3 on device SureStore12000e 
(/dev/nst0), Volume TapeDiff0003
13-Dec 07:46 hpcvsjpg-sd: End of all volumes.
13-Dec 07:46 hpcvsjpg-dir: Bacula 1.38.11 (28Jun06): 13-Dec-2006 07:46:17
  JobId:  5
  Job:RestoreFiles.2006-12-13_07.42.55
  Client: hpcvsjpg-fd
  Start time: 13-Dec-2006 07:42:57
  End time:   13-Dec-2006 07:46:17
  Files Expected: 1
  Files Restored: 1
  Bytes Restored: 25
  Rate:   0.0 KB/s
  FD Errors:  0
  FD termination status:  OK
  SD termination status:  OK
  Termination:Restore OK

13-Dec 07:46 hpcvsjpg-dir: Begin pruning Jobs.
13-Dec 07:46 hpcvsjpg-dir: No Jobs found to prune.
13-Dec 07:46 hpcvsjpg-dir: Begin pruning Files.
13-Dec 07:46 hpcvsjpg-dir: No Files found to prune.
13-Dec 07:46 hpcvsjpg-dir: End auto prune.

=

contents of Bootstrap:  /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr
=
Volume=TapeDiff0003
MediaType=DDS-2
VolSessionId=3
VolSessionTime=1165867195

Re: [Bacula-users] Backups Successful - Restores Fail

[Scott Farmer]

Did you look for the file in the temp directory the file was restored 
to? In your config below the restore process shows the base path where 
the file was restored. The files will not be restored to the original 
path unless you change that option when you run the restore, or change 
the path in your configuration.


Run Restore job
JobName:RestoreFiles
Bootstrap:  /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr
Where:  */tmp/bacula-restores*



jpg wrote:

Need some guidance on how to restore a single file.

Successfully configured and did a full backup of filesystem
spanning 4 tapes in autochanger.

Renamed a test file from 'ob' to 'ob.orig'. Then requested a
restore of the file 'ob'.

Restore said it completed successfully, however the 'ob' file
was NOT restored.

Help.
-jpg


Screen dump of bacula-console-gnome.
=
restore

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
 1: List last 20 Jobs run
 2: List Jobs where a given File is saved
 3: Enter list of comma separated JobIds to select
 4: Enter SQL list command
 5: Select the most recent backup for a client
 6: Select backup for a client before a specified time
 7: Enter a list of files to restore
 8: Enter a list of files to restore before a specified time
 9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Cancel
Select item:  (1-12): 1
+---+-+-+--+--++
| JobId | Client  | StartTime   | JobLevel | JobFiles | JobBytes
   |
+---+-+-+--+--++
| 4 | hpcvsjpg-fd | 2006-12-12 18:00:03 | F| 118  | 72050657
   |
| 3 | hpcvsjpg-fd | 2006-12-12 07:31:08 | F| 128292   | 17876337782 
   |
| 1 | hpcvsjpg-fd | 2006-12-11 12:24:08 | F| 127416   | 17776636886 
   |
+---+-+-+--+--++
To select the JobIds, you have the following choices:
 1: List last 20 Jobs run
 2: List Jobs where a given File is saved
 3: Enter list of comma separated JobIds to select
 4: Enter SQL list command
 5: Select the most recent backup for a client
 6: Select backup for a client before a specified time
 7: Enter a list of files to restore
 8: Enter a list of files to restore before a specified time
 9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Cancel
Select item:  (1-12): 7
Automatically selected Client: hpcvsjpg-fd
Enter file names with paths, or  to enter a filename
containing a list of file names with paths, and terminate
them with a blank line.
Enter full filename: /home/jpg/ob9
Enter full filename: 
Bootstrap records written to /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr


The job will require the following Volumes:
   
   TapeDiff0003



1 file selected to be restored.

Run Restore job
JobName:RestoreFiles
Bootstrap:  /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr
Where:  /tmp/bacula-restores
Replace:always
FileSet:HomeDirs
Client: hpcvsjpg-fd
Storage:SureStore12000e
When:   2006-12-13 07:42:43
Catalog:hpcvsjpgCatalog
Priority:   10
OK to run? (yes/mod/no): yes
Job started. JobId=5
13-Dec 07:42 hpcvsjpg-dir: Start Restore Job RestoreFiles.2006-12-13_07.42.55
13-Dec 07:42 hpcvsjpg-sd: 3301 Issuing autochanger loaded drive 0 command.
13-Dec 07:42 hpcvsjpg-sd: 3302 Autochanger loaded drive 0, result is Slot 3.
13-Dec 07:44 hpcvsjpg-sd: Ready to read from volume TapeDiff0003 on device 
SureStore12000e (/dev/nst0).
13-Dec 07:44 hpcvsjpg-sd: Forward spacing to file:block 3:0.
13-Dec 07:46 hpcvsjpg-sd: End of Volume at file 3 on device SureStore12000e 
(/dev/nst0), Volume TapeDiff0003
13-Dec 07:46 hpcvsjpg-sd: End of all volumes.
13-Dec 07:46 hpcvsjpg-dir: Bacula 1.38.11 (28Jun06): 13-Dec-2006 07:46:17
  JobId:  5
  Job:RestoreFiles.2006-12-13_07.42.55
  Client: hpcvsjpg-fd
  Start time: 13-Dec-2006 07:42:57
  End time:   13-Dec-2006 07:46:17
  Files Expected: 1
  Files Restored: 1
  Bytes Restored: 25
  Rate:   0.0 KB/s
  FD Errors:  0
  FD termination status:  OK
  SD termination status:  OK
  Termination:Restore OK

13-Dec 07:46 hpcvsjpg-dir: Begin pruning Jobs.
13-Dec 07:46 hpcvsjpg-dir: 

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Oliver Lehmann]

Jeremy C. Reed wrote:


 Why do the chflags(attr-olname, s.st_flags) restore the fileflags of the 
 sourcefile twice?

once in case the 2nd linking failed (there is a return after that!)
and the 2nd time for the linking was successfull case.


 Also the first reset of the chflags() should probably have error checking 
 and debugging there too (specific for that). (That's what I have added to 
 my own code.)

The first chflags has error checking and reporting (rest file flags to
none)
   Qmsg2(jcr, M_ERROR, 0, _(Could not reset file flags for file %s: ERR=%s\n),

The second chflags has error checking and reporting as well (restore file
flags in case of 2nd linking failed too and return)
   Qmsg2(jcr, M_ERROR, 0, _(Could not restore file flags for file %s: 
ERR=%s\n),

The third chflags has error checking and reporting as well (restore file
flags in case of linking was successfull)
   Qmsg2(jcr, M_ERROR, 0, _(Could not restore file flags for file %s: 
ERR=%s\n),


 A hardlink is just a normal file -- it does have mode, ownership and 
 access and modification times. (I think maybe you just typed wrong word 
 above and didn't mean that.)

Better say a normal/regular file is just another hardlink ;)
All hardlinks/normal/regular files/whatever pointing to the same inode. This
is why all hardlinks share the same attributes. Attributes are along with other
file informations stored inside the inode. - all hardlinks same attributes.
Thats why I said that setting attributes for, you might say the same inode,
more than once doesn't need to be. That was why I changed set_attributes()
to not set the attributes again when the filetype is FT_LNKSAVED because then
there is another file pointing to the same inode, already in the filesystem
or has been restored before (otherwise the link() call in create_file would
have failed). In the first case setting the attributes would be even wrong.
In the second case it would not harm to set the attributes once more if there
wouldn't be such file flags like schg which are preventing this.

 
 Also a symlink has a mode (which can be changed but probably on all BSDs 
 it isn't even honored), ownership and modification time (time of symlink 
 creation) and change time (time of last file status change). I can see all 
 of this easily.

A Symlink can have its own attributs which can be set too (lchmod(), lchown(),
lutimes()), this is right because it has an own inode to store the information.



-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] Win32: LabelFormat Directive Syntax

[Erich Prinz]

On Dec 13, 2006, at 1:40 AM, Robert Nelson wrote:

 Do you mean the result was clientname-Day_12?  If so that would be  
 expected.

Yes, these were the results. Good!

 According to the grammar in the manual, the curly braces are  
 optional if you
 are just expanding the name.  If you want to take advantage of the :
 commands then you need the braces.

 As for the need for quotes, They are only needed if the string  
 contains one
 or more of the following characters: '=', '{', '}', ';', ' ' or ','.

Then my misunderstanding of the syntax driven by late nights and  
early mornings.

Thanks for the clarification on this...


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of  
 Erich Prinz
 Sent: Tuesday, December 12, 2006 8:05 PM
 To: Robert Nelson
 Cc: 'bacula-devel Development'
 Subject: Re: [Bacula-devel] Win32: LabelFormat Directive Syntax

 Now I'm unable to duplicate the issue either.

 Here is the Pool conf (working at this time)

 # Default pool definition
 Pool {
Name = Default
Use Volume Once = yes
Pool Type = Backup
Recycle = yes   # Bacula can automatically
 recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 719h   # 29 days 23 hours
Label Format = $Client-Day_$Day
MaximumVolumes = 6
MaximumVolumeJobs = 1

 }

 Notice there are no braces or double quotes and this yields the
 output  clientname_12  as an example.

 Erich

 On Dec 12, 2006, at 4:15 PM, Robert Nelson wrote:

 I'm not able to duplicate either of the problems you report.  Could
 you send
 me copies of your Bacula-dir.conf and Bacula-sd.conf files as well
 as a
 capture of the debug output when you run a job that should  
 autolabel a
 volume?

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 Erich Prinz
 Sent: Monday, December 11, 2006 8:33 AM
 To: bacula-devel Development
 Subject: [Bacula-devel] Win32: LabelFormat Directive Syntax

 Hi Robert.

 I'm doing basic testing of the Win32 build of 1.39.30 with full
 install of the Dir, SD, and FD.

 Configuring the Director for automatic labeling of the disc based
 volumes has been an interesting exercise.

 Bacula Documentation shows the proper syntax as:

  LabelFormat = File-

 where the label and any variables are in double quotes. Configured in
 this manner, the volume label yields   .

 However, when leaving the double quotes off, the volume label is
 correctly applied  eg.  File-0001  and so on.

 Also, the Director fails to launch under these two conditions in the
 Pool section of dir-conf when present in the configuration setting:


  LabelFormat = ${Client}


  LabelFormat = ${Client}


 Erich

 - 
 -
 ---
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
 opinions on IT  business topics through brief surveys - and earn  
 cash
 http://www.techsay.com/default.php?
 page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/bacula-devel




 - 
 -
 ---
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
 opinions on IT  business topics through brief surveys - and earn  
 cash
 http://www.techsay.com/default.php?
 page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/bacula-devel



 -- 
 ---
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to  
 share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php? 
 page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/bacula-devel






-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] problems with hardlinks to schg secured files on FreeBSD on restore

[Alan Brown]

On Tue, 12 Dec 2006, Kern Sibbald wrote:

 The solution proposed is to keep file flags in a list and set them after
 all files have been restored, so that all hardlinks can be created. Though
 it is probably enough to do this for hardlinked files. Looks like this
 would make the restore code even more complicated.

 Not only is it more complicated, but it can be very expensive.  Suppose you
 are restoring a  million hard linked files.  That could mean that you need
 you will need to keep a list that could amount to hundreds of millions of
 bytes (you need to keep at least forward links, the full path and the file,
 as well as certain of the file attributes).

Sounds perfect for a database table

 But what is the solution if you restore a file from an incremental backup
 which is a hardlink to an IMMUTABLE file?

Um... why would you ever restore in place unless it's disaster recovery?

 Off hand, I would say that the FreeBSD guys have worked themselves into a big
 hole.   They have violated the rule that says that root can do anything.

Linux has similar issues for immutable filesystems. In many environments 
it's important that root _can't_ do anything unless it's taken the initial 
step of removing the safety catch off the shotgun first.

(Eg: Webservers, other easily compromised systems as a starting point)

AB

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] 1.38.11 - possible bug in Rerun Failed Levels.

[Alan Brown]

Can anyone else confirm this?



Rerun Failed Levels = yes

If an incremental job is scheduled to start before a full or differential 
job has completed (ie, still running): When the incremental job starts the 
previous (still running) job is detected as failed and the incremental 
is upgraded to full or differential.



It seems repeatable here but I'd like confirmation from someone else 
before filing it as a genuine bug.

AB


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Jeremy C. Reed]

On Wed, 13 Dec 2006, Kern Sibbald wrote:

 Concerning all these differences on FreeBSD:  if the changes needed to make 
 things work correctly on FreeBSD are extensive and require a bit of 
 #ifdefing, we are going to have to re-think how we do it.  The code is 
...

I just want to point out that this problem is not specific to FreeBSD. I 
am sure it will happen on many other (even non-BSD) operating systems too 
... but it just hasn't been reported yet.

Linux with standard ext2fs file system has the same behaviour: you can not 
create a link (hardlink) to target file that has the immutable file 
attribute. (This is easy to try.)

I am not familiar with this in Bacula though ... from a quick search 
through bacula/src I don't see any ioctl for setting ext2fs flags. If I am 
overlooking this, please point me to it.

I am curious about this since file system flags are handled for BSD 
systems, so why not others too? (If it does, please point me to it.)

The standard e2fsprogs suite provides source code for this. See 
lib/e2p/fsetflags.c and lib/e2p/fgetflags.c. This e2fsprogs code supports 
both Linux ext2fs and BSD (chflags and stat). I assume xfsprogs and 
progreiserfs have similar functionality and routines.

So what I am getting at ... instead of just ifdef'ing for HAVE_CHFLAGS, 
maybe it should have a common routines like fsetflags() and fgetflags() 
that can be adjusted for all.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] problems with hardlinks to schg secured files on FreeBSD on restore

[Kern Sibbald]

On Tuesday 12 December 2006 20:12, Alan Brown wrote:
 On Tue, 12 Dec 2006, Kern Sibbald wrote:
 
  The solution proposed is to keep file flags in a list and set them after
  all files have been restored, so that all hardlinks can be created. 
Though
  it is probably enough to do this for hardlinked files. Looks like this
  would make the restore code even more complicated.
 
  Not only is it more complicated, but it can be very expensive.  Suppose 
you
  are restoring a  million hard linked files.  That could mean that you need
  you will need to keep a list that could amount to hundreds of millions of
  bytes (you need to keep at least forward links, the full path and the 
file,
  as well as certain of the file attributes).
 
 Sounds perfect for a database table

Very slow, and besides the FD does not have access to any database.

 
  But what is the solution if you restore a file from an incremental backup
  which is a hardlink to an IMMUTABLE file?

 
 Um... why would you ever restore in place unless it's disaster recovery?

If I have blown a file away, I frequently restore directly.

 
  Off hand, I would say that the FreeBSD guys have worked themselves into a 
big
  hole.   They have violated the rule that says that root can do anything.
 
 Linux has similar issues for immutable filesystems. In many environments 
 it's important that root _can't_ do anything unless it's taken the initial 
 step of removing the safety catch off the shotgun first.
 
 (Eg: Webservers, other easily compromised systems as a starting point)
 
 AB
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Kern Sibbald]

On Wednesday 13 December 2006 17:20, Oliver Lehmann wrote:
 Jeremy C. Reed wrote:
 
 
  Why do the chflags(attr-olname, s.st_flags) restore the fileflags of the 
  sourcefile twice?
 
 once in case the 2nd linking failed (there is a return after that!)
 and the 2nd time for the linking was successfull case.
 
 
  Also the first reset of the chflags() should probably have error checking 
  and debugging there too (specific for that). (That's what I have added to 
  my own code.)
 
 The first chflags has error checking and reporting (rest file flags to
 none)
Qmsg2(jcr, M_ERROR, 0, _(Could not reset file flags for file %s: 
ERR=%s\n),
 
 The second chflags has error checking and reporting as well (restore file
 flags in case of 2nd linking failed too and return)
Qmsg2(jcr, M_ERROR, 0, _(Could not restore file flags for file %s: 
ERR=%s\n),
 
 The third chflags has error checking and reporting as well (restore file
 flags in case of linking was successfull)
Qmsg2(jcr, M_ERROR, 0, _(Could not restore file flags for file %s: 
ERR=%s\n),
 
 
  A hardlink is just a normal file -- it does have mode, ownership and 
  access and modification times. (I think maybe you just typed wrong word 
  above and didn't mean that.)
 
 Better say a normal/regular file is just another hardlink ;)
 All hardlinks/normal/regular files/whatever pointing to the same inode. This
 is why all hardlinks share the same attributes. Attributes are along with 
other
 file informations stored inside the inode. - all hardlinks same attributes.
 Thats why I said that setting attributes for, you might say the same inode,
 more than once doesn't need to be. That was why I changed set_attributes()
 to not set the attributes again when the filetype is FT_LNKSAVED because 
then
 there is another file pointing to the same inode, already in the filesystem
 or has been restored before (otherwise the link() call in create_file would
 have failed). In the first case setting the attributes would be even wrong.
 In the second case it would not harm to set the attributes once more if 
there
 wouldn't be such file flags like schg which are preventing this.

I encourage you to re-submit a patch for the above problem once 1.40.0 is out, 
possibly coordinating with Attila, since he seems to be working on something 
a bit more encompasing (attribs + ACLs, ...).


 
  
  Also a symlink has a mode (which can be changed but probably on all BSDs 
  it isn't even honored), ownership and modification time (time of symlink 
  creation) and change time (time of last file status change). I can see all 
  of this easily.
 
 A Symlink can have its own attributs which can be set too (lchmod(), 
lchown(),
 lutimes()), this is right because it has an own inode to store the 
information.
 
 
 
 -- 
  Oliver Lehmann
   http://www.pofo.de/
   http://wishlist.ans-netz.de/
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/bacula-devel
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] The number of files mismatch!

[Forrest England]

Thanks for all the helpful responses,
that gives me a better idea of how the volumefiles field is used.
Wierd thing is the btape test and fill commands run without a hitch with the 
bacula-sd.conf I'm using.
I've found a way to work around it so I can get some backups while I get it 
working right.
I guess I'll keep playing with settings for the drive and taking a closer look 
at the debugging output for bacula-sd.

this is on a machine running Centos 3.4 by the way
changer I'm testing with is a Exabyte AutoPAK 1x10
though I have the same exact problem on another machine running fedora core 2
with a Dell PV-132T lto changer

-- 
__
Forrest England | System Administrator
Dealer.com
V 802.658.0965 x179
[EMAIL PROTECTED] | www.dealer.com 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Postgres slow because of autocommit

[Kern Sibbald]

On Wednesday 13 December 2006 15:57, Gabriele Bulfon wrote:
 I came across the performance problem with SPARC Sun280R machines, at first, 
because they have a slower processor then modern AMD or x86 machines.
 On sparc machines large backups cannot be managed, because the transfer rate 
of the LTO is slowed down up to 1Mb/s or lower, because of the slow 
performance of Postgres on the same machine.

I don't think that the performance of the tape writing speed has anything to 
do with the database speed.  This is because the big and slow part of the 
database update is done only *after* all the data for a job is written to the 
tape.  If the database is indeed slowing down the tape writing, then it is 
because you have an under configured machine (slow CPU or lack of sufficient 
memory).

 Moving the DB on another x86 / amd machine solve the problem, but I anyway 
can reach a maximum rate of 8-10Mb/sec, that is not the maximum transfer rate 
I may have on those LTO drives (that may run from 15 to 60 to 120 Mb/s 
depending on the version).

Try moving your tape drive to a modern AMD or x86 machine   :-)

 On x86/amd machines, the transfer is higher and acceptable, but yet not 
using the full potential of the scsi library or tape drive, that is anyway 
lower than it may be, always because postgres is slowing down the bacula 
process.
 I am happy to know that we're gonna have a release with transactions, and 
see what happens.

It will enormously speed up the total time it takes to run a job.

 Thanx a lot,
 Gabriele.
 Gabriele Bulfon - Sonicle S.r.l.
 Tel +39 028246016 Int. 30 - Fax +39 028243880
 Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
 http://www.sonicle.com
 
--
 Da: Bill Moran [EMAIL PROTECTED]
 A: Gabriele Bulfon [EMAIL PROTECTED]
 Cc: bacula-users@lists.sourceforge.net
 Data: 13 dicembre 2006 15.09.50 CET
 Oggetto: Re: [Bacula-users] Postgres slow because of autocommit
 In response to Gabriele Bulfon [EMAIL PROTECTED]:
  Hello,
  I stumbled upon some pages that confirm a suspect I had about using
  postgres with bacula:
  - Postgres has autocommit by default, slowing down a lot any Bacula
  operation because Bacula does not use any transaction during write.
  If this is truedo I have any way to set up just the Bacula database
  (not the other ones I have) to have no autocommit?
  Is there any pre-script to set the bacula connection without auto 
commit?
 There is no way (that I'm aware of) to disable autocommit.
 By definition, any database that's not being fed transactions is in
 autocommit mode (PostgreSQL actually calls this unchained mode).
 It makes sense: without an explicit transaction, how would the DB
 server know when to commit the data?  I don't know of any DB that
 does it any differently.
 That being said, the Bacula team has been working hard at adding
 transaction support and other performance improvements -- if you
 search the list archives, you'll see lots of discussions.  I think
 some of the improvements are slated to appear in the next version.
 That being said, PostgreSQL runs just fine even without the transactions.
 Everything I run uses PostgreSQL (I manage 4 directors).  Two of them
 manage large data sets using beefy hardware (of 25 servers, 1 of them
 has 1,500,000 files/12G compressed)  Another one is my laptop, and the
 fourth is a medium-grade machine backing up about 20G of servers and
 desktops.  None of them are experiencing any performance problems.
 --
 Bill Moran
 Collaborative Fusion Inc.
 [EMAIL PROTECTED]
 Phone: 412-422-3463x4023
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Oliver Lehmann]

Kern Sibbald wrote:

 I encourage you to re-submit a patch for the above problem once 1.40.0 is 
 out, 
 possibly coordinating with Attila, since he seems to be working on something 
 a bit more encompasing (attribs + ACLs, ...).

Ok, no problem - I'll do so.

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] restore data saved from windows into a linux

[Kern Sibbald]

On Wednesday 13 December 2006 14:33, Marco Strullato wrote:
 Hello!
 I have to restore data saved from windows into a linux box but I get
 this error:Error: Win32 GZIP data stream not supported on this Client.
 
 How shoud I do?

Try upgrading your FD to the latest 1.39.30 BETA release.  It is reported to 
work with older Dir/SDs, and it will restore to a Linux box.  However, be 
careful to read the full ReaseNotes as the installation is *significantly* 
different 

 
 Thanks
 
 Marco
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-users mailing list
 Bacula-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bacula-users
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] [Bacula-devel] problems with hardlinks to schg secured files on FreeBSD on restore

[Attila Fülöp]

Kern Sibbald wrote:
 On Wednesday 13 December 2006 16:07, Attila Fülöp wrote:
 Folks,

 just to dropping  into this discussion.

 Kern Sibbald wrote:
 On Wednesday 13 December 2006 08:49, Oliver Lehmann wrote:
 a Kern Sibbald writes: 
 patch-src-findlib-attribs.c
   when restoring a symlink, use lchflags to restore the file flags
   defined for the symlink (new feature)
 This is right, but only part of a bigger problem. FreeBSD, as opposed to
 other OSes allows symlinks to have own permissions ACL etc and offers
 appropriate syscalls. Specifically this are lchmod, lutimes, lchflags
 acs_set/get_link_np.

 I have written a patch witch addresses this issue. So this patch will
 interfere with my changes. I would prefer not to have above mentioned
 new feature in the CVS since this will surely give me conflicts on
 next cvs update.

 I'm in the process of writing the regression scripts for my patches.
 Since my patch addresses other stuff (mostly ACL code, and some minor
 fixes) and the writing of regression scripts isn't that well documented
 this may take some time. Nonetheless I hope to have the testing done
 until next Monday.

 I will look into the other new patches this evening to see if they
 interfere with my changes and report back tomorrow.
 
 I would be very happy if you will provide a patch.  However, there is almost 
 zero chance that it will go in before 1.40.0 is released.  The only fixes 
 that I am accepting at the moment are important bug fixes that do not disrupt 
 the code too much.

Yes, I know. We already talked about this.

 I suggest you simply pull down the new file after I have 
 integrated the patch and adjust your code to work with it.  This is, 
 unfortunately, something that developers must do quite often.

Well that is actually what I was trying to avoid, but such is life ;-).

 Concerning all these differences on FreeBSD:  if the changes needed to make 
 things work correctly on FreeBSD are extensive and require a bit of 
 #ifdefing, we are going to have to re-think how we do it.  The code is 
 already a bit messy and adding more non-standard system dependent code will 
 push it over my tolerance of messyness.  As a consequence, we will need to 
 look at ways of making it cleaner --- e.g. moving some of the code, possibly 
 the system dependent code into subroutines ...

No, I don't think they are extensive. Just a couple of lines, mainly
ifdefing chmod/chflags/utime to the 'l' versions.

Sorry I don't have access to the current code right now, since it
is at home. I will send you a 'preliminary patch' tomorrow, so You
can peek at it and decide if it is too messy.

 Attila

   when restoring a hardlink, don't call chmod, chown, utime because it 
 is
   a hardlink and don't  have such attributes (as far as I know, if 
 someone
   with more FS-foo can step up and confirm this?). Changing this
   attributes will change the sourcefiles attributes which is probably 
 not
   what is wanted here anyway
 I'll have to think about this a bit more.  However, I don't think it is 
 correct to skip setting the attributes.  To understand hardlinks, the 
 first 
 thing is to realize that the name is slightly misleading.  A hard link 
 is 
 not 
 really a link.  The data for the two files the attributes are one and 
 the 
 same.  The situation is very different from a softlink where there is a 
 separate directory entry that points to an existing file.   

 Thus to properly restore a hardlink you must also reset the attributes 
 or 
 you 
 could potentially end up with incorrect attributes (owner, modes, ...).
 Ok, but from my understanding setting attributes on a hardlink changes 
 the 
 attributes of the inode the hardlink is pointing to, like for normal 
 files 
 which are technically hardlinks too. 
 There is no such think as a hardlink.  There is a hardlink operation.  It 
 is 
 very different from a softlink, and if you think about them the same way, 
 you 
 will never get it right.  Two files that are hardlinked (really poor 
 terminology) *are* one and the same file.  The two files share the same 
 inode, so there is no hardlink with separate attributes that points to 
 an 
 inode (as is the case for a softlink, which is a pointer).   For 
 hardlinked 
 files, there is only one set of data and one set of attributes.

 So changing attributes for n objects  
 pointing to the same inode is like changing the attributes n times for 
 the 
 same object or is this wrong?
 There are n filenames that share the same data and attributes true, and if 
 you 
 are doing a full restore, it is possible Bacula will set those attributes 
 to 
 the same thing n times since each of Bacula's n representations of the 
 hardlinked files contains the attributes (there is only one copy of the 
 data 
 though).  Ideally, Bacula would set the attributes only once when it 
 restores 
 the data, but I would have to look at the code (which I don't have the 
 time 
 to do) to remember exactly what Bacula does.

 

Re: [Bacula-users] Postgres slow because of autocommit

[Ryan Novosielski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kern Sibbald wrote:

 Moving the DB on another x86 / amd machine solve the problem, but I anyway 
 can reach a maximum rate of 8-10Mb/sec, that is not the maximum transfer rate 
 I may have on those LTO drives (that may run from 15 to 60 to 120 Mb/s 
 depending on the version).
 
 Try moving your tape drive to a modern AMD or x86 machine   :-)

I'm inclined to believe that's not necessary. My director machine is a
Sun UE450 3x296MHz, and the performance I get seems to be acceptable. My
example numbers are 1213K/s (including spooling), or 41 mins for 3GB
with a DAT72 drive. Is this slow? I use MySQL4 on my machine.

- --
-  _  _ _  _ ___  _  _  _
|Y#| |  | |\/| |  \ |\ |  | | Ryan Novosielski - Systems Programmer III
|$| |__| |  | |__/ | \| _| | [EMAIL PROTECTED] - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.| IST/AST - NJMS Medical Science Bldg - C630
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFgDxsmb+gadEcsb4RAnc/AKDlhmNn9iT4ZSqZQwidiafEZ1MEXgCgr9Yi
wP2+niaQIUqHnueVE5AHCSg=
=+Fcw
-END PGP SIGNATURE-
begin:vcard
fn:Ryan Novosielski
n:Novosielski;Ryan
org:UMDNJ;IST/Academic Systems and Technologies
adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103-2757
email;internet:[EMAIL PROTECTED]
title:185 South Orange Avenue
tel;work:(973) 972-0922
tel;fax:(973) 972-7412
tel;home:(973) 792-0497
x-mozilla-html:FALSE
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Building bacula on OpenBSD

[Kern Sibbald]

Hello,

Since this is directed to me, and assuming I wrote the double 'ed sections 
below (which sound a lot like me but so much is snipped that I cannot be 
sure), I can assure you that, my intention, if I am the guity party was not 
to insult any person or any particular OS, but just to point out that it 
appears to me to be an OS compatibility problem (actually a system header 
file to be more correct).

See notes below, where I assume that I wrote the offending statements:

On Wednesday 13 December 2006 18:28, Brian A. Seklecki wrote:
   Stop in /usr/local/src/bacula-1.38.11/src/stored.
  
  It looks to me like the OS' header file is badly broken -- at least in the 
  sense that if it is a Unix system, both mt_fileno and mt_blkno should be 
  defined in the struct mtget.
  
  Someone should fix the OS, barring that we will need a patch.
 
 Kern, Rus, et al:
 
 We have to be really careful with regard how we word things here.  The
 way you assert that could be easily misinterpreted or misconstrued to
 have a vendor-bashing tone.

I'm sorry, I did not intend to be vendor bashing.  I stand by what is written. 
If it is a Unix system and there are not mt_fileno and mt_blkno in the struct 
mtget, there are serious compatibility problems, since I don't have an 
OpenBSD system, assuming the OS is not going to change, we would need a patch 
to Bacula to fix it.

 
 Moreover, conceding the unavailability of compatibility with the OpenBSD
 platform doesn't gain us any additional users; a very large group of
 talented individuals with tremendous experience writing highly secure,
 reliable, and _portable_ code who could contribute greatly to the
 project.
 
 -- To set the record straight, and encourage mutual cooperation -- 
 
 The reality here is that OpenBSD is very selective about where it
 focuses its development efforts, and the st(4) driver is not one of
 those places.
 
 Therefore, the assertion that The OS is broken is not correct, it
 simply hasn't been implemented or maintained as it should.

Yes, broken was a poor choice of words.  I would rephrase it to say it is not 
Unix compatible.

 
 Before I go on and make my own silly assertions, I should note: '
 
Things are always subject to change, and this is F/OSS and you're
always welcome to do the work yourself or have corporate sponsorship.
 
 OpenBSD is not the platform for a Bacula director.  You wont see it (at
 present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek
 Powderhorn Tape Silo connected via Brocade FC switches.(1)
 
 However you will see it at the perimeter and on the wire keeping the
 packet kiddies from stealing all of your customers data.  It could be
 the ideal system for the job with features like enhanced crypto
 acceleration via crypto(9) and the existing improvements on scsi(4) and
 recent HBA support.
 
 Anyway, not a director, not now at least, and probably not a SD Storage
 Daemon either.

Yes, since the problem above arises when compiling the SD.

 
 But most definitely a management console and file daemon.

I think these already exist.  Bacula does have some code to support OpenBSD.

 
 Russel: You'll probably notice that Bacula builds perfectly fine up
 until it gets to the director, then you get into OS-specific kernel
 knits and hooks where either OpenBSD lacks the framework/API (pthreads,
 st(4), etc.) or kernel-specific code needs to be added to Bacula.

Without a decent implementation of pthreads, even the client (file daemon) 
will not build.

 
 In the mean time, we should endeavor to create a bacula-clientonly
 Port in OpenBSD ports, or bacula port with a clientonly flavor.
 
 This has been done before, but the work was never commited (CC:)
 
 1. http://www.arsc.edu/resources/silo.html
 
 I will take the lead on this if I have to.
 
 ~BAS
 
  
  I checked the man page for st, where all other Unix systems define the 
packet.  
  They include no definition, so you will need to consult the header file 
  directly sys/mtio.h.   Sorry, but you are pretty much on your own on this.
  
  
  
   
   
 == Error in /usr/local/src/bacula-1.38.11/src/stored ==
   
   
   ==Entering directory /usr/local/src/bacula-1.38.11/src/tools
    Make of tools is good 
   
 
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-users mailing list
 Bacula-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bacula-users
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions 

Re: [Bacula-users] restore with two autochanger using same MediaType

[Arno Lehmann]

Hello,

On 12/12/2006 11:47 PM, Thomas Glatthor wrote:
 Hi Arno,
 
 
Ok, I understand that setup. I even see a solution for it:
Set up your storage devices with different media types.
When transfering tapes, change the media types of the tapes according to 
the location they're going to.

 
 
 if been thinking about that before asking the list,
 but that is a workaround and not a solution.

I don't share your definition of a workaround and a solution, I think... 
In your situation, I'd implement a script to determine the tapes to 
remove, to unload them, to mark them as inaccessible, and to change the 
MediaType. (In fact, most of such a script already exists here :-)

Implemented as part of a backup infrastructure, this would be part of 
the overall solution. In my terminology, at least.

 a real enterprise backup system must be able to handle such a simple setup 
 :)

Well, then Bacula is not an eberprise backup system for your enterprise. 
But you could make it one.

 an easy lookup to the media-table will solve the problem to choose the right 
 changer automatically.

Hmm. I'm not running 1.38 here any more, but I'm quite sure that a 
feature request would be accepted. It's not long before we can expect 
the next voting call from Kern...

Arno

 Regards
 
 Thomas
 
 
 btw:
 why are blocking high priority jobs
 on one location/changer lower priority
 jobs on a different location/changer?
 i think that the priority have to take care of clients and storages,
 so the jobs with different priority on different storages can run at once 
 (order by priority and storage).
 (a client with priority 10 and storage Jukebox1 does not have to prevent a 
 priority 11 job on jukebox2 from being started)
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-users mailing list
 Bacula-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bacula-users

-- 
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] 1.38.11 - possible bug in Rerun Failed Levels.

[Arno Lehmann]

Hi,

On 12/13/2006 1:07 PM, Alan Brown wrote:
 Can anyone else confirm this?
 
 
 
 Rerun Failed Levels = yes
 
 If an incremental job is scheduled to start before a full or differential 
 job has completed (ie, still running): When the incremental job starts the 
 previous (still running) job is detected as failed and the incremental 
 is upgraded to full or differential.
 
 
 
 It seems repeatable here but I'd like confirmation from someone else 
 before filing it as a genuine bug.

I think that's the behaviour, right.

One of the reasons why I prefer to have 'maximum concurrent jobs=1' in 
my job definitions. (And a max wait time, too, so even under dificult 
conditions the job is not started too in a row.)

I'm also not sure how to prevent this. The key question is which job the 
  incremental one should be based upon. If you take the last job before 
the currently running one, that looks like a safe choice, and could 
probably implemented by slightly modifying the SQL query for the latest job.

Basing the incremental job onto the running one might be more correct 
when thinking about the file selection (i.e., select all files modified 
since the running job started), but you can't be sure that the job 
currently running completes without error.

Arno

 AB
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-users mailing list
 Bacula-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bacula-users

-- 
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] restore with two autochanger using same MediaType

[Kern Sibbald]

On Wednesday 13 December 2006 22:48, Arno Lehmann wrote:
 Hello,
 
 On 12/12/2006 11:47 PM, Thomas Glatthor wrote:
  Hi Arno,
  
  
 Ok, I understand that setup. I even see a solution for it:
 Set up your storage devices with different media types.
 When transfering tapes, change the media types of the tapes according to 
 the location they're going to.
 
  
  
  if been thinking about that before asking the list,
  but that is a workaround and not a solution.
 
 I don't share your definition of a workaround and a solution, I think... 
 In your situation, I'd implement a script to determine the tapes to 
 remove, to unload them, to mark them as inaccessible, and to change the 
 MediaType. (In fact, most of such a script already exists here :-)
 
 Implemented as part of a backup infrastructure, this would be part of 
 the overall solution. In my terminology, at least.
 
  a real enterprise backup system must be able to handle such a simple 
setup :)
 
 Well, then Bacula is not an eberprise backup system for your enterprise. 
 But you could make it one.
 
  an easy lookup to the media-table will solve the problem to choose the 
right changer automatically.
 
 Hmm. I'm not running 1.38 here any more, but I'm quite sure that a 
 feature request would be accepted. It's not long before we can expect 
 the next voting call from Kern...

Yes, if things go half way decently, after updating the projects list I'll 
send it out this weekend and take votes until just after the first of the 
year.  I haven't decided how to do the voting.  Last year, it took me too 
much time to count them, so either I have to simplify it or find someone else 
to do it.

 
 Arno
 
  Regards
  
  Thomas
  
  
  btw:
  why are blocking high priority jobs
  on one location/changer lower priority
  jobs on a different location/changer?
  i think that the priority have to take care of clients and storages,
  so the jobs with different priority on different storages can run at once 
(order by priority and storage).
  (a client with priority 10 and storage Jukebox1 does not have to prevent a 
priority 11 job on jukebox2 from being started)
  
  -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
  opinions on IT  business topics through brief surveys - and earn cash
  http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Bacula-users mailing list
  Bacula-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bacula-users
 
 -- 
 IT-Service Lehmann[EMAIL PROTECTED]
 Arno Lehmann  http://www.its-lehmann.de
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-users mailing list
 Bacula-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bacula-users
 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Always upgrade Incremental to Full. Why

[Arno Lehmann]

Hi,

On 12/13/2006 4:54 PM, Kamen Medarski wrote:
 I have a strange situation here. I can't find any reason why bacula 
 always try to upgrade scheduled or even manualy runed incremental job. 
 Full job appear to be done without errors for any client, but next 
 incremental job was upgraded to full without any clue. I've made triple 
 check  to configuration, but there is nothing strange. I've attach my 
 dir config, please can someone help me with this issue.

You've got your jobs set up incorrect.

It is not the right thing to set upone job for full and one for 
incremental backup. Instead, set up one job only, and decide which level 
(full, incremental, or differential) to run when you start the job 
(using the console or a schedule).

After that is done, and there remain errors, post these - I didn't look 
at the configuration very closely.

Arno

-- 
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Backups Successful - Restores Fail

[Arno Lehmann]

Hi,

On 12/13/2006 4:57 PM, jpg wrote:
 Need some guidance on how to restore a single file.
 
 Successfully configured and did a full backup of filesystem
 spanning 4 tapes in autochanger.
 
 Renamed a test file from 'ob' to 'ob.orig'. Then requested a
 restore of the file 'ob'.
 
 Restore said it completed successfully, however the 'ob' file
 was NOT restored.
...
 Bootstrap records written to /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr
 
 The job will require the following Volumes:

TapeDiff0003
 
 
 1 file selected to be restored.
 
 Run Restore job
 JobName:RestoreFiles
 Bootstrap:  /var/lib/bacula/hpcvsjpg-dir.1.restore.bsr
 Where:  /tmp/bacula-restores

The file you look for will most probably reside in 
/tmp/bacula-restores/home/jpg/ob9

Arno

-- 
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] multitape-changer issue

[Arno Lehmann]

Hello,

On 12/13/2006 10:34 AM, Alessio Mineni wrote:
 Thanks Arno, you are a Saint :)

It's christmas time :-)

 Alle 20:50, martedì 12 dicembre 2006, Arno Lehmann ha scritto:
 
Hello,

On 12/12/2006 11:59 AM, Alessio Mineni wrote:

Hi all,

 I have 3 DAT drives and I want to group this drives into one autochenger
virtual device via multitape-changer script.

There was some discussion about multitape-changer recently. Use some of
the list archives to see if there is relevant information for you...

[...]

I don't think this is how multitape-changer works. I never actually used
it, but I think it simulates a one-drive autochanger with a number of
slots equal to the number of drives you have.
 
 
 Me silly! You are right! I correct it leaving only one tape device named 
 changer0. I've found the thread you are talking about but, it use a 
 configuration like old mine (with one autochanger and three tape device 
 configured in sd.conf).
 
 This is the new:
 
 bacula-sd.conf
 
 AutoChanger {
   Name = multitape0
   Device = vtape0
   Changer Command = /usr/libexec/bacula/multitape-changer %c %o %S %a %d
   Changer Device = /dev/sg0
 }
 
 Device {
   Name = vtape0
   Drive Index = 0
   Media Type = 4mm
   Archive Device = /dev/changer0
   AutomaticMount = yes
   AlwaysOpen = no
   RemovableMedia = yes
   RandomAccess = no
   AutoChanger = yes
   LabelMedia = no
 }
 
 and bacula-dir.conf
 
 Storage {
   Name = changer0
   Address = 192.168.0.20
   SDPort = 9103
   Password = P00io9
   Device = multitape0
   AutoChanger = yes
   Media Type = 4mm
   Maximum Concurrent Jobs = 1
 }
 
 
[...]
 
 
[...]

1 - no automatic startup link has done by bacula, I have to link
/dev/nstx to /dev/changer0 manually

Sure, Bacula doesn't create device nodes for you.


2 - no automatic change has done by bacula

So the autochanger setup didn't work. What does btapes test command tell
you?
 
 
 Why not? Using multitape-changer in command line it create the right 
 simlink /dev/changer0 -- /dev/nst1|2|3.

Well, that's something the multitape-changer script does, not the Bacula 
core itself.

 If I tell bacula to update slots it will virtually change the tapes in the 
 library changing the simlink, and read, one by one, the tapes header.

I understand, though, that this command does work.

 
So the multitape-changer setup is not correct. See that thread I
mentioned for more information.

Or hope to find someone who actually uses that... (or pay me :-)
seriously, I didn't get the impression that the suggested multichanger
script is easy to use).

Arno
 
 
 Take a look at this output:
 
 chronos dev # bconsole
 Connecting to Director chronos:9101
 1000 OK: chronos-dir Version: 1.38.5 (18 January 2006)
 Enter a period to cancel a command.
 *update slots
 Using default Catalog name=MyCatalog DB=bacula
 The defined Storage resources are:
 [...]
  3: changer0
 [...]
 Select Storage resource (1-10): 3
 Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
 Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
 3306 Issuing autochanger slots command.
 Device multitape0 has 3 slots.
 Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
 3301 Issuing autochanger loaded drive 0 command.
 3302 Autochanger loaded drive 0, result: nothing loaded.
 3306 Issuing autochanger list command.
 Volume 1 not found in catalog. Slot=1 InChanger set to zero.
 Volume 2 not found in catalog. Slot=2 InChanger set to zero.
 Volume 3 not found in catalog. Slot=3 InChanger set to zero.

This seems to indicate the volumes you have in your drives (i.e. virtual 
slots) are labeled by Bacula, but there are no catalog entries. As a 
result, Bacula will refuse using them. This is intentional, by the way :-)

 *label

Using the 'label' command will not help you much, here... to add the 
existing volumes to the catalog, use the 'add' command. Or, to try 
labeling from bacula, erase the existing tape labels, which is easily 
done with 'mtx -f ... weof'. Not that this will render any existing data 
on the tapes useless.

 The defined Storage resources are:
 [...]
  3: changer0
 [...]
 Select Storage resource (1-10): 3
 Enter new Volume name: extra01-0001
 Enter slot (0 or Enter for none): 0

Hmm, it's a long time that I tried labeling with slot=0, but IIRC that 
will label the tape currently loaded in the drive.

In your situation, that means that the link to the tape drive to 
actually use has to be set up already.

You might try to use a command like 'label volume=extra01-0001 
storage=changer0 pool=extra01 slot=1' or similar and see if that works.

At least it might trigger the needed call of multitape-changer to set up 
the link to the drive.

 Defined Pools:
 [...]
 13: extra01
 [...]
 Select the Pool (1-13): 13
 Connecting to Storage daemon changer0 at 192.168.0.20:9103 ...
 Sending label command for Volume extra01-0001 Slot 0 ...
 3301 Issuing autochanger loaded drive 0 command.
 3302 Autochanger loaded drive 0, result: 

Re: [Bacula-users] about the 1.40 version release

[Robert Nelson]

Yes TLS communication is supported by the Windows version.  Openssl is
installed as part of the Bacula installation.  Configuration is similar to
the UNIX environment and requires some hand editing of the configuration
files.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jaime
Ventura
Sent: Wednesday, December 13, 2006 7:22 AM
To: bacula-users@lists.sourceforge.net
Subject: [Bacula-users] about the 1.40 version release

Hello,
   I've read a few messages ago that the new stable version of 
bacula would be released 'till the end of 2006. Does this sting stand?
   On The Current State of Bacula -- 1.39.29 (01 December 2006) 
its says Configurable TLS (SSL) communications encryption 
http://www.bacula.org/dev-manual/Bacula_TLS_Communication.html#CommEncrypti
on 
between each component
   Does the w32 client supports such feature or just the *nix?
   Thanks.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] about the 1.40 version release

[Jaime Ventura]

Thank you, Robert, for you reply.
Those are very good news, since the current stable version didnt.

Robert Nelson wrote:
 Yes TLS communication is supported by the Windows version.  Openssl is
 installed as part of the Bacula installation.  Configuration is similar to
 the UNIX environment and requires some hand editing of the configuration
 files.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Jaime
 Ventura
 Sent: Wednesday, December 13, 2006 7:22 AM
 To: bacula-users@lists.sourceforge.net
 Subject: [Bacula-users] about the 1.40 version release

 Hello,
I've read a few messages ago that the new stable version of 
 bacula would be released 'till the end of 2006. Does this sting stand?
On The Current State of Bacula -- 1.39.29 (01 December 2006) 
 its says Configurable TLS (SSL) communications encryption 
 http://www.bacula.org/dev-manual/Bacula_TLS_Communication.html#CommEncrypti
 on 
 between each component
Does the w32 client supports such feature or just the *nix?
Thanks.

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-users mailing list
 Bacula-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bacula-users




   


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Postgres slow because of autocommit

[Gabriele Bulfon]

I have an LTO3 library installed behind a modern AMD machine, a Sun v20z 
biprocessor.
Again with Solaris 10 and postgres 8.
The avarage rate is 8Mb/s, and I have just some peak transfer rate of 14Mb/s 
(and this is
way
tooslow for an LTO3), and this happens ONLY when Bacula is backing-up 
somebig-big file (meaning that probably Bacula is working less with the 
dbbecause the majority of work is about writing the data on the device,rather 
than writing one db record).
On the same machine, I can measure very higher rates if I just roughly write 
some data with tar.
About your cute answer, let me say that the Sun280R that is runningBacula and 
Postgres on a Storedge LTO1, is the same machine that waspreviously running 
Legato software for backup.
With Legato I could measure a throughput of 10-12Mb/s.
If I have both Bacula and postgres on this machine, I can have up to a 1Mb/s.
If I move both Director and Postgres in the LAN on to a newer x86machine (still 
with solaris 10), and leave just the SD on the 280R, Ireach a maximum of 7Mb/s.
I have Bacula installed in many different ways, and everything makes me think 
that Postgres is the problem.
Maybe I should put into some kind of trace the postgres db duringbackup, so to 
have some useful statistics about the activities...
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
--
Da: Kern Sibbald [EMAIL PROTECTED]
A: bacula-users@lists.sourceforge.net
Cc: Ryan Novosielski [EMAIL PROTECTED] Gabriele Bulfon [EMAIL PROTECTED] 
Bill Moran [EMAIL PROTECTED]
Data: 13 dicembre 2006 19.31.20 CET
Oggetto: Re: [Bacula-users] Postgres slow because of autocommit
On Wednesday 13 December 2006 18:46, Ryan Novosielski wrote:
 Kern Sibbald wrote:

  Moving the DB on another x86 / amd machine solve the problem, but I
anyway
  can reach a maximum rate of 8-10Mb/sec, that is not the maximum transfer
rate
  I may have on those LTO drives (that may run from 15 to 60 to 120 Mb/s
  depending on the version).
 
  Try moving your tape drive to a modern AMD or x86 machine   :-)

 I'm inclined to believe that's not necessary.
I was being a bit cute ...
 My director machine is a
 Sun UE450 3x296MHz, and the performance I get seems to be acceptable. My
 example numbers are 1213K/s (including spooling), or 41 mins for 3GB
 with a DAT72 drive. Is this slow?
Not for a DAT, but it is horrible for any LTO particularly if it is an LTO-3.
 I use MySQL4 on my machine.

 --
  _  _ _  _ ___  _  _  _
 |Y#| |  | |\/| |  \ |\ |  | | Ryan Novosielski - Systems Programmer III
 |$| |__| |  | |__/ | \| _| | [EMAIL PROTECTED] - 973/972.0922 (2-0922)
 \__/ Univ. of Med. and Dent.| IST/AST - NJMS Medical Science Bldg - C630

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Postgres slow because of autocommit

[Gabriele Bulfon]

I forgot about the link I found about this:
http://www.mail-archive.com/pgsql-performance@postgresql.org/msg19584.html
what do you think?
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
--
Da: Kern Sibbald [EMAIL PROTECTED]
A: bacula-users@lists.sourceforge.net
Cc: Ryan Novosielski [EMAIL PROTECTED] Gabriele Bulfon [EMAIL PROTECTED] 
Bill Moran [EMAIL PROTECTED]
Data: 13 dicembre 2006 19.31.20 CET
Oggetto: Re: [Bacula-users] Postgres slow because of autocommit
On Wednesday 13 December 2006 18:46, Ryan Novosielski wrote:
 Kern Sibbald wrote:

  Moving the DB on another x86 / amd machine solve the problem, but I
anyway
  can reach a maximum rate of 8-10Mb/sec, that is not the maximum transfer
rate
  I may have on those LTO drives (that may run from 15 to 60 to 120 Mb/s
  depending on the version).
 
  Try moving your tape drive to a modern AMD or x86 machine   :-)

 I'm inclined to believe that's not necessary.
I was being a bit cute ...
 My director machine is a
 Sun UE450 3x296MHz, and the performance I get seems to be acceptable. My
 example numbers are 1213K/s (including spooling), or 41 mins for 3GB
 with a DAT72 drive. Is this slow?
Not for a DAT, but it is horrible for any LTO particularly if it is an LTO-3.
 I use MySQL4 on my machine.

 --
  _  _ _  _ ___  _  _  _
 |Y#| |  | |\/| |  \ |\ |  | | Ryan Novosielski - Systems Programmer III
 |$| |__| |  | |__/ | \| _| | [EMAIL PROTECTED] - 973/972.0922 (2-0922)
 \__/ Univ. of Med. and Dent.| IST/AST - NJMS Medical Science Bldg - C630

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] No rule to make target -- libsql.a

[Quanzhong Zhang]

Hi,

There are some error message appear when I install Bacula. Would you
kindly help me?

Execute the command:
  ./configure \
--sbindir=$HOME/bacula/bin \
--sysconfdir=$HOME/bacula/bin \
--with-pid-dir=$HOME/bacula/bin \
--with-subsys-dir=/var/bacula/subsys \
--with-sqlite=$HOME/depkgs/sqlite-2.8.17kes \
--enable-gnome \
--with-mysql=/usr \
--with-working-dir=$HOME/bacula/bin/working \
[EMAIL PROTECTED] \
[EMAIL PROTECTED] \
--with-smtp-host=10.8.1.10

For ./configure command it seems no problem.
But when I execute the command make, the error messages as following,

... ...
make[1]: *** [mysql.o] Error 1
make[1]: Leaving directory '/home/bacula/bacula-1.38.11/src/cats'

 == Error in /home/bacula/bacula-1.38.11/src/cats ==

... ...

... ...
make[1]: *** No rule to make target '../cats/libsql.a', needed by
'bacula-dir'. Stop.
make[1]: Leaving directory '/home/bacula/bacula-1.38.11/src/dird'

 == Error in /home/bacula/bacula-1.38.11/src/dird ==

... ...


... ...
make[1]: *** No rule to make target '../cats/libsql.a', needed by
'bscan'. Stop.
make[1]: Leaving directory '/home/bacula/bacula-1.38.11/src/stored'

 == Error in /home/bacula/bacula-1.38.11/src/stored ==

... ...

... ...
make[1]: *** No rule to make target '../cats/libsql.a', needed by
'dbcheck'. Stop.
make[1]: Leaving directory '/home/bacula/bacula-1.38.11/src/tools'

 == Error in /home/bacula/bacula-1.38.11/src/tools ==

My operating system is Redhat Enterprise Linux 4
The version of Bacula is 1.38.11
The attached file is config.out


Thanks and Best Regards,
Zhang QZ




config.out
Description: config.out
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users