To backup WordPress (and most of similar systems, scripts etc) all you need is to get a copy of information from database and copy of all files. Files often are in one directory, information is usually in one database.

The first thing you need to do is determine which database is being used with your website. After you determine that, you’ll need to make a backup by entering the following command:

1

$ mysqldump -p -u username -h hostname.com name_of_database > dump.sql

Don’t forget to check what is there in dump.sql after that and ensure the database contains the proper information for the actual website your backing up. This dump will usually happen at the root of your hosting plans server.

To create the backup:

1

$ cp -R directory copy_of_directory

NOTE:
“-R” is to copy recursively, “directory” is the name of folder you are copying, “copy_of_directory” is name of created copy

After this command has been successfully ran. You now have a copy of the data files of the website.

To restore the website from the backup:

1
2
3

$ mysql -p -u username -h hostname.com name_of_database < dump.sql
$ rm -R directory
$ cp -R copy_of_directory directory

The first command, will restore the database.
The second recursively deletes directory with files.
The third restores files.

You need to delete the directory, otherwise files from backup will overwrite actual files (this is ok) but will not delete any files that was in actual copy but was not in the backup (this is not ok). You usually don’t need to delete and recreate the database because dump contains commands to drop affected tables before loading information.

If you want to create a “zipped” archive and not worry about overwriting directories:

1

$ tar -c directory -j -f backup_of_directory.tbz "-c directory" sets target, "-j"

means packing with bzip2 to make file smaller and “-f backup_of_directory.tbz” sets name of backup.

If you want to remove old files and unpack backup.

1
2

$ rm -R directory
$ tar -x -j -f backup_of_directory.tbz

“-x” means “extract”, “-j” means “unpack bzip2-packed data” “-f backup_of_directory.tbz” sets name of archive to unpack.

Of course, you will need to move your freshly made archive to a safe place in case you need to retrieve it later:

1

$ mv backup.tbz ~/some/safe/place/backup.tbz

In order to specify your own ErrorDocuments, you need to be slightly familiar with the server returned error codes. You do not need to specify error pages for all of these, in fact you shouldn’t. An ErrorDocument for code 200 would cause an infinite loop, whenever a page was found…this would not be good. The following is a list of error codes for your reference:

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
36
37
38
39
40
41
42

Successful Client Requests
200 	OK
201 	Created
202 	Accepted
203 	Non-Authorative Information
204 	No Content
205 	Reset Content
206 	Partial Content
 
Client Request Redirected
300 	Multiple Choices
301 	Moved Permanently
302 	Moved Temporarily
303 	See Other
304 	Not Modified
305 	Use Proxy
 
Client Request Errors
400 	Bad Request
401 	Authorization Required
402 	Payment Required (not used yet)
403 	Forbidden
404 	Not Found
405 	Method Not Allowed
406 	Not Acceptable (encoding)
407 	Proxy Authentication Required 	 
408 	Request Timed Out
409 	Conflicting Request
410 	Gone
411 	Content Length Required
412 	Precondition Failed
413 	Request Entity Too Long
414 	Request URI Too Long
415 	Unsupported Media Type
 
Server Errors
500 	Internal Server Error
501 	Not Implemented
502 	Bad Gateway 	 
503 	Service Unavailable 	 
504 	Gateway Timeout 	 
505 	HTTP Version Not Supported

You will probably want to create an error document for codes 404 and 500, at the least 404 since this would give you a chance to handle requests for pages not found. 500 would help you out with internal server errors in any scripts you have running. You may also want to consider ErrorDocuments for 401 - Authorization Required (as in when somebody tries to enter a protected area of your site without the proper credentials), 403 - Forbidden (as in when a file with permissions not allowing it to be accessed by the user is requested) and 400 - Bad Request, which is one of those generic kind of errors that people get to by doing some weird stuff with your URL or scripts.

In order to specify your own customized error documents, you need to add the following command, on one line, within your htaccess file:

1
2
3

ErrorDocument code /directory/filename.ext
    or
ErrorDocument 404 /errors/notfound.html

This would cause any error code resulting in 404 to be forward to yoursite.com/errors/notfound.html

Likewise with:

1

ErrorDocument 500 /errors/internalerror.html

You can name the pages anything you want, and you can place the error pages anywhere you want within your site, so long as they are web-accessible (through a URL). The initial slash in the directory location represents the root directory of your site, that being where your default page for your first-level domain is located. I typically prefer to keep them in a separate directory for maintenance purposes and in order to better control spiders indexing them through a ROBOTS.TXT file, but it is entirely up to you.

If you were to use an error document handler for each of the error codes I mentioned, the htaccess file would look like the following (note each command is on its own line):

1
2
3
4
5

ErrorDocument 400 /errors/badrequest.html
ErrorDocument 401 /errors/authreqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/notfound.html
ErrorDocument 500 /errors/serverr.html

