Thank you for your feedback, Rodrigo.  I looked up the copy job
information as you suggested.  From what I can tell, you have to purge
the original job before you can use a copy.  This means to me that to
do a restore, we have to:

1) identify all the jobs associated with all the files being restored.
2) purge those jobs from the database (which promoted their copies to
a restorable state)
3) perform the restore

Since I'm trying to make it as easy as possible for my coworkers to
restore, having them go through the process of identifying the jobs
for a given backup and purging them seems a bit much.  I've decided to
stick with the dual client method.  I've implemented it and tested it.
 It is working beautifully!

We're running CentOS and the Redhat/CentOS init script for bacula-fd
as supplied will not allow multiple clients.  I had to modify it to
allow that.  In fact, I will look into submitting my updated init
script to the package maintainer.  The init script doesn't use the PID
files generated by bacula to manage the process and it should, even if
you just want to run a single client.  Other than that, the only
drawback is that when we do perform offsite backups, we are
essentially moving that data over the network twice (once for the
normal backups and once for the offsite backups.)  Since we're not
moving a lot of data, this is a non-issue.

Thanks again!

Eric

On Sun, Sep 11, 2011 at 5:55 PM, Rodrigo Renie Braga
<rodrigorenie AT gmail DOT com> wrote:
> Well, I'm really starting to figure this bacula feature yet, but I'd
> recomend taking a look at Copy Jobs.
>
> The ideia would be only running your normal Full/Diff/Inc Backups and then,
> weekly, create a "copy" of them on your offsite storage. When restoring, it
> will require only your normal Full/Diff/Inc backups. Only when these were
> unavailable (like in a disaster!) that Bacula would automatically require
> the Offsite Storage.
>
> I lost all my documentation and links that I had about Copy Jobs (along with
> my 1TB HD), but I'm once again taking a look at this feature to implement it
> on a different company and as soon that I find these documentations again I
> will send them to you...
>
> 2011/9/8 Eric Pratt <eric.pratt AT etouchpoint DOT com>
>>
>> I'm using Bacula with USB drives to perform offsite backups.  I'm
>> trying to create the simplest process possible so in the event I'm
>> unavailable, my coworkers can perform restores with confidence without
>> knowing a whole lot about bacula.
>>
>> Originally, our offsite backups were performed as just a part of the
>> normal schedule for a job called "JobName".  The schedule was:
>>
>>  Run = Level=Full 1st sun at 23:05
>>  Run = Level=Differential 2nd-5th sun at 23:05
>>  Run = Level=Incremental mon-sat at 23:05
>>  Run = Level=Full sun at 10:00 Pool=OffsitePool
>>
>> Any scheduled runs that did not define a pool went to our normal VTL
>> pool.  The problem I had there was that the weekly fulls at 10:00AM
>> each sunday became the new baseline for all following differentials
>> and incrementals.  The drive with offsite backups is cycled weekly so
>> this means attempting to restore a directory that got blown away
>> Tuesday meant bringing the offsite drive back before restoring.  The
>> intention for our offsite backups is purely to give us some form of
>> disaster recovery ability.  In this case, they're actually hindering
>> us.  Worse, the more we have to bring these onsite, the less likely
>> they will be "safe" for DR purposes.
>>
>> I want to separate the offsite backups from the normal backups so I
>> removed the last line of the schedule above.  Then I created a new job
>> called "JobNameOffsite" and a new schedule called
>> "JobNameOffsiteSchedule" that looks like this (the pool is defined in
>> the job to be OffsitePool):
>>
>>  Run = Level=Full sun at 10:00
>>
>> Now, the differentials and incrementals appear to be looking at the
>> full from the 1st sunday of the month and not the weekly offsite fulls
>> for the last full.  However, restoring most files still results in
>> attempts to require the offsite backup volumes since it was the last
>> job to use that fileset for a specific path on a given client.  Since
>> the offsite disk is not available on any given week, this can pose
>> problems.  I can of course work around this and pull files from
>> specific job IDs but I am trying to keep this simple for non-admins to
>> perform restores in my absence.
>>
>> My next idea is to configure a second client on each machine just for
>> offsite backups.  If I do this, I can tell bacula to restore from
>> ClientName or ClientNameOffsite.  This should provide 100% separation
>> of the normal and offsite backups as well as an easy method for
>> restoring data for those who are not experts with bacula.  They would
>> simply choose to restore from "ClientName" and it's business as usual.
>>  Restores from "ClientNameOffsite" would be only in emergency
>> situations.  Even then, it's as simple as bringing the disk on site
>> and choosing to restore from the proper client name.
>>
>> Before I start down this path, does anyone have any other ideas to
>> keep restores simple while still achieving offsite backups within
>> bacula?  Is there some simple way to tag a job as offsite to provide
>> this level of separation without a second client on each machine?  Are
>> there any pitfalls with my proposed approach that I should be aware
>> of?
>>
>> I am trying to avoid some things in this process.  The primary one is
>> avoiding doing anything outside of bacula.  This is tied to the
>> simplicity factor.  I can document the restore procedures, but I want
>> to avoid having people lookup volumes tied to JobIDs and performing an
>> rsync to move the volumes into place.  I want them to just go into
>> bconsole, restore, and be done with it.
>>
>> Thanks, everyone!
>>
>> Eric
>>
>>
>> ------------------------------------------------------------------------------
>> Doing More with Less: The Next Generation Virtual Desktop
>> What are the key obstacles that have prevented many mid-market businesses
>> from deploying virtual desktops?   How do next-generation virtual desktops
>> provide companies an easier-to-deploy, easier-to-manage and more
>> affordable
>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>> _______________________________________________
>> Bacula-users mailing list
>> Bacula-users AT lists.sourceforge DOT net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
>

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users