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