EvolveBDR v0.0.2 - a Bacula OVF

EvolveBDR v0.0.2 is a portable OVF format Virtual Machine pre-configured to run Bacula as easily as possible.  EvolveBDR aims to supply sane default configurations to allow SysAdmins to rapidly deploy EvolveBDR in their environments while greatly minimizing the learning curve necessary to successfully implement Bacula as a file level backup solution.

I spend a large portion of my time on the internet haunting /r/SysAdmin on Reddit.  A common question on that venerable forum often contains something similar to "Can you please recommend a low cost/FOSS enterprise backup solution?"  I and many others are quick to recommend Bacula, BackupPC, Areca, Cobian Backup, and Veeam's free edition.  Personally, I find myself recommending Bacula more often than not; a proven solution that has been in development for the better part of a decade; if not longer.

The power of Bacula comes with a small price: a learning curve that is often difficult for the novice *NIX administrator; especially for the Jr. Admin who finds themselves in a primarily Windows-based environment.  (This is not a judgement against their skill-sets or a denigration of their worth as a SysAdmin.)  The creation of EvolveBDR is a response to this challenge with a OVF format Virtual Machine which comes pre-configured to use Bacula as a file based backup solution using hard disks as the primary archival medium.

Some features you may find interesting:

• The virtual appliance has been built on top of TurnKey Core v12.0 RC.
• The file system lives on top of LVM for rapid provisioning of more disk space without rebooting the VM.
• CurlFtpFs to make remote backups easier.
• A default volume pool and Windows-friendly FileSets (one at the moment for Win2k3; Win2008 on the way) to help Windows SysAdmins spend less time configuring Bacula and more time implementing EvolveBDR/Bacula in their environment.

It should be noted that EvolveBDR is still being developed and tested.  If you insist on using this in production, you do so at your own risk.  It is also recommended that you change all of the currently configured passwords to something a little more secure than 'bacula'.  ;)

Admins locked out by Group Policy? PsExec to the rescue!

Have you ever accidentally used Group Policy to prevent yourself from being able to edit Group Policy?  You wouldn't be the first SysAdmin - it can happen to even the most seasoned of us; especially in the middle of the night during a particularly long maintenance window...

Here is the scenario:

A single Windows Server 2008 R2 machine running AD and RDS (clearly in need of a couple of Domain Controllers and the transfer of FSMO roles away from the Remote Desktop Session Host).  Fortunately, AD Recycle Bin is enabled.  A young SysAdmin decides to modify Group Policy on this time bomb without peer review or change management.  Fortunately, they didn't edit the default Domain Policy, but they did apply a policy to all Users that prevented access to the Control Panel and explicitly forbid the execution of the MSCs from Start --> Run.  Hell, he even disabled the execution of MMC, RegEdit, and CMD.EXE...!

Wouldn't you know it, he even had the courtesy to run a 'gpupdate /force'...

It is at this time that many SysAdmins would try to do things like edit the Registry, delete entries from SYSVOL, and other nefarious items that are sure to make your day a whole hell of a lot worse.

(Had the Jr. Admin only edited the default Domain Policy, we could perhaps use Dcgpofix to restore the default Domain Group Policy for our Disaster Recovery.)

Fortunately, TaskMgr was still accessible, and PsExec was installed on the host to fix a previous issue with a legacy application that wasn't multi-thread aware.  (We modified the default shortcut for the application and added PsExec to set set the affinity of the application to a single core - works like a charm!)  How did I fix the issue?  I did the following:

Start --> Run --> taskmgr followed by File --> New Task (Run...) and 'psexec cmd.exe' with the task created with administrator privileges.  This allowed me to spawn a shell.  Now, I thought I was going to have to use REG from the command line to query and delete Registry keys, but my intuition told me to try running MMC for the hell of it...

And it launched.

Now, the real test is whether or not I can add the GPO snap-ins and edit the policy object...

Yes.

I then used the Group Policy Editor MMC snap-in to disable the GPO followed by another 'gpupdate /force' from my PsExec-spawned shell.

I saved the day, and now I have convinced the client to spin up a few Domain Controllers.

As for the Jr.?  There never was a Jr. SysAdmin - it was me the entire time; or, at least I think it was me.  An unnamed party also has Domain Admin rights, but they swear they didn't cause this blunder.

Maybe I will dig through the logs, for fun and profit, just to make sure...