[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] [Bacula-users] [Fwd: Re: bacula : about the bacula.spec form rpms]


On Monday 03 March 2008 20.29:09 Martin Simmons wrote:
> >>>>> On Mon, 3 Mar 2008 11:48:37 +0100, Kern Sibbald said:
> >
> > Hello Scott,
> >
> > I've copied the bacula-users list because some people may not be aware of
> > the problems they are getting themselves into using *standard* packages
> > to install Bacula.
> >
> > I *strongly* recommend that we completely reconsider the package
> > directories that we use.  The current way of installing Bacula by
> > packages is *very* far from optimal.  Let me explain ...
> >
> > There are standards such as FHS, and these are good and useful for most
> > programs, but they really do a big disservice to Bacula users when we are
> > dealing with recovery.  If you spread the Bacula installation all around
> > your computer filesystem as most packages do and as the standards
> > specify, and your system is a server and the server goes down (loses the
> > harddisk), you will find it next to impossible to restore that server --
> > very few people think about this.  What I am saying here applies to a
> > Bacula server (Director, SD) and not clients.
> >
> > A much better scheme for installing Bacula on a server is outlined and
> > recommended in the manual, and that is to install *everything* (except
> > perhaps the man pages) either in a single directory or under a single
> > unique directory.  This allows the smart sys admins to backup a single
> > directory along with their nightly catalog backup, and thus have in hand
> > a single bsr file that will recover not only their catalog, but all their
> > configuration files (critical for the Director, and important for the SD)
> > as well as all the Bacula binaries, which in the future will include
> > plugins required for restore.
>
> Something I don't understand about this approach -- how do you restore this
> single directory before you have restored a working Bacula installation
> that can read the bsr?

You need to get at least some minimal Bacula running, with say the default 
installation and a few minor tweaks to be able to access your tape drive or 
disk.  Then you feed it the bsr file (mine is emailed to me as well as stored 
on another machine), and it gets your whole config, including the binaries, 
plugins, ...  The binaries are not the most important, but the plugins are 
critical as are your conf files (dir and sd) and the database.

>
> If you do it using a recovery disk, then you'll need to put all the
> critical files on that disk anyway.  You can also include the Bacula rpms
> on the recovery disk, to allow them to be reinstalled on the server or on a
> new server.  The plugins should also be installed from rpms.
>
> If you do it by reinstalling the OS from normal distro media, then you can
> also reinstall Bacula from rpms on a CD.

As mentioned above, the binaries are not necessarily the most critical part 
unless perhaps you have applied a number of critical patches.  The most 
important parts are your Director's conf file, your catalog, and shortly any 
special plugins, but as time goes by, there are more and more little pieces 
that are important.  By saving everything in one wack, you are sure you did 
not miss anything.

Best regards,

Kern

