1 files changed, 172 insertions, 0 deletions
diff --git a/old/published/Webmonkey/backup_webserver.txt b/old/published/Webmonkey/backup_webserver.txt
new file mode 100644
index 0000000..b031480
--- /dev/null
+++ b/old/published/Webmonkey/backup_webserver.txt
@@ -0,0 +1,172 @@
+So you're a good little monkey and you have a backup strategy for all your local PCs, rsync, Time Machine or similar backup software mirrors your files to external drives on a regular basis, but what about your remote web server?
+
+Today we'll take a look at ways you can back up your HTML files, stylesheets, application files and even databases on your remote web host.
+
+The only thing you'll need is a remote web hosting service that allows SSH connections to the remote shell. 
+
+Ready for backup Nirvana? Okay let's dive in.
+
+== The Backup Tools ==
+
+We're going to assume your web host uses a Linux machine. If you're host provides Solaris, there are equivalents to all the Linux apps we're going to use. 
+
+Have a Windows web hosting service, feel free to add in the equivalent tools for Windows users.
+
+The first thing we'll do is use tar and bzip2, two command lines tools for making compressed file copies, to back up any flat HTML, CSS, Javascript or what have you files. Let's say your web host stores all your public files in a directory named www. In that case we're going to do something like this:
+
+<pre>
+tar -cf `date +%F`.tar /path/to/html_folder
+</pre>
+
+and then 
+
+<pre>
+bzip2 `date +%F`.tar
+</pre>
+
+That's all good and well, but we don't want to type those commands in the shell all the time so let's make a shell script. Login to your web server via SSH and enter this command:
+
+emacs backup.sh
+
+Substitute the editor of your choice or, if you're more comfortable with the GUI, just login via FTP and create the file that way.
+
+Now paste this code into your backup.sh file, adjusting the file paths to work with your setup:
+
+<pre>
+#!/bin/bash
+DATE=`date +%F`  			
+TARFILE=$DATE.tar 		
+tar -cf $TARFILE /path/to/html_folder
+bzip2 $TARFILE 
+</pre>
+
+The first line is just the standard bash script header, if you're using tsch adjust accordingly. From there we grab the date and then create a tarfile using the date and appending the directory name to the end. Technically this could all be one line, but I split it up for readability.
+
+Then we just create the actual .tar archive and compress it with bzip2 (feel free to use gzip or any other compression tool you like).
+
+So now we have a backup of our flat files, but what about the database? Most shared web hosts have decent database redundancy setups, but I still prefer to have flat file back up. Here's another bash script to backup a PostgreSQL database using <code>pg_dump</code>. Copy this text into a new file named backup_db.sh:
+
+<pre>
+#!/bin/bash
+/path/to/pg_dump -x -D -Uusername -f path/to/`date +%F`.sql
+</pre>
+
+This just calls pg_dump and outputs the database (including insert statements) to a file named today's date.sql in whatever directory you specify. For those using MySQL, <code>mysql_dump</code> can do roughly the same thing. And note that you can dump compressed files using either tool.
+
+One potential gotcha here, invoking pg_dump without entering a password won't work unless your password is stored somewhere. For Postgres that would be the ~/.pgpass file. See the manual for more info on the [http://www.postgresql.org/docs/8.2/interactive/libpq-pgpass.html format and permission of .pgpass].
+
+The last step is to make our shell scripts executable so just make sure to change the permissions so that cron can execute them. In most shells that looks something like this:
+
+<pre>
+chmod u+x filename
+</pre>
+== Automation ==
+
+Now that's all well and good we have a couple of bash scripts that we can invoke from our terminal prompt and backup out files. Bu that who wants to do that? Let's set them up to run automatically once a day.
+
+From the terminal open up your crontab using this command:
+<pre>
+crontab -e
+</pre>
+Now add these lines:
+<pre>
+0 1 * * * path/to/backup.sh > /path/to/log_files/backup.out 2>&1
+30 1 * * * /path/to/backup_db.sh > /path/to/log_files/backup_db.out 2>&1
+</pre>
+
+Hit save and we're done: automated backups. The crontab above will run your backup scripts once a day at 1 AM for flat files script and 1:30 AM for the database script. If there are any problems or the scripts aren't running, check the output in the .out files.
+
+== Fancier Automatic Backups ==
+
+Want to get really fancy and have your home machine automatically login to your server and download those backup files for safe, off site keeping?
+
+It's not to hard to do. The first step is to write the script. Create a new text file wherever you'd like and name it grab_backup.sh or something similar. Now copy and paste this code adjusting the setting to match the location of the backup files we created in the last step.
+
+<pre>
+#!/bin/bash
+DATE=`date +%F` 
+FILE1=$DATE.tar.bz2 
+FILE2=$DATE.sql
+
+# we'll connect with SCP to copy the files
+scp username@example.com:path/to/$FILE1 ~/web/backup/folder
+scp username@example.com:path/to/$FILE2 ~/web/backup/folder
+
+# if you want to delete the backup files from the server just uncomment these lines:
+#ssh username@example.com rm -f path/to/$FILE1
+#ssh username@example.com rm -f path/to/$FILE2
+</pre>
+
+We need to make this script executable so go ahead and chmod it the same way we did above. Give it a test run from the command line and once you enter your remote login password, <code>scp</code> should start downloading the files.
+
+'''Note''': if you get a message like <code>scp: .: not a regular file</code>, a fairly common error, make sure there's no spaces between the colon at the end of the login info and the file you're trying to copy.
+
+=== What to do about the password ===
+
+Astute readers are probably wondering how we're going to automate a script that needs a password before it can do it's job. 
+
+Well, there's actually two way to handle that and both of them involve using SSH public/private key authentication. Essentially we need to create a key pair and then add the public key on our remote server's list of authorized keys. 
+
+But that doesn't entirely sidestep the password problem since SSH keys themselves require a password.
+
+There's two ways a round that, one is a really bad idea, but it works and the other is a bit more complex, but much more secure. 
+
+Let's walk through the first method -- creating a password-less SSH key-pair -- and then we'll talk about why that's a bad idea.
+
+First create an SSH key like so:
+
+<pre>
+ssh-keygen -t rsa
+</pre>
+
+When prompted for a password just hit enter and leave it blank. 
+
+When ssh is done you should see a message like:
+<pre>
+Your identification has been saved in /home/yourusername/.ssh/id_rsa.
+Your public key has been saved in /home/yourusername/.ssh/id_rsa.pub.
+</pre>
+
+We need to add the public key (id_rsa.pub) to our web server. You can either do that using FTP and cut and paste the info into ~/.ssh/authorized_keys, or since your still in the shell, try this line, substituting your login info: 
+
+cat ~/.ssh/id_rsa.pub | ssh username@server.com 'cat >> .ssh/authorized_keys'
+
+That will add the SSH key we just generated to your webserver's list of authorized keys, which means you can now login to your remote server from your home machine without needing to enter a password -- perfect for an automated script.
+
+However it's not so perfect from a security stand point. The way things stand now if an attacker gets ahold of your home machine they have unlimited access to your remote machine as well (because your private key is compromised and there's no password to protect it).
+
+We can limit potential damage somewhat by adding restrictions to what we can do with our remote login. Open up the file .ssh/authorized_keys on your web server and you should see something like:
+
+<pre>
+ssh-dss AAAAB3Nza[..huge string of gibberish..] = user@localhost 
+</pre>
+
+Just before the ssh-dss bit add this:
+
+<pre>
+from="0.0.0.0",command="/home/user/path/to/backup_folder"
+</pre>
+
+Just change the "from" IP Address to the IP of your home network or computer and make sure to change the path to match wherever you're storing the backup files that are being created by our earlier cron script. Also chop off the = user@localhost bit at the end of the line.
+
+That's a little better, but still not good enough for many. In any security scenario there is always a weakness, if you use a password that's the weakness. In our case the private SSH key is the weakness. If you're confident that you can keep your private key secure then what we've done may satisfy you.
+
+If you think the whole set of instructions above is insane (and generally speaking it is), there is a far more secure option. The trick is use ssh-agent, which is complex enough that it warranted its own tutorial. Don't worry, despite being complex in theory, ssh-agent actually isn't all that hard to use, have a read through [our tutorial] and once you're up and running jump back over here and we'll hook up our script.
+
+== Finishing Touches ==
+
+Now you should have a shell script set up and a way to login to your remote server sans password (whether by the insecure method above or the ssh-agent method). The last step in our automation process is create a cron job on our local machine.
+
+Open up a shell windows and repeat the steps above like so:
+
+<pre>
+crontab -e
+</pre>
+Now add these lines:
+<pre>
+0 2 * * * /path/to/grab_backup.sh > /path/to/log_files/grab_backup.out 2>&1
+</pre>
+
+Now we have a cron job on our local machine that will reach out to our remote server and grab a copy of all our backup files and dump them on our local machine. In our case the dump will happen at 2 AM, though you can adjust that to pick a good time for your setup (note that for this to work, obviously, your local machine needs to be running).
+
+That pretty much covers it. You've now got two database and flat-file backups, one local, one remote. Now make sure you back up that local copy on another drive along with the rest of the files. And then back that drive up to one in blast vault that can withstand a nuclear hit and you should be able to keep your website running smoothly throughout the apocalypse.
+\ No newline at end of file