Bryce on Technology

I recently implemented a javascript based slider using MooTools. I’m increasingly becoming a huge fan of Mootools. Their documentation is great and the code I write just seems to be much cleaner. I don’t feel like it’s as fragile as js I’ve written in prototype/scriptaculous.

The content slider, which I pretty much implemented verbatim using Antonio Lupetti’s great tutorial at http://woork.blogspot.com/2009/01/elegant-animated-weekly-timeline-for.html.

Antonio’s tutorial is really great. It is missing two elements which I think improve the code base: Read more…

Stuff I'm Working On coding, HowTo, javascript, mootools

I am becoming a better systems administrator every day secondary to my work as a ruby on rails and PHP developer. As a very small development shop I have very limited resources to perform the backup and recovery policies bigger shops and huge enterprises employ.

However, after just a morning of futzing with a few key linux commands and better utilizing a service I already back up my source code to (www.github.com) I have a found a robust and secure way to handle automated, off-site, redundant backups in a way that will let me compete with some bigger shops. I’ve posted the code below so I hope you will find it useful. Over the next few posts, I’ll unpack what I’ve written and the philosophy behind it.

A few things bothered me in the way I was doing traditional backups:

1. I knew I had to get them off-site, but actually finding time to get off-site (to a secure location) wasn’t happening.
2. The backup had to be absolutely secure. My clients’ source code is too precious and leakage too damaging to make even one mistake with security breach
3. Had to be simple and automated. I usually have 10 other things I need to do at the same time. I didn’t want backups to be number 11.
4. Small file size. Again, being a small dev shop, I didn’t want to put a lot of cost into storage of incremental backups
5. Incremental backups were key since I don’t want to go to all this trouble only to restore a copy of the bad data I was trying to replace. If I a problem isn’t made known until after the next set of backups are made, I’d be overwriting bad data with bad data; better to restore to the point before the problem happened.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

 
 
#!/usr/bin/sh
 
#backupdb
echo "======================================"
echo "backing up database"
mysqldump -u backup --all-databases > /var/www/html/alldatabases.sql
 
#tar and compress the directories really hacky and should either make a file for exclusions or just get rid of the crap
tar -czvvf /var/www/bkp/websqlbkp.tar.gz /var/www/html/alldatabases.sql /var/www/html/*
 
#encrypt that mug and then remove the decrypted file
echo "encrypting backup"
openssl des3 -salt -k supersecret \
        -in /var/www/bkp/websqlbkp.tar.gz \
        -out /var/www/bkp/websqlbkpencrypted.tar.gz
 
#cleanup files I don't want people to see
echo "cleaning up files"
rm -rf /var/www/bkp/websqlbkp.tar.gz
rm -rf /var/www/html/alldatabasesl.sql
 
#update the git repo
echo "committing to git `date` "
cd /var/www/bkp/
 
echo "adding to git"
/usr/local/bin/git add .
 
echo "commiting git"
/usr/local/bin/git commit -a -m "commiting backup on `date`"
 
echo "pushing to github"
/usr/local/bin/git push origin production

How-To, HowTo, Stuff I'm Working On HowTo, technology