The goal is to dump the database to the filesystem, add it to the tar file, encrypt it and then delete the clear text version of the file.

Security considerations abound. In a nutshell however, it is important not to publish any unencrypted database dump anywhere. Dump files can be searched on easily by Google and if you house even a morsel of private user data, you’ll be in trouble very quickly if it’s not encrypted.

Getting started, the MySQL command to dump a database is:

 mysqldump -u user -psupersecret --all-databases > /some/dir/backupsql.sql

-p will prompt for a password

-all-databases will dump every database you have running on the mysql instance. If you want a specific database, replace –all-databases with your_db_name

This command pushes the output of the mysqldump command to a file on the filesystem.

Since I don’t want my cron job to be prompted for a user’s password when dumping the db, I have created a special backup user with only enough permissions to read the tables, and write their contents to a file. You can create such a user by running the following command inside a mysql prompt:

GRANT SELECT, LOCK TABLES ON *.* TO 'backup'@'localhost'
IDENTIFIED BY 'supersecret'

Make sure to flush privileges after creating users. There’s not much more frusterating than trying to figure out why that script didn’t work.

One security consideration is that if you were to run the ps command while the dump script is running, it will expose the username and password of the backup user potentially allowing other users of the system to make select statements to databases they otherwise shouldn’t be on.

By limiting the backup user access only from the localhost, this eliminates the possibility of someone else dumping your database from some other host; the user must be logged into the box the database resides on.

At the conclusion of this script, we will have all the database data and structure backed up to a file on the filesystem. In the next post, I’ll explain how to add this data to a tar archive and then encrypt the whole mess.

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

The article was profound in explaining Linux’s potential power play in the netbook arena; netbooks are small low power laptops. They’re great for surfing the web, doing emails and many other normal, everyday, tasks. Their low power makes them very affordable but has a major shortcoming when it comes to loading an operating system. Without a lot of memory (Ram) or hard drive space, large operating systems with many background processes would cripple the tiny netbook and render them useless.

Enter Linux. Linux is a highly configurable dream of an operating system that technologists love to play with. Because of its configurability, it’s a perfect candidate to run on a netbook. Processes that are never used can be shut off automatically. Shutting down processes means 1) more memory to do web surfing 2) more processor cycles for web surfing and 3) less space taken up on the hard drive.

Another very important consideration is spyware/malware. Linux is a very secure system by its very nature. The kernel (the brains of the OS) is more protected by its very design. Because of its seemingly insignificant market penetration, spammers and malware developers don’t have any incentive to develop their bugs for this OS. Linux wins again.

Finally, slapping Linux on the netbook follows a bigger trend in the commodization of hardware. Computers are getting cheaper and cheaper as business processes become more efficient and components become less expensive. The operating system has become a bigger slice of the total purchase price of a system. As hardware continues to become more of a commodity, vendors like IBM, HP and DELL will look for ways to jettison the proportionately higher cost of the OS.

As netbooks become more popular, Linux will become more familiar. This familiarity will enhance a seemingly insignificant player in the consumer operating system battle and that could really change the game.

original link:

http://www.fastcompany.com/blog/chris-dannen/techwatch/2009-year-linux-revolution