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