Hi Kern, In a sense I agree with your definition for rescue bacula. But in real life, I would imagine this a bit differently.
In a production environement : bacula server is it's own server. ( Dir and SD could be together ). I really preconise to have a tar of this system made before/after every big changes. A tar or whatever copies of /etc/bacula (for config files) is a must to have at another place. (Two backup with different backup system is better just in case of. Futher when this cost nothing more cpu time and a bit of disk place). Now in case of a disaster, we need to define what disaster. If all burns there's no more computers. If backups are on disk they no more exist, and you have to take some times to transfert the offsite media. What would be the most probable in this case. You could not find the same hardware, the old linux serving bacula wasn't able to manage new video, harddisk, cpu, motherboard and so. You have to start a new fresh install. Get the /etc/bacula conf and after just some revision you could restart it with new rpm. More and more people I've encounter (which a big numbers are fresh to *nix) are looking for program where FHS says they should be found. I totally agree with your vision and concept : but I don't kown any way of having a static-fd, static-dir, static-sd with openssl where crypted transmission and/or encrypted media are use. So I can't imagine myself a way of bare simple rescue. All other concurent software maker still failed with this as I know. Does anyone have a successfull bare restore with Arghserve disaster rescue option ??? I think another point would be important for FHS rpm distribution way. What will append if distributions want that distributed rpm should or have to follow certain rules ? I respect all of your choice, afterall they conduct all of us where we are (able to have really good backups, restore and so). For my own need I could always "patch" the spec to deploy as I want. That's the beautifull of our freedom of choice. PS : I've just try this week the bat ( so nice !!! ) Regards Kern Sibbald wrote: > 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. > > 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 <[EMAIL PROTECTED]> >> To: Bruno Friedmann <[EMAIL PROTECTED]> >> Cc: Kern Sibbald <[EMAIL PROTECTED]> >> 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 \ >>> [EMAIL PROTECTED] \ >>> [EMAIL PROTECTED] \ >> 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 >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/bacula-devel > > -- Bruno Friedmann [EMAIL PROTECTED] Ioda-Net Sàrl - www.ioda-net.ch 2830 Vellerat - Switzerland Tél : ++41 32 435 7171 Fax : ++41 32 435 7172 gsm : ++41 78 802 6760 C'est Facile et Cool d'Évoluer en ligne : www.cfcel.com ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
