Hi Craig and Kern,
Just one observation....
On Wed, Apr 8, 2009 at 5:09 PM, Kern Sibbald <kern AT sibbald DOT com> wrote:
> Hello Craig,
>
> Thanks for the very kind email, and the well balanced presentation of some of
> Bacula's features that can be improved :-)
>
> Concerning automatic handling of LVMs: I think it would be a nice feature,
> where I hesitate is that it is OS dependent, and 99% of the directives we
> have (not all) are OS independent. That means that before implementing
> something like that, we need to give it very careful consideration.
>
I can't comment on the technicalities, but I do know that within
Amazon's EC2 (their cloud computing service) a perennial issu that
comes up is:
'How do I do backups of ...' usually MySQL is inserted
The answer seems to be:
'Place <it> on a LVM volume and take scripts to take snapshots'
The process looks something like:
1. mysql connection (left open): FLUSH TABLES WITH READ LOCK;
2. lvcreate -L16G -s -n dbbackup /dev/vg/myvmdisk1
3. mysql connection: UNLOCK TABLES;
Anyway, I just thought I'd throw in one more use case to contemplate.
There maybe other common EC2 cases but the mention of LVM snapshots
jogged the memory.
While such things are OS dependent they do potentially expand the user
base if the answer to backup questions in the EC2 becomes:
"Configure and point Bacula at it and it'll just work"
Thanks for a great application!!
HTH
Mark
> On the question of lstat in the database: yes, a number of people have
> requested what you are suggesting. The problem of just putting the lstat
> packet in the database is two fold:
>
> 1. Without careful though, it would very significantly increase the size of
> the database and possibly slow down record insertion. The size issue is
> really quite worrisome. Your statement that PostgreSQL would be as efficient
> as the current base64 encoding is interesting and worth understanding ...
>
> 2. The current lstat is not really system independent (I forgot that the silly
> mode bits can differ from Unix to Unix).
>
> Item 2 is just something to consider when we re-work the lstat packet -- it
> probably needs to be a part of the project.
>
> Item 1 is much more problematic. Eric and I have been working on a design for
> making selected parts of the lstat more accessible (i.e. have them as
> separate table columns -- perhaps Eric could dig out our notes on this
> subject). There are fields that we can totally eliminate, and that would
> largely compensate for the extra space taken by adding new separate columns,
> but for 3.0, we decided not to make any changes since all the design issues
> were not totally clear. One important aspect is the requirement to convert
> existing databases.
>
> You certainly have the right attitude by mentioning MySQL and SQLite. One
> important point is that we need to be as SQL engine neutral as possible (not
> always so easy).
>
> If you would like to work on either or both of these projects, we would be
> very happy, but as you can see, I feel we need to carefully design what will
> be done before coding. However, as long as we discuss these points and
> resolve as much as possible beforehand, and as you say "assuming perf testing
> worked out and it worked OK for MySQL and SQLite as well", I don't see any
> problem, and the simple answer is yes, it is OK ...
>
> What do you think?
>
> Best regards,
>
> Kern
>
> On Wednesday 08 April 2009 03:35:50 Craig Ringer wrote:
>> Kern Sibbald wrote:
>> > On Tuesday 07 April 2009 17:32:27 Reynier Perez Mira wrote:
>> >>> 1.Bacula Release 3.0
>> >>
>> >> When will be Bacula 3.0 released during this week?
>> >
>> > Since I am working 12-16 hours a day, and I as well as the other
>> > developers are doing it all for free: It will be ready when it is ready
>> > (during this week).
>>
>> For what it's worth, as someone who's done my own fair share of OSS dev
>> work (on Scribus, PoDoFo, lprof, and misc other things):
>>
>> *THANKS*
>>
>> Bacula makes part of my job dramatically simpler, easier, and safer. It
>> takes some learning and can take some coaxing to get it to do what you
>> want, but once it's set up it *just* *goes*, and it informs you if/when
>> something DOES go wrong. I cannot overstate the value of this.
>>
>> It's also nice to see a project where I start using it and don't
>> immediately feel the gotta-fix-that-unfeature/bug/whatever itch. Because
>> Bacula already does what I need it to. Ther are things where it could be
>> simpler/cleaner/nicer, mostly in configuration, but they're all pretty
>> minor.
>>
>> Other backup systems I've investigated (including several commercial
>> ones) have had weird limitations, horrifying UIs (yes, compared to
>> Bacula!), and/or scary packaging and setup that makes me reluctant to
>> let them anywhere near my servers.
>>
>> Bacula is already integrated into most of the OSes I use, and trivial to
>> install on the others.
>>
>> Now that it handles deleted files correctly, it's pretty much perfect.
>>
>> BTW, if I was to find the time to implement native fd support for LVM
>> snapshots, so that rather than using pre- and post- scripts for
>> snapshots and using path stripping, the user could just specify (eg)
>> "lvm_snapshot=/var/spool/cyrus/mail;2GB" in the FileSet options and have
>> Bacula take care of managing the snapshot, would that be something you'd
>> potentially want to see included?
>>
>> Also, if I was to submit a patch that changed the database format for
>> post-3.0 to store lstat attributes as individual fields in the DB,
>> rather than using the almost-base64 encoded strings Bacula currently
>> uses, would that be considered? I'd *REALLY* like the ability to query
>> those values directly and to create indexes on them, something I can
>> currently do only by adding a C helper function to PostgreSQL and using
>> functional indexes. Kinda clunky. Since (at least in Pg) storage as
>> native values is at least as storage-efficient as the base64 form, would
>> this be considered assuming perf testing worked out and it worked OK for
>> MySQL and SQLite as well?
>>
>> >> Is the SVN release ready for production?
>> >
>> > Yes. This was answered in the first paragraph of the email you are
>> > citing ... :-)
>>
>> I've been using 2.5.42b2 for weeks now, by the way, and the only issues
>> I've encountered have since been fixed in svn.
>>
>> --
>> Craig Ringer
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
