Server Backup Management Script

Running the infrastructure for your home, small business or company can be fun but you also take the risks on yourself.  Data loss being the biggest point of failure.  Nothing short of a steady daily incremental backup and monthly full backup.  These backups should be stored offsite.  All important storage drives should be raided with redundancy.  The server(s) needs to be on a UPS (and test the UPS).  Frankly the majority of this is common knowledge.  The big pain comes in actually setting the backup system up.  Reinventing the wheel is always a bad idea so instead of coming up with your own set of backup scripts the first step should be to see what existing software or solution are out there.

This applies only to Linux.  I tested many pieces of software and found most of them clunky at best.  Without naming names I’ll just say every piece of software I tried was lacking when compared to a scripted setup.

Searching the internet I came across this perfect script for which I take no credit for but I want to share.  Backup-Script (mirror: Backup-Script)

All instructions to run the script are contained within the file description.  It is very simple to setup, the instructions even include a good common cron tab line.

I customized the script a bit to suit my needs a bit better.  It is ready to go for a vanilla ispconfig or plesk setup.  It manages both the backup but also the restore.  It does a full backup and then incremental backups.  Restoration is easy, the same script can be used.  All the instructions are in the script header.

So I ran a full backup onto a local hard drive.  Then moved that hard drive to an offsite storage location.  The incremental backups are fairly small in comparison so those auto transfer via rsync upon completion.

GIT Work Flow

I get asked a lot about SVN, GIT, Mercurial.  It is clear to me that SVN has been superseded by GIT and I think many others agree.  Go ahead and read a great comparison here (GitSVNComparison).  My favorite addition (other than the dramatic decrease in size of repositories) is the branching mechanism that GIT adds.  This also becomes the learning curve to long time SVN users.  SVN users famously create the classic trunk,branch,tag structure for every repository they use but almost never utilized anything but trunk.

So the biggest learning curve with jumping into GIT is the intended workflow.  Lets take a quick look at how one should use GIT when working on a group project.  This workflow maximizes modularity of your code additions and minimizes the downtime created by conflicts.  To get you thinking while you are reading.  Typical branching usage is to have each developer work in their own branch.

First some terminology:

  • master branch –  This is essentially your trunk in SVN.  This is the main working branch in SVN.
  • local commit – In GIT everything you commit is local until you push.
  • remote push – Since all your commits are local, they need to be pushed to the remote server.
  • checkout – In GIT this refers to checking out a branch, the entire repository is morphed into a branch when you perform a checkout.
Now the intended workflow:
  1. Clone the repository, URL is often provided.
    git clone
  2. Create a branch for you to work in.
    git checkout -b experimentalBranch
  3. Do some work!
  4. Commit your work.
    git commit -a
  5. Push your branch to the remote server (optional!), required if you want to get your branch from another machine.
    git push origin experimentalBranch
  6.  You have completed your bug fix lets say, time to merge your changes into the master branch.  First we have to checkout the master branch.
    git checkout master
  7. Make sure we have an updated master branch.
    git pull
  8. Time to merge your branch into master, this is the conflict resolution step.
    git merge experimentalBranch
  9. If all went well, push the updated master branch to the remote repo
    git push
 Now what if we are working on our experimental branch and some very important bugs are fixed and pushed into master.  These changes will directly impact your work.  It might be easier at this point to merge master into your branch so you can get the updates and keep working.
  1. Make sure you are on your branch.
    git checkout experimentalBranch
  2. Merge master into your branch
    git merge master


Diablo 3 Homebrew

Not all homebrew has to be emulators.  Not all homebrew we talk about has to come from here.

A very interesting project has fired up over the past 3 weeks.  Starting on IRC as a small project and growing into a large organization over github.  Being that the Diablo 3 beta was leaked very early to the public a strong desire to play was fired up in many.  As with many games today and particularily games of the Diablo genre almost everything in the game requires a server to communicate with.  So for those unlucky few who got shafted on the beta invites and wish to indulge in some Diablo 3 sights check out Mooege.  It is a private server emulator for Diablo 3.  No it won’t be the real game, no you can’t do quests yet.  You can run around the Diablo 3 universe, kill random mobs you spawn for 9001 damage and play with some of the skills for each class.  Surely this is enough to satiate your desires for Diablo 3 or exacerbate them, until the release date that is.

See Mooege and read the FAQ for installation info.

Update: Mooege Forums


Android SurfNet Workshop

Over the past year I was on the intern team for a Canadian research network called SurfNet.  SurfNet primarily concerns itself with interactive surfaces and things you can touch like a touch table or SMART boards.  The intern team gets projects submitted to them by professors that are part of the research network.  It was fun to work on the intern team but unfortunately it was not a lot of team work.  The majority of the projects came from my local university and I worked alone.  Even after finishing with them September 1, 2011 they are still keeping me on the payroll to work unofficially for them.  They wish to put the entire team on a project I have been working on over the past few months.

Every year they hold a conference and gather all the people involved in SurfNet.  This year it was held in Calgary, Alberta at the University of Calgary.  Excellent establishment, great people and an all around fun time.  This year they offered students to submit ideas for workshops.  I decided to submit a workshop on Android development.  Albeit not to related to SurfNet it is still an interactive surface and almost everyone is beginning to pick up on Android as the best way to developer quick research projects targeting mobile devices.  So I gave a 1.5hr talk on Android and it generated some pretty good interest. Here are the slides purely for interests sake.

Presentation Download



With the blessing of the author of libgambatte I am able to publically announce GambatteDroid.  Gambatte is a cycle accurate open source Gameboy and Gameboy Color emulation library.  As a developer I must say that libgambatte is very well written.  Kudo’s to all the authors involved in the project (Project Home)  As a Gameboy fan nothing is more nostalgic than playing it on a mobile device.  Go ahead and visit the forums if you have any comments to make.  Please rate or comment on the market page!

Video (Link):