Web Site Backing up

Danger lurks on the web, and a website is never totally immune to infiltration by the ‘bad guys’. Be they actual people or malicious automated code that roams the web, looking for  an ‘open door’, to wriggle their way into your code. There are numerous reasons why this can happen, things such as weak and/or old passwords, old dynamic CMS installations, outdated security settings on the hosting companies, even an attack on a different site on the same shared server, etc, etc.

Don’t believe it can’t happen to you!

Having a reliable backup system equals peace-of-mind, however, that is only half the battle, we also need to know how to restore from a backup – and have practiced the procedure before it has to be done under duress!

So before anything happens, we need to have several protocols in place to minimize the potential damage, and the time needed to get back online again.

AT ALL TIMES:

• Stay current with any updates that are offered for software, CMS systems, Themes, plugins etc. Not keeping these updated is an invitation for the hackers, as they know what was fixed, and will target that in older versions.
• Use super-secure passwords and change them periodically. Avoid a brute-force entry.
• Keep local copies of key files – especially if a CMS installation was done on the host server with SimpleScripts. Customized themes should also saved locally.
• Use a good hosting company that is up-to-date on security precautions
• For a CMS website, give members only those permissions they actually need to do their job, no more than that.
• For any database-driven site, periodically force members to re-login by resetting ‘secret keys’. (in WP)
• Use the HTACCESS file to control sensitive pages
• Make sure your own computer is clean and malware-free
• Do not login to sensitive websites using a public unsecured WIFI.
• Establish a Google Webmasters account, and ‘verify’ your site.

Establish Backing up system: Where, How, When, What to backup.

1. Where? On a cloud, on a different server, on your own machine? Saving backups in multiple locations is ideal – if cumbersome.
2. How? Automated system, or manually? Email to self?
3. When? How often is the site content updated? How much will you lose if you don’t have a recent backup? How many versions of the backup to keep?
4. What? The entire site, or just a database? Or specific folders that are updated more often than the basic content?

Where:
There are many Cloud locations, some are free up-to-a-point, some not quite free.

• Amazon S3
• Dropbox
• Sugarsync
• Google Storage
• Microsoft Azure
• Rackspace

A CMS backup file can be saved on the same server hosting the website, but that is pointless if the entire server goes down, or you get locked out. Save it on one’s own computer is ok, as long as that computer has it’s own reliable backup system.

How:
For a CMS system, automated back-up plugins are available. Open Source or commercial. Research whether the options offered are what you need before committing to a system. For static websites, keep the files on your local machine up-to-date. (If you built the website on your local machine, and then FTP’d the files to the server, the local will always be current.) If manually, make sure it’s done on a schedule.
If your site was built with an online web site builder offered by a hosting company, you need to research what kind of backups they provide of your customized site.

When:
Depending on how often a site is updated, plan multiple backups as needed. Once a week, or everyday? Keep several versions, as you need to restore from a backup that was made before a virus struck. Depending on how often you visit your site, it could be days before you know!

What:
The “what” applies to database driven, and/or CMS websites. There are several parts that make up the site, so these may need to be backed up separately. A database is backup separately, and the content files (which may not change often) can be their own less-frequent backup. On a WordPress installation, there can be separate backups for the core PHP files, and the uploaded content. (such as photos.)

DISASTER STRIKES!
You open your webpage, and something bad appears:

• A nasty red & black warning page, with the cruel notification that your website is “dangerous” and “infected”. You know you are innocent, so what happened?
• A 404 error, “Page not found”
• A “can’t connect to database” error or any other unexpected warnings.

Depending on what appears, your actions are determined by the error messages. If Google and the browser puts up the virus warning page, here are some steps to take ASAP:

1. Login to your hosting root folder (by FTP or on the hosting site), and look at the date stamps for files. Anything that was updated without your knowledge is suspect. Rename the suspect file with a .txt extension, and replace with a clean version from your own computer. Then download the bad file to check it’s code.
2. For a CMS site, try to login to the admin area in the browser. Even if the warning window appears, it still offers a link to the site – which (hopefully) is now clean as you removed the rouge file.
3. Update the CMS installation. Even if it is up-to-date, run the update again.This may overwrite files that were hacked.
4. Login to your hosting account and change all passwords, including the FTP password. (This can take several hours to take effect – reason #1 is done first.)

Caveat: this information reflects only the tip of the security iceberg, others with experience and/or knowledge are invited to add their comments by posting a reply.

At this point the site may be back to normal, however, some CMS installations have hundreds of files, and it can be impossible to check them all for date changes. The best solution would be to delete everything on the server, and reinstall a fresh version of the CSM system The database also needs to be checked by the hosting company – if the DB was hacked, they need to take action.

If the entire contents of the root folder are deleted, everything will need to be re-installed. For a static HTML site, the clean files can be uploaded again. For a CMS website, a fresh installation of the CMS system will need to be done, and the  database connections will need to be entered. Only after the core files are back in place, as well as any plugin that created the backup, can a restoration be started.

Once the site is back to normal, the “virus attack” warning may still show. At this point Google has to be invited to spider the site again, to give it a clean bill of health. This needs to be done in the Google Webmaster account.

Links:

http://www.google.com/webmasters/tools
http://www.noupe.com/how-tos/wordpress-security-tips-and-hacks.html
http://www.stopbadware.org/home/security#removing
http://codex.wordpress.org/Hardening_WordPress
http://docs.joomla.org/Security
http://drupal.org/documentation/is-drupal-secure
http://pluginbuddy.com/purchase/backupbuddy/
http://drupal.org/node/22281
http://extensions.joomla.org/extensions/access-a-security/site-security/backup