>
> __Martin
>
> > Now there could be several choices according to your preferences of how
> > to install Bacula in a single directory (or under a single directory). 
> > On some systems, this may be /var/bacula, on others it might be
> > /opt/var/bacula, and after that, you might choose to install *everything*
> > in /var/bacula, or you might prefer to
> > have /var/bacula/bin,  /var/bacula/scripts,  /var/bacula/plugins, ...
> >
> > My point is not to try to dictate the exact structure, but to guarantee
> > that if you backup a single directory, you will get *everything* of
> > importance that Bacula needs to be restored.  Obviously you can also
> > have /var/bacula/tmp and /var/bacula/working, which you might want or not
> > want to exclude from the backup.  However, the worst case would be to
> > backup Bacula from a list of files or by specifying each file in the
> > FileSet include, because if you do an upgrade and we add a new critical
> > file or someone adds a plugin, then you will find yourself with a *much*
> > bigger job to get a server backup and running.
> >
> > Obviously there are other techniques for dealing with this problem (hot
> > spare), but IMO, for all Bacula installations, the Bacula files should be
> > placed in Bacula's own single directory or single directory tree as I
> > have described above.
> >
> > This is something that I would like to see us switch to doing with our
> > rpm releases, and we would allow users to specify the base structure (a
> > single directory or a single tree), but if they want to start moving
> > files all over the place, that IMO should be left to the user to maintain
> > his own spec files possibly based on ours.
> >
> > Best regards,
> >
> > Kern
> >
> > On Sunday 02 March 2008 20.06:43 Scott Barninger wrote:
> > > FYI this offline conversation...
> > >
> > > -------- Forwarded Message --------
> > > From: Scott Barninger <scott@xxxxxxxxxxxxx>
> > > To: Bruno Friedmann <bruno@xxxxxxxxxxx>
> > > Cc: Kern Sibbald <kern@xxxxxxxxxxx>
> > > Subject: Re: bacula : about the bacula.spec form rpms
> > > Date: Sat, 01 Mar 2008 06:55:49 -0500
> > >
> > > Hello Bruno,
> > >
> > > I will look at implementing this.
> > >
> > > On Sat, 2008-03-01 at 11:55 +0100, Bruno Friedmann wrote:
> > > > Hi Scott,
> > > >
> > > > With an increasing number of customers using bacula, I'm really
> > > > interesting into one or two piece of change in the bacula spec.
> > > >
> > > > The only real annoying thing is that script_dir is hardcoded to the
> > > > /etc/bacula which is the old "wrong" debian way to put script.
> > > >
> > > > Normally I think  it's place should be under /usr/lib(64)/bacula ?
> > >
> > > Yes, there was some discussion of this back when we changed directory
> > > locations for FHS compatibility. /etc/bacula  isn't really "correct"
> > > just traditional for bacula.
> > >
> > > > I've made some try yesterday, modifing the bacula.spec. And it would
> > > > be quiet easy to had a build_script define that can change with the
> > > > configure.
> > >
> > > Yes it would be relatively easy for me to add a build time switch to
> > > alter that location. Having a "build_fhs" define could cause it to be
> > > set to %_libdir/bacula.
> > >
> > > > I understand that would break old install. I'm looking a way to
> > > > prepare futur and new installation.
> > > >
> > > > Perharps I should prepare my own packapes branch to avoid conflict,
> > > > did you have a trick to add for example a -ioda(0-9) extra release
> > > > tag (I'm a bit new to rpmbuild :-) )
> > >
> > > I recommend not messing with the release tag. It was only ever meant to
> > > be a number. rpm would interpret -b1 as "newer" than -a5.
> > >
> > > > I've the habit to use also this option during configure :
> > > >
> > > >
> > > > ./configure  		\
> > > >   --prefix=/					\
> > > >   --exec-prefix=/usr				\
> > > >   --sbindir=/usr/sbin 				\
> > > >   --sysconfdir=/etc/bacula			\
> > > >   --libexecdir=/usr/lib64/bacula		\
> > > >   --datadir=/usr/share/bacula			\
> > > >   --with-working-dir=/var/lib/bacula		\
> > > >   --with-scriptdir=/usr/lib64/bacula		\
> > > >   --with-pid-dir=/var/run/bacula		\
> > > >   --with-subsys-dir=/var/run/bacula		\
> > > >   --enable-ipv6			\
> > > >   --enable-largefile		\
> > > >   --enable-smartalloc		\
> > > >   --with-gnu-ld         	\
> > > >   --enable-conio		\
> > > >   --with-libiconv-prefix	\
> > > >   --with-libintl-prefix		\
> > > >   --with-gettext		\
> > > >   --with-tcp-wrappers		\
> > > >   --with-dir-user=bacula	\
> > > >   --with-dir-group=bacula	\
> > > >   --with-sd-user=bacula		\
> > > >   --with-sd-group=bacula	\
> > > >   --with-fd-user=root		\
> > > >   --with-fd-group=bacula	\
> > > >   --with-sbin-perm=0754		\
> > > >   --with-dump-email=admin_topd@xxxxxxx	\
> > > >   --with-job-email=admin_topd@xxxxxxx	\
> > >
> > > This should be easy too.
> > >
> > > >   --with-smtp-host=exchange.ultim.ch		\
> > > >   --with-x		\
> > > >   --with-python		\
> > > >   --with-openssl	\
> > > >   --with-mysql 		\
> > > >   --enable-build-dird	\
> > > >   --enable-build-stored	\
> > > >   --disable-batch-insert \
> > > >
> > > > and I usually place some gcc optimisation corresponding to the arch
> > > > of the cpu something like that
> > >
> > > This is possible too. But if you use it you must be complete because it
> > > will cause rpmbuild not to read the default macros.
> > >
> > > > # GCC optimize for Intel () ...
> > > > # export CFLAGS="-O3 -msse -mmmx -march=x86-64 -mtune=nocona
> > > > -funroll-loops -mfpmath=sse -g -pipe -ffast-math" # export
> > > > CFLAGS="-O3 -msse -mmmx -march=pentium4 -mtune=pentium4
> > > > -funroll-loops -mfpmath=sse -g -pipe -ffast-math" # export
> > > > BOOT_CFLAGS="-O3 -march=pentium4 -mfpmath=sse -pipe"
> > > > # export CXXFLAGS="-Os -march=pentium4 -mfpmath=sse -pipe
> > > > -mpreferred-stack-boundary=4"
> > > >
> > > >
> > > > # GCC optimize for AMD64 ()
> > > > export CFLAGS="-O3 -msse -mmmx -march=x86-64 -mtune=k8 -funroll-loops
> > > > -mfpmath=sse -g -pipe -ffast-math" export BOOT_CFLAGS="-O3
> > > > -march=x86-64 -mfpmath=sse -pipe"
> > > > export CXX_FLAGS="-Os -march=x86-64 -mfpmath=sse -pipe
> > > > -mpreferred-stack-boundary=4"
> > > >
> > > > # Clean any previous configure or make
> > > > make distclean
> > > >
> > > > make clean
> > > > # We use the / configuration ...
> > > > #./configure pentium4-suse-linux \
> > > >
> > > >
> > > >
> > > > All of my install work under suse 10.1 / 10.2 / 10.3 and I've got no
> > > > trouble with them. If you have any remarks or comment, I will be glad
> > > > to heard them ...
> > > >
> > > >
> > > > I've in my idea box also the use of openbuild.suse.com (this could
> > > > easily extend the portability of the project)
> > > >
> > > > Have an excellent week-end.
> > > > Regards.
> > >
> > > -----------------------------------------------------------------------
> > >-- This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > Bacula-devel mailing list
> > > Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.sourceforge.net/lists/listinfo/bacula-devel
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Bacula-users mailing list
> > Bacula-users@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/bacula-users
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.