On 20/04/2019 20:14, Tilman Schmidt wrote:
Hi Radosław,
On Fri, Apr 19, 2019, at 11:40, Radosław Korzeniewski wrote:
What "resources" are you referring to? My current phone has 64bit OS
and 4GB of RAM (top models has 8G). Having a real bare metal server
with hundreds GB of ram is not a big deal. Storage space is extremely
cheap too. Unless you run your Bacula on wrist watch or 30Y hardware
you do not need to worry about any RDBMS for Bacula catalog.
That's the situation today. Of course nobody in his or her right mind
would use SQLite for a new Bacula installation.
But this thread was originally about an existing installation. Ten years
ago (just as an example, when I did one Bacula installation I am still
running) there were no phones with 4 GB of RAM. You were lucky if you
had that much memory in your server. Back then, SQLite was even the
default backend offered by Bacula during installation. So it was quite
reasonable to use it in a small environment. (Let's say less than 10
servers.)
How Great! We removed this legacy in the end! Let's celebrate! :)
You see it as a loss, OK. I see it as a great step forward.
It would be if there was a migration path for all those faithful Bacula
users who've been using and promoting the product for many years and who
have been misled into installing it with the SQLite backend initially.
As it stands, they find themselves in a dead end now. Can't you
understand that they are not in the mood to celebrate?
SQLite was deprecated in Bacula something of the order of ten years ago,
which is about when I installed Bacula at my current $ORK.
I did not even consider SQLite as the back-end for Bacula, not because
there was anything wrong with SQLite, I had used it previously and it
was and is in use with our current products, it was just not suited to
Bacula in 2009.
Why?
Because MySQL was available, and stable, and offloads the proverbial
metric tonne of processing, and on a machine with 4Gb or RAM (I still
have the box, but it no longer does the Bacula thing, that's now done on
a 72Gb system with an FC tape) it just made so much more sense.
Maybe my time writing databases (as in the underlying code) has given me
a different view on things, but I don't consider transferring data
between different databases a difficult thing, merely fiddly and a bit
time consuming.
I switched our system from MySQL to PostGRES eighteen months ago, and
after a bit of fiddling with the options of "mysqldump" and some
judicious use of "grep -v" and "sed" it just worked. There are about
1,500,000,000 entries in the "file" table, it took a couple of hours,
but what's time to a computer?
SQLite is a brilliant tool for single-user environments, but less
brilliant where you have an OS that allows you to do more things.
SQLite tracks PostGRES development as a guide to where it should go
next, moving from SQLite to PostGRES should be quite easy, possibly the
output of ".dump" (| grep -v "CREATE TABLE") would be very compatible.
Cheers,
Gary B-)
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
