On 05/18/10 10:37, Joseph Spenner wrote: > --- On Mon, 5/17/10, Phil Stracchino <ala...@metrocast.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 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