You can specify a full URL rather than a virtual URL in the ErrorDocument string (http://yoursite.com/errors/notfound.html vs. /errors/notfound.html). But this is not the preferred method by the server’s happiness standards.

You can also specify HTML, believe it or not!

1

ErrorDocument 401 "<body bgcolor=#ffffff><h1>You have to actually <b>BE</b> a <a href="#">member</A> to view  this page, Colonel!

While this is possible, it’s not recommended since you can have so much more control over the error pages when used in conjunction with xSSI, CGI or both. Also note that the ErrorDocument starts with a ” just before the HTML starts, but does not end with one…it shouldn’t end with one and if you do use that option, keep it that way. And again, that should all be on one line, no naughty word wrapping!

Next, we are moving on to password protection, that last frontier before we delve into into the true capabilities of htaccess. If you are familiar with setting up your own password protected directories via htaccess, you may feel like skipping ahead.

SSH or Secure Shell is a network protocol that allows data to be exchanged using a secure channel between two networked devices. It’s used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for Telnet and other insecure remote shells, which send information, notably passwords, in plain text, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet.

In plain English? SSH allows you to give and receive data securely over the internet to other computers or servers. A majority of servers are Unix. This is actually one world where windows has not (and I can comfortably say, will never) taken over. Because Mac OS X nowadays is based on Darwin and chunks of existing open source software from a large number of sources like BSD, GNU, Mach, and even Linux. There is an option to use something called “Terminal” that will allow you to SSH into a server without having to add any third party software.

I’ll briefly discuss the items needed to log into a remote server using SSH.

First thing is you want to make sure you have SSH enabled on your server. If you contact your hosts help desk. You’ll need to pry the following information out of them:

• If SSH is enabled on your server. If not, ask that they enable it
• What domain you will use
• What port you will use
• What your username/password will be. *Most likely this username and password will be the same as yout FTP credentials

Once you get this information, you’ll need an SSH client to get into your server.
If you are on a Mac, you can use Terminal which is already installed on your computer and located at: Applications>Utilities>Terminal.

NOTE:
If you use a distribution of Linux or Unix. You can follow these directions as well because the simularities are almost identical. There may be small differences, but chances are if your using Linux, you’re not reading this article =]

When you launch Terminal, you’ll see a window that looks like this:

NOTE ABOUT HOSTNAMES:
Most likely your hosting provider will provide you only with the Hostname or IP to login to your sever via SSH. It should look something like this:

name.domain.com

or this

77.124.52.169

Both of these things do the same thing. They point Terminal at a specific server on the internet.

After opening Terminal. You will see two lines of text. The first line show previous login information; the second line shows the details of your computer followed by a a dollar sign “$”

NOTE:
The dollar sign doesn’t mean that your Mac is expensive (even though they are). It means Terminal is ready to receive commands from you. From this point on, I will refer to the dollar sign as the “prompt”.

First thing you want to enter after the prompt is:

ssh

This will tell Terminal you want to SSH into a specific location on the internet or network.

IMPORTANT:
You don’t want to press enter after entering this. You still have some more things to do

Then you need to enter your username. Followed by an “@” symbol, then the Hostname or IP. So the line of text you entered should look something like this:

1
2
3

ssh username@doin.hostname.com
or
ssh username@77.124.52.169

If your host provide you with a “port” number. Enter that in the same line of text like so:

1

ssh username@doin.hostname.com -p5527

After you’ve entered all the credentials, press the return key.

Now you will be asked to provide the password for the account:

Type in your username and press enter. Then you will be asked to enter that your password:

NOTE:
Even though you don’t see the cursor moving. When you press a key, it is registered by Terminal. This is a security feature that is not specific to Terminal, but ALL SSH clients.

After you successfully enter your password. You have officially SSH’d into a server!

Now it’s time to learn a few simple Linux commands and you will be able to do things that would take you hours in FTP in literally under a minute.

Stay tuned..

SSH or Secure Shell is a network protocol that allows data to be exchanged using a secure channel between two networked devices. It’s used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for Telnet and other insecure remote shells, which send information, notably passwords, in plain text, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet.

In plain English? SSH allows you to give and receive data securely over the internet to other computers or servers. A majority of servers are Unix. This is actually one world where windows has not (and I can comfortably say, will never) taken over.

I’ll briefly discuss the items needed to log into a remote server using SSH.

First thing is you want to make sure you have SSH enabled on your server. If you contact your hosts help desk. You’ll need to pry the following information out of them:

• If SSH is enabled on your server. If not, ask that they enable it
• What domain you will use
• What port you will use
• What your username/password will be. *Most likely this username and password will be the same as yout FTP credentials

Once you get this information, you’ll need an SSH client to get into your server.

To SSH into a server, you need a third party application like PuTTY is your best bet and it’s free!

The following examples will use PuTTY which is the standard SSH tool in the windows world.

Once you launch PuTTY, You’ll see the following window. This window will look intense, but I assure you you only need a very small amount of what PuTTY does. This is gonna be cake!

Most likely your hosting provider will provide you only with the Hostname or IP to login to your sever via SSH. It should look something like this:

name.domain.com

or this

77.124.52.169

Both of these things do the same thing. They point PuTTY at a specific server on the internet.

Enter this information in the “Hostname or IP” field.

If they provide you with a “port” number. Enter that in the port field to the right of the Hostname field. If they did not provide you a port number, just leave the port to the default setting of “22″

After these fields have been properly entered, press the, “Open” button on the bottom.

NOTE:
You may notice that you didn’t have to enter a username or password. Don’t worry, you’ll have to enter that once you join the SSH session.

After you press the open button. The PuTTY window will close and something that looks like the following:

Type in your username and press enter. Then you will be asked to enter that your password:

NOTE:
Even though you don’t see the cursor moving. When you press a key, it is registered by PuTTY. This is just a security feature that is not specific to PuTTY, but ALL SSH clients.

After you successfully enter your password. You have officially SSH’d into a server!

Now it’s time to learn a few simple Linux commands and you will be able to do things that would take you hours in FTP in literally under a minute.

Stay tuned..