I’ve been using git_backup to back up the websites I run for quite a while now. It works well and I only need to scan the daily cron emails to see if the backup went well or if there were any odd files changed the day before.
One thing that I didn’t expect when I started using it was how it would enable developing those websites in a sandbox without any danger of affecting the production instances.
Back when my blog was powered by Wordpress, I would do most of my major modifications on a copy of my blog that ran on my local desktop.
First, to provide the LAMP stack, I downloaded MAMP.
Then, I cloned my blog from my backup server and modified the code to point at a local database.
1 2 3 4 5 6 7 8 9
And finally, I imported the live database data:
At this point, I was free to try out new plugins or do any wide-reaching change without worrying that I might break something permanently. Then, when I was confident about the change I wanted, I would change the live site.
When I wanted to update my local working copy, all I needed to run was a few git commands:
1 2 3
The first clears out any changes I had made. The second removed any untracked files (new plugins, etc.). And the third grabbed upstream changes while preserving my commit that changed the config to point at my local database.
Then, I re-imported the live database data.
Once this was done, I had an up-to-date copy of my blog to play around with.
For one of the Drupal installations I ran, I used a scripted version of the above technique to keep a development copy up to date on the server. This allowed the site’s admins to have the same safety net while trying out new things that I had locally, but without having to set up a local database and web server.
Here is the cron script:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
The only odd line is the
chmod. That was necessary because Drupal itself made that directory unwritable and that prevented the
git pull command from working.
Cron ran this script at 1am every night, so each morning the development site would be an up-to-date copy of the previous day’s content and code. This was frequent enough for the site’s owner and when he wanted it reset in the middle of the day I would just manually run the script.