Hello Maria,

Thanks for your contribution.  I'll take a careful look at it and the 
placement you specified and get back to you a little later.  Since it is an 
addition, rather than a change, it should be quite easy for me to fit it 
in ...  :-)



On Monday 03 October 2005 09:51, Maria McKinley wrote:
> My suggestion was actually for a different part of the manual then the
> patch that Arno has written is for.  I was imagining it being placed as
> another subsection in the Getting Started with Bacula section under the
> subsection, Understanding Pools, Volumes and Labels (maybe call it
> Understanding Jobs and Schedules).  Not sure what people thought of it,
> though.  I have never made a patch before, but if people liked what I
> wrote, I could give it a shot.  Seems like it shouldn't be too hard,
> since I'm not changing any of the current text, just adding another
> subsection.  (Famous last words...)
>
> Since Phil couldn't tell me what does happen when there are two jobs at
> the same time with the same priority, I haven't changed added that, but
> would be glad to if someone else knows.
>
> It is entirely possible that everyone thinks the changes that have been
> suggested by Phil sufficiently deal with the problem, which I can
> understand (I certainly think it has cleaned the documentation up quite
> nicely, thanks Phil).  Nevertheless, I think it would also be useful to
> include this more general introduction paragraph in the introduction to
> bacula, but maybe other people think this intro is already long enough,
> which I would understand.  Also, I won't be at all offended if people
> have ideas to make it clearer or better written.
>
> cheers,
> maria
>
> fyi this was what I wrote (with a few minor adjustments):
>
> In order to make bacula as flexible as possible, the "directions" given
> to bacula for backup are broken into several pieces.  The main
> instruction is the job resourse, which defines a job.  A backup job
> generally consists of a fileset, a client, a schedule for one or several
> types/times of backups, and a pool, as well as additional instructions.
>   The thing that usually defines a job is what is being backed up, so
> typically each fileset/client combination will have one corresponding
> job.  Most of the directives, such as pools and schedules, can be mixed
> and matched among the jobs.  So you might have two jobs backing up
> different servers using the same schedule, the same fileset (backing up
> the same directories on 2 machines) and maybe even the same pools.  The
> schedule will define what type of backup will run when (full on monday,
> incremental the rest of the week, for example), and when more than one
> job uses the same schedule, job priority determines which actually runs
> first.  If you have a lot of jobs, you might want to use JobDefs, where
> you can set defaults for the jobs, which can then be changed by the
> inidividual job definitions, but saves rewriting the identical
> parameters for each job.  In addition to the file sets you want to back
> up, you should also have a job that backs up your catalog.  Finally, be
> aware that in addition to the backup jobs there are restore, verify, and
> admin jobs, which have different requirements.
>
> Kern Sibbald wrote:
> > On Saturday 01 October 2005 18:43, Phil Stracchino wrote:
> >>Arno Lehmann wrote:
> >>>Please note that in certain cases this wayof working doesn't produce the
> >>>expected results: If (under unix / linux) you move a whole directory,
> >>>the directories contents access times are not updated. Thus, when moving
> >>>a directory into a fiilesystem tree that is backed up, bacula might not
> >>>back up files you need to be stored. When moving directories inside the
> >>>backed up filesets, their contents will not be backed up from the new
> >>>locations. You can work around these problems by using the touch command
> >>>on the files in directories affected by such operations, although this
> >>>might break other software.
> >>
> >>This is a good call, and this paragraph should definitely go in there as
> >>well.  I suggest placing it after the st_mtime/st_ctime discussion,
> >>making it the last paragraph in the replacement text.
> >
> > Hello,
> >
> > After reading all the emails, I'm a bit confused, so I'm not planning to
> > do anything for several reasons: 1. I have a number of undocumented
> > features to document that important to work on, and for which I am having
> > problems finding the time. 2. What is desired in this case is not clear
> > to me as there seem to be several proposals and counter proposals.
> >
> > Just the same, if some improvement can be made along the lines you have
> > been discussing, all the better, so if someone can put it all together
> > and supply me a patch to the development doc, and everyone agrees with
> > it, and it looks good to me, I'll be more than happy to apply it.

-- 
Best regards,

Kern

  (">
  /\
  V_V


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to