On 05/18/10 10:37, Joseph Spenner wrote:
> --- On Mon, 5/17/10, Phil Stracchino <alaric AT metrocast DOT net> wrote:
>> As previously mentioned, staggering backups on your clients is
>> fairly easy.  A six-day backup cycle is *unusual*, because it 
>> doesn't fit neatly into either weekly or monthly schedules, and
>> because we don't have an ideal calendar divided into equal months
>> of a multiple of six days.
> 
> Ok, I do have a spare disk in my system I can use for the 7th day.
> So, let's change the schedule such that I have 3 sets of "7 disks",
> for a total of 21 disks.  Perhaps this will simplify the scheduling.
> I still wish to have a full backup for every client at least once per
> week (7 days).

Yes, that part is simple to set up.  So as I understand it, you're going
to have a "media set" of seven disks, and you're going to have three
sets of disks that you swap in on a weekly cycle, right?  And you want
each client to have a full backup once per week and an incremental every
other night, with the full backups staggered night-to-night to spread
them across the whole week.  Correct?


> The configurations in bacula really confuse me.  It seems like I need
> configuration settings which reference other settings which reference
> pools which contain more settings which eventually point to what I'm
> really backing up.  Perhaps this gives the administrator extremely
> specific granularity in what gets backed up, but I think my needs are
> much simpler.  I just have a bunch of clients with identical backup
> needs, they get backed up every night between 1am GMT and 12am GMT in
> no particular order, and I want a full backup of each one every week.
> That's pretty much it.

It's not really as complex as it looks.  You have storage resources
which contain media pools, which describe the properties of the
individual volumes they contain.  You have schedules that describe when
backups happen, you have client resources that identify the clients they
happen to, and you have job resources that describe how the backups are
performed, to what clients (by reference to client resources), when (by
reference to schedules), and to what media (by reference to pools).


> I tried using pieces of the config referenced at
> http://bacula.org/5.0.x-manuals/en/main/main/Backup_Strategies.html 
> I'm not sure what the "WeeklyCycleAfterBackup" does.  Do I really
> need that?

In that example, if you look at the schedules, it tells you what the
"WeeklyCycleAfterBackup" schedule is for:  It's the schedule for the
bacula catalog backup, which is set to start *after* the regular weekly
backup for reasons that should be obvious.  The usual trick is to start
the Catalog backup shortly after the main backup is started, and at a
lower priority.  Thus the Catalog backup will wait to run until after
the main backups complete, and then back up the Catalog and all the
metadata of the main backups that just ran.


> And the Pool definitions as well.  But now when I run my backups, I
> get an error:
> 
> 18-May 09:00 bacula-va-sd JobId 62: Job
> Bacula_Server.2010-05-18_02.00.00_08 is waiting. Cannot find any appendable 
> volumes. Please use the "label" command to create a new
> Volume for: Storage:      "FileStorage" (/opt/bacula/volumes) Pool: 
> TuesdayPool Media type:   File

Do you have Volumes created in your Pools, or are you using autolabeling?

> So, I suspect I need to modify something since I have different Pools
> now?  Do I really need all these Pools?

If you want to make sure each night's backups use a separate disk, then
yes, you pretty much do need different pools for each night of the week.
 In a hardware configuration like that, backing up to removable disks,
with (I infer) one disk being used each night, you probably need to
create separate Storage devices pointing to the mountpoints of each
individual disk.


> I'm OK with totally wiping my database clean and starting from
> scratch.  So, if anyone has a super simple configuration I can try
> I'm up for it!

You'll probably want to do that *anyway* once you get all the wrinkles
ironed out of your configuration.


-- 
  Phil Stracchino, CDK#2     DoD#299792458     ICBM: 43.5607, -71.355
  alaric AT caerllewys DOT net   alaric AT metrocast DOT net   phil AT 
co.ordinate DOT org
         Renaissance Man, Unix ronin, Perl hacker, Free Stater
                 It's not the years, it's the mileage.

------------------------------------------------------------------------------

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users