Bacula-users

Re: [Bacula-users] Other than Bacula

2014-06-02 12:38:19
Subject: Re: [Bacula-users] Other than Bacula
From: Kern Sibbald <kern AT sibbald DOT com>
To: Steven Haigh <netwiz AT crc.id DOT au>, bacula-users AT lists.sourceforge DOT net
Date: Mon, 02 Jun 2014 18:35:29 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/02/2014 03:16 PM, Steven Haigh wrote:
> On 02/06/14 23:01, Kern Sibbald wrote:
>>
>> Hello,
>>
>> Your comments are quite valid.  However a better approach to solving the
>> problem is when people like you (especially English speakers) find the
>> solutions, you modify the documentation to include the correct words for
>> someone not familiar with the software to understand it, and then send
>> that in as a contribution, then everyone (including me) benefits from
>> your work :-)
>
> At this stage, I'm still not sure I have things set up correctly myself.
> I'm not quite clear with all knobs and buttons in Bacula. TSM is all
> coming from a file based - not job based. This means that things like
> retention are handled per file - not per job.
Correct, and that can be very confusing.  The advantage of the way
Bacula does things concerning Jobs vs Files is that one Bacula instance
can handle the same amount of work that it takes 10-12 instances of TSM
to run.
>
>
> I'm not exactly clear what will happen with a file that is still a
> system that is backed up and the retention time expires. Is that file
> backed up again on the next incremental? Does it not get backed up at
> all again?
The retention period applies only to the time a file/job/volume is kept
in the catalog, and what is backed up is indicated by Phil's newby "doc".
>
>
> My current config does a Full backup once - then a nightly incremental.
> I'm not exactly sure that this will do what I want - but I can't find
> anything that says either way...
>
> Some of my backups are multi-Gb and are over a slow (5Mbit) link - as
> such, incrementals are good - and full backups take hours. I'm not
> convinced that Bacula handles this case well however - but I am yet
> unable to prove one way or another.
>
> The whole concept of removable media in Bacula makes sense for tapes,
> but does not translate well to removable disks. vchanger is a rather
> nasty hack - but (kinda) works. It would be much nicer to have bacula
> deal with removable disks directly - and not hacked in. In the TSM
> world, this was easily done by "vary offline /path/to/volume" and can
> easily be scripted. TSM then knows the volume isn't available and
> doesn't try to use it. During a restore, it will say "VOLUME <blah>
> required".
Bacula actually handles removable drives quite well -- many years ago, I
programmed it to do my laptop backups while I was on vacation to USB
sticks.  The problem is that most people don't know how to configure
them properly.  vchanger or even Bacula's virtual autochanger is
overkill for removable media.

>
>
> I'm not sure if this would take much to implement in bacula - but it
> would be lightyears ahead of what is currently there....
>
> Thoughts and comments?
>
Once you get over the steep learning curve you will find Bacula robust
and stable.

Good luck.
Kern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlOMp9EACgkQNgfoSvWqwEgDEgCfZkI+nevUTEDWLKvT7QMoAPm8
LbYAmwdW6LAwhrICkaZtnMjrCIFL37ii
=MENy
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users