[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] [Fwd: Re: bacula : about the bacula.spec formrpms]
> There are standards such as FHS, and these are good and useful for
> programs, but they really do a big disservice to Bacula users when we
> dealing with recovery. If you spread the Bacula installation all
> computer filesystem as most packages do and as the standards specify,
> your system is a server and the server goes down (loses the harddisk),
> will find it next to impossible to restore that server -- very few
> think about this. What I am saying here applies to a Bacula server
> (Director, SD) and not clients.
Adherence to the filesystem standards is important in that many
enterprises require their use where such standards exist, and the key
point here is to preserve the various configuration files and
information, not the location of the binaries. I don't really care where
the binaries are as long as the configuration and database is completely
captured; in fact, if I'm restoring at a DR site, I may not have the
same release or version that I have at home, but if I have the
configuration, I have the necessary -- perhaps not optimal, but
*necessary* -- pieces to put my environment back together.
If Bacula is going to play in the big leagues, there isn't any excuse
for dodging the standards, period. It may not be perfect, but it's the
Way Things Are Done, and deviants are excluded from playing; in fact,
the current setup requires some justification as it deviates from the
FHS in minor ways, which has delayed getting Bacula available to other
parts of the organization with more stringent requirements.
FHS is the right way to do this on Linux, and there are similar
"recommended" setups for AIX, Solaris, etc. Don't invent something
different -- in enterprises, different == bad.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.