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.pr...@etouchpoint.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@lists.sourceforge.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
