Or, What auto maintenance can teach us about website maintenance, Part 2
Last week, we looked at website maintenance in a different light by comparing web site maintenance to auto care and maintenance. We made the case that more companies should treat website maintenance like they treat auto maintenance—it’s just common sense for your car, so why not for your website?
We also said that if business owners can arm themselves with a low-risk, agile application deployment process modeled after modern, scalable, cloud deployment strategies, they can reap benefits in cost savings, maximum performance and give their business the freedom and flexibility to not be at the mercy of any one particular web hosting company or online services vendor.
Get a good insurance policy
In Part 1, we said that regular website maintenance should be more common—as preventative care to prevent disasters—just like performing regular auto maintenance, but we can draw an analogy to auto insurance, too.
In many ways, the idea of being prepared for anything is directly related to an earlier post on risk management as it applies to your web development. Just as having roadside assistance and an up-to-date auto insurance policy can rescue you in a crisis, having all your ducks in a row when it comes to your web application is just as prudent for business owners and their IT departments.
Stranded on the Internet Superhighway
Several years back, I got a frantic call from a client who’s website wouldn’t come up. When I dug into the issue, it turned out the hosting company they had been using (OnSmart — remember them?) had gone out of business, leaving thousands of customers just like my client stranded on the internet superhighway. No support site, no portal, no home page, not even their phone numbers would ring. Would you be prepared for a similar unfortunate situation?
If you have all of the necessary accounts, usernames and passwords handy and the knowledge and the power to move hosts easily — armed with the information in this article — you can be ready for anything, even if it’s as extreme as natural disasters, a power outage or ISP bankruptcy. Though rare, these things can happen, and it is in your company’s best interest to be prepared for anything.
We’re about to tell you everything you need to know in order to be protected against the non-performance of any 3rd parties.
Look to the Cloud
It’s quite common nowadays to spin up application server instances across multiple availability zones, a technique that fans of Amazon Web Services recommend for ultimate high-availability applications. In essence, creating this type of deployment strategy can prevent a lapse in service even when an entire Amazon data center has a hiccup from impacting your business. Traffic just shifts automatically from one data center to another. Amazon has only had issues a couple of times in the past decade, but again, being prepared for anything is becoming the norm. As they say, it’s not if it fails, it’s when.
On the other hand, can we borrow some of the best tools and techniques from scalable cloud deployment to make our website, online application and database platform as flexible as it can be? For instance, couldn’t we copy and tweak our cloud deployment scripts, such as those used with Jenkins, Chef, Puppet or Fabric, to include server backup, transfer, file sync, data replication and migration features? Our source code in a repository providing the means to publish our changes to a production server at the click of a button. So it can’t be that much different to backup and migrate our site to a different ISP, literally at the flip of a switch. Now that developer APIs are becoming more commonplace and expected from our SaaS providers, some DNS providers even make it feasible to automate name server updates as well, for a complete, end-to-end automated hosting migration solution.
Be prepared for anything
Following is a list of the most common accounts you will need to migrate your entire web application at the drop of a hat. It’s not exhaustive list, but most for most common types of web applications, you’ll be required to have access to at least these common accounts at a minimum. If you use WordPress, we’ve included some extra goodies as well toward the end of the list that can also come in handy if you’re in a pickle.
The Top 35 Things You Absolutely Must Have to Move Your Website In 24 Hours or Less
1. The URL,
2. Your Username, and
3. Your password
…to your Domain Name Registry account (aka your Registrar)
I’ve run into a few clients over the years that don’t even remember where they bought their domain name, having clicked on an ad for free hosting, they just signed up for a package deal consisting of domain name registration, DNS management, email and hosting all in one. It pays to use a company that specializes in domain names such as GoDaddy.com.
It is also highly recommended that you review your domain name contacts (there are 4 of them per domain—owner, billing, administrative and technical contacts) to ensure each domain’s contact information, and especially each email address, is up-to-date. We also highly recommended that you consolidate all of your domains to a single account at a single registrar.
4. The URL,
5. Your Username, and
6. Your password,
…to your DNS management account
In most cases, companies simply use the DNS tools provided by their Domain Name Registrar. So these three items may be the same as 1, 2 and 3, but this isn’t always the case, so it’s crucial to know for sure. Both GoDaddy Total DNS, and Network Solutions DNS management tools are top notch.
7. Know whether you’re using your Domain Name Registrar’s default name servers, your DNS provider’s default name servers, or your hosting company’s name servers
Your domain name, where it’s hosted, and how traffic gets there, are three sepearate features required to make a website work—registry, hosting, and DNS, respectively.
So this one can be a bit confusing if you’re not very familiar with DNS management. There’s four distinct, but subtly different options. The first option is that you have your domain name registration, DNS management and hosting all with one company. This used to be more common than it is now, and only a few of the biggest companies are all-in-one anymore. GoDaddy, Network Solutions and 1and1.com are common examples. I’ve never been a big fan of all-in-one solution providers, because all too often, each of the services offered by them are average or poor. You can usually get much better tools and service for a lower price by using individual providers.
If your DNS is managed at your domain name registrar then you’re probably using your registrar’s default name servers, too. This is quite common. However, your DNS can be pointed from your registrar to a 3rd party DNS provider instead. This is often done to get the best service from a specialist that provides only DNS services. DNSMadeEasy and DynDNS are both terrific companies that focus on one thing—offering stellar DNS management tools.
Once you know exactly where your DNS records are updated, you’re ready to record the answer to #7 — you might be using your DNS provider’s default name servers, or you might be sending name resolution downstream to the hosting company where your website files are actually hosted. If you’re not sure, any support tech at your DNS management provider can tell you in a jiffy. In either case, it’s important to know exactly how you have yours set up.
We recommend using your DNS provider’s default name servers and managing DNS on your own for maximum flexibility and speed, because usually registrars aren’t great at hosting and server management, and likewise, hosting companies usually aren’t terrific when it comes to making quick or custom DNS changes.
8. Know what TTLs are for and when to change them
Few web developers even know what DNS TTLs are for and rarely touch the defaults. The concept is so simple though — Time To Live (TTL) values tell all the other DNS servers around the world how many seconds should elapse before they should come back to check back for updates.
If you know you’re going to be making DNS changes in the near future, go ahead and drop your TTLs to one half, one quarter, or even one tenth of the default, typically the number of seconds in a day, or 86400. Realistically, you can set your TTLs to as low 3600 (one hour) or 1800 seconds (half hour). This way when you do make changes, the world will find your new site much, much faster. No need to wait 24 to 48 hours for DNS changes to propagate around the world. TTLs are built-in to all decent DNS tools out there to prevent that lag time. Don’t forget to change your TTLs back to reasonable defaults a day or two after your updates are done.
9. The URL,
10. your username,
11. and your password,
… to your hosting account’s billing control panel.
Your hosting provider will almost certainly email you over and over when your credit card on file is about to expire. Many times, they’ll require to put in more than one possible funding source, too. In any case, there are times when you might fail to receive such email notifications, and it can be a real bummer when your site goes down with a warning about your site being disabled.
Be sure your credit cards and contact info is up-to-date in your billing control panel. Murphy’s law usually indicates that this is most likely to happen when the owner of the credit card is unreachable in the Brazilian rain forest for 2 weeks.
12. The credit limit,
13. expiration date,
… of the billing method on file at your hosting provider.
Clearly if more than one person can spend against this credit card, and they take a client to lavish dinner at a trade show, spending up to within $20 of the maximum credit limit for the card, and tomorrow your $100 hosting auto-bill fails, you could have some serious issues on your hands.
Under this category are additional, related sub-items such as knowing who else can use said credit card, what the spending limits are and what things can cause non-typical or unforeseen expenditures that might encroach upon your credit limit. Examples include videos hosted on your site that go viral and reach your bandwidth quota. See 14 & 15.
14. Your web hosting quotas, and
15. how your common website usage patterns come to reaching these quotas.
Included in your hosting quotas are limits such as hard drive space and bandwidth. There are normal usage for hosting the site to visitors (outbound traffic) and also FTP quotas for uploading. One example of this is if you switch from manual FTP updating to an automated deployment system. It’s not unusual for your developers to get “deployment trigger happy” and send dozens or even hundreds of copies of the site to the server within a short period of time. Another instance is after installing an automated backup tool that creates temp folders and leaves a copy of daily archives on the hard drive, or a botched update that fills up error logs with the same error message repeating thousands of times. MySQL database binary logs can fill up too if you have a replication setup (see 19 – 22).
16. The URL,
17. your username,
18. and your password
… to your web hosting Control Panel
Typically hosting companies use CPanel or Plesk because these tools provide the most features for the lowest cost. Whatever back-office your hosting company provides, you need to know how to get in there to make changes and inspect configurations. This is usually the place where you create FTP accounts, browse the files and folders making up your website content, protect directories and so on. This is also where you typically manage MySQL databases, database usernames and passwords. (See 19 – 22).
19. The Hostname,
20. the username,
21. the password,
22. and the port number
… to connect to your database.
Hand in hand with these four items are the configuration file within your website application where these four items are stored. This config provides the mechanism for your web application to connect to the database. If you use WordPress, these are stored in your wp-config.php file.
23. How to create databases, DB users and passwords, and grant privileges
CPanel and Plesk make this pretty quick and easy, using a point and click interface. Normally you create a database, you create a db username and password, and then assign that user to the database. It takes a minute with 3 steps. If you connect to your MySQL server on the command line, you’ll use the GRANT statement. Review how to do this from your CPanel, but also keep the link to the GRANT syntax handy if you need to manually manage database access.
mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON %DATABASENAME%.* TO '%USERNAME%'@'%HOSTNAME%' IDENTIFIED BY '%PASSWORD%';
24. How to backup your MySQL Database
A couple of scenarios can come into play here. In most cases for typical websites, your database is small enough and your site usage patterns are such that you can use your CPanel tools to backup the whole database, and it’s easily done with a few clicks. One additional nice feature of using CPanel is that you can export, gzip and save a local copy all with one click.
If you use the command line, you’ll want to review the mysqldump command. Here’s the basics:
mysqldump -u %USER% -p -h %IP_ADDRESS% --result-file=/tmp/outputfile.sql %DATABASENAME%
For maximum flexibility, work with your hosting company support team or web developer to create a simple backup script that runs daily. Ideally, get these backups sent off-site. S3 storage from Amazon AWS is a fantastic, durable, cost-effective method of storing off-site backups.
25. The hostname,
26. your Username,
27. your password
28. and port number
… for updating web files via FTP (or SFTP).
In most cases, the hostname is the same as your website domain name, but in some cases it may be the fully-qualified DNS name provided to you by the hosting company for the server your site is hosted on. This is often called the “temporary URL” and comes in the automated email that you get when you first sign up for hosting. In some cases, your host might move your site to a difference server without even notifying you, which means you might not even know your temp URL. Good to know if your DNS breaks and you need to backup your site in a hurry. FTP port is commonly 21, and SFTP port might be 22 (or if using FTP-S or Secure FTP, it might be port 443). If you’re not 100% sure, check with your hosting company support staff. In some cases, you may also need an SSH key or to know how to edit the firewall settings to allow file upload access.
29. Know your stack (LAMP? WAMP? WIMP? Other?)
30. Web Server Software,
31. and version
32. Server Side Programming Language
33. and version.
34. Using any custom extensions or libraries?
Your web stack refers to the platform and framework your site uses. Sometimes people also include with that, all the files relating thereto that make up your web application.
You might be running on a Windows server or a Linux server. You might be using Apache, Lightspeed or another web server solution. You might need special libraries or modules installed. You might need specific versions of all of this software.
The files making up your website can consist of lots of different files and formats in dozens of nested folders. You might be using .NET files with .asp or .aspx extensions, PHP files (.php) or Java (.jsp). Apache and PHP are the most common. If you’re using a framework such as WordPress, Drupal, Joomla or Magento, be sure to also take note of the version number of the framework.
Backing up your website content can be a little trickier, because it can consist of hundreds, thousands or even tens or even hundreds of thousands of files, as well as user-generated uploaded assets such as images, PDF files, and more.
For starters, backup or sync your web files via FTP at least once a month. A decent option here is to routinely use an FTP sync program, such as WS FTP Pro or Transmit. By using FTP Sync, the software figures out what files have been changed or added, so download size (bandwidth) is minimized, and it’s much faster.
For the command-line savvy reader, take a look at the rsync program. Again, your hosting company and web developer should be able to help you with a reliably off-site sync solution.
35. Where are your backups? You’ve got backups, right?
Knowing when your backups run, how to obtain them, how do extract them, inspect them for accuracy, and use them to replicate your site are all vital steps if you want an emergency procedure for moving your website. Almost every website hosting company can provide you with backups, and some ensure you this is a support function, your backups are safe and made regularly, and you need not worry about it. But what if your hosting company gets hit by a tornado or earthquake? What if they go out of business?
Companies like Carbonite and Mozy advertise all the time about the prudence of you personally keeping an offsite backup, right? That’s just for your personal photos and music collection. Do you have offsite backups being made daily for your website files so vital to your business? Without offsite, automated backups going to a 3rd party provider in an automated fashion — tested and checked regularly — you could be in for an extremely rude awakening if anything goes awry at your host.
If you use WordPress, Backup Buddy is a great option covering all-important #35. It has a built-in admin panel that lets you enter your Amazon S3 bucket, dropbox, box or other 3rd party storage provider account info, and it backs up your site content and database automatically every day at the time you specify. Nothing could be simpler, and few WordPress plugins are as valuable for disaster recovery. Other alternatives include BlogVault, VaultPress, and WordPress Backup to Dropbox. Using one of these automated WP backup options is strongly encouraged.
Summary
- Registrar Account Info
- Company, URL, account number, username & password
- DNS Account Info
- Company, URL, account number, username & password
- Hosting Account Info (Billing CPanel, Hosting CPanel)
- Company, URL, account number, username & password
- Database Credentials
- Hostname, Username, Password, Port Number
- Stack Info
- LAMP (Linux Apache MySQL PHP) or Windows-based
- Web Server being used
- Scripting Language (PHP, ASP, JSP, etc)
- Backup Strategy
- Frequency, offsite location, checked
Get the template
To make it even easier to keep track of these crucial items, make a copy of our Google Spreadsheet and just fill in the blanks. Note: You need a copy of this spreadsheet for each domain name that has something running on it!
Conclusion
Well, that’s it. If you’re ever in a dire situation, we hope these 35 crucial items really come in handy and save you from the pain, frustration and agony that can come from a prolonged website outage. Take control today — and even if you have all of these items at your fingertips, double check and update them regularly.
If you want to really be sure that your backup and migration strategy is ready for prime time, work with your IT team to actually simulate an outage of one or more of these services. That’s the best way to know with certainty that your team and your process can recover quickly and you’re ready for anything.
