By James Dunn ||
I didn’t sleep very well last night. No, it wasn’t because of a barking dog, a crying child, or my WordPress website had been hacked. We had a very rough storm roll through – complete with lightning, thunder, a tornado warning, and more rain that we’ve had in a single night in quite a while.
While laying awake watching the storm, what I usually do so my family can sleep uninterrupted, I got to thinking about where all of our important papers were and how easily we could locate them in the event of a natural disaster. Fortunately, we have a pretty good disaster recovery plan in place. We have two fire safes located in our house – one in our Master Bedroom and one in the basement. Great, I knew where our important papers were.
Then, my mind wandered over to my WordPress websites. I’m currently moving all of my websites to a new, more powerful server, so it’s the perfect time to update my disaster recovery plan for my WordPress websites. I keep a record of all the important information I need to access or move both in an electronic document AND a printed document.
Since I am changing servers, I will need to update certain items on this document, so it’s the perfect time to confirm all the information on the document. I thought I’d share this with you as well.
What Information Do I Need To Record
Your Server Control Panel Login Information
Whether you use cPanel, Plesk, ServerCP, or some other control panel, you have to login to access the control panel. Be sure to record not only the login ID and password, but the URL for your login access. Sometimes, this may include a port, so don’t forget to include that information as well.
Your Domain Registrar Login Information
If you are moving from one server to another, you will probably need to change your nameservers. To do that, you will need to login to your Domain Registrar’s control panel to make those changes, so be sure to record your login ID, your password, and the URL you use to login.
Your DNS Login Information
If you host your own nameservers, you will not need this information. Also, if you use your registrar’s nameservers, you will not need this information. However, after the recent GoDaddy debacle, I would recommend against this. If you use an external DNS service, then you should record your login ID, password, and the URL you use to login.
Your Server IP Address
If you host your own nameservers, this will not be important for any of your configuration, but you should still have it recorded. If you use your registrar’s nameservers or another nameserver, then you will need the server IP address to record in your “A” record.
Your NameServer Information
You should have at least two nameservers – sometimes more. Typically, the protocol would be ns1.domain.com, ns2.domain.com, ns3.domain.com, etc. Some nameservers do not use ns1. but instead use simply ns. Regardless, of the format or how many you have, be sure to record all of them as they are important.
Your MySQL Database Information
You will need this for two different purposes.
#1 In case you ever need to reenter it into your WordPress setup. You will need the database name, the database username, and the database password. Remember when you initially set up your website? If not, set up a test website to see what information is needed to confirm this.
#2 If you use a program to directly access your MySQL database tables. Personally, I use Navicat because I find that it is so much easier to use than PhpMyAdmin. Regardless, of which one you use, you will need to record your database name, database username, and your database password. With Navicat, I need to know the IP address of my server. You did record that earlier didn’t you? If not, now is the time to do it.
WordPress Login Information
Be sure to record your main WordPress admin login information – both username and password. You didn’t use “Admin” as your admin login ID did you? If you did, now is your chance to change that. Install UserName Changer from the WordPress repository and make that change NOW, before you take another step.
Next, record your FTP login information. This will include your hostname (domain.com), your username, and password. Also, be sure to note whether you use standard FTP or if you operate through SSH (SFTP) access. Finally, if you use any type of encryption instead of the plain FTP, be sure to make note of that as well.
WordPress Authentication Unique Keys and Salts
Remember that long string of numbers that you generated at WordPress’s Secret Key Service? Be sure to revisit your wp-config.php file and record that string as well.
WordPress Table Prefix
You did give your WordPress table a prefix other than “wp_” didn’t you? If so, be sure to record the table prefix here. If you didn’t, now is the time to make that change. Install the plugin – Change Table Prefix – from the WordPress Repository and make that change now. Record the new WordPress table prefix so you don’t forget it.
If you are not hosting your own nameservers or if you are using another mail service, you should record your MX Record settings. This would be important to continue to send and receive email should your move your website or you suffer a catastrophe.
Mail Server Information
If you host your own mail server – such as Squirrel Mail or some other service – then record your online mail server access information. This should include your login ID and password, as well as the URL that you visit to access your email. If you have to designate a specific port to access your mailbox, be sure to record it as well.
If you forward your email to a Google or GMail account like I do, then you should also record your access information for that account.
Will I Ever Use This Information
Even if you are not planning to move your hosting to another server and you never have a catastrophic failure, you should maintain all this information so you can sleep better at night.
I work with a local radio station that covers high school football on Friday nights and streams their station online 24/7. One Friday afternoon, I got a call about 2:30PM saying that their website was inaccessible. After about 30 minutes of research, we discovered their their nameserver was down for their actual domain name (domainname.fm); however, their published domain was a simple redirect.
Since the domain registrar was unsure how long it would take to solve their nameserver issue, our quick solution was to remove the redirect, point the name servers to our server, and mirror their content on our server. Another potential solution was to just change the redirect to a sandbox domain on our server. Regardless, this quickly became a non-issue because they didn’t know their login information at their domain registrar and could not retrieve it by game time.
If this information had been readily available, we could have had them back up in under an hour with the redirect change and possibly even a couple of hours with a DNS change. Instead, the live stream was down for that game. For them, they lost listenership for that evening and potentially many weeks to come – all because they didn’t maintain some simple records.
I created a simple document with blanks for all this information. I fill in the information, save the document, print a hard copy and file it, and sleep well secure in the knowledge that my WordPress Disaster Recovery Plan is in place and kept up to date. We should all prepare our own plan and file it away in a safe place. The storm could come tonight.
I’d love to hear about your own WordPress Disaster Recovery Plan. Leave your comments below.
Also published at wpmu.org