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

------------------------------------------------------------------------------
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