On Tue, 21 Aug 2007, Kenny Dail wrote:
>> Yes, we looked at putting the bacula database on the main DB server and
>> decided against it for exactly this reason.
>
> Now, here I am moving my bacula DB to the main DB server because I'm
> worried about the bacula DB going down. Don't you have a live
Hello,
First, thankful all for the commentaries.
I will be opening a topic in the list of developers for that if to interest
and help me, if possible.
Dan Langille I will go to follow its suggestion and to make this
implementation. Code this and contribute.
If some Bacula user to need one cata
> On Tue, 21 Aug 2007, Bob Hetzel wrote:
>
> > IMHO, it's somewhat of a design flaw to set up your backup system
> > depending upon the enterprise db box. If the enterprise db server goes
> > down you need to get that up and running, then restore the bacula
> > catalog, then you can begin restori
The counter-argument to this is, of course, that the enterprise db
server is often the best equipped and configured in terms of
high-availability, clustering, and replication, making it the system
least likely to go down in the first place ;-)
Naturally, you don't want that DB server to be a d
On Tue, 21 Aug 2007, Bob Hetzel wrote:
> IMHO, it's somewhat of a design flaw to set up your backup system
> depending upon the enterprise db box. If the enterprise db server goes
> down you need to get that up and running, then restore the bacula
> catalog, then you can begin restoring everythin
If bacula supported other DB engines, bacula could be more easily
"evaluated", but the mysql setup is pretty darn simple. I applaud the
bacula developers for adding extra documentation on mysql into the
bacula docs rather than just a simple link to a google search or
www.mysql.org If I didn'
At 03:57 21.8.2007, Dan Langille wrote:
>On 21 Aug 2007 at 1:26, Peter Buschman wrote:
>
> > I will not go so far as to say that Bacula needs support for
> > additional databases but that, given the availability of coders and
> > testers, it can easily be ported to most RDBMS's on the planet.
> > S
I have to agree with Joao (apologies for spelling
problems due to Latin alphabet). The choice of
something as trivial as a catalog database can be
a complete show-stopper for many applications. I
have seen this when deploying a solution that met
all customer requirements, but which was SQL
Chris Hoogendyk wrote, sometime around 20/08/07 21:24:
> my gut reaction was ... I suppose you could write such an interface, but
> why? If someone insists on a commercial database, why would they not
> insist on a commercial backup solution? Or, alternatively, if someone
> was willing to accept an
On 21 Aug 2007 at 1:26, Peter Buschman wrote:
> I will not go so far as to say that Bacula needs support for
> additional databases but that, given the availability of coders and
> testers, it can easily be ported to most RDBMS's on the planet.
> Support for more databases is ultimately a positive
I have to agree with Joao (apologies for spelling
problems due to Latin alphabet). The choice of
something as trivial as a catalog database can be
a complete show-stopper for many applications. I
have seen this when deploying a solution that met
all customer requirements, but which was SQL
Yes, one database is very appreciable by customer whose not have skills
to manage a mysql, pgsql or sqllite databases. But my goal with this idea
is to promote Bacula in enterprise sites which has only one type of
database.
I believe in the independence of the database too.
Thanks for replys.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Hoogendyk wrote:
>
> Ryan Novosielski wrote:
>> Easiest way to handle this sort of thing generally is a DB dump and
>> backup the dump with Bacula. I assume all DB's have a tool to do this.
>> There's something that can be done with FIFO's, but
Ryan Novosielski wrote:
> Easiest way to handle this sort of thing generally is a DB dump and
> backup the dump with Bacula. I assume all DB's have a tool to do this.
> There's something that can be done with FIFO's, but I don't quite
> understand all that stuff.
>
> João Henrique Freitas wrote:
Clarifying the thinks...
On 8/20/07, Arno Lehmann <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> 20.08.2007 21:55,, Ryan Novosielski wrote::
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Easiest way to handle this sort of thing generally is a DB dump and
> > backup the dump with Bacula.
Hello,
20.08.2007 21:55,, Ryan Novosielski wrote::
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Easiest way to handle this sort of thing generally is a DB dump and
> backup the dump with Bacula. I assume all DB's have a tool to do this.
> There's something that can be done with FIFO's, b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Easiest way to handle this sort of thing generally is a DB dump and
backup the dump with Bacula. I assume all DB's have a tool to do this.
There's something that can be done with FIFO's, but I don't quite
understand all that stuff.
João Henrique Freit
17 matches
Mail list logo
