Web Server Backups Standard

Purpose

This standard defines the practices for system and site backups for all web servers administered by Web Services.

Brief Description

Having backups can turn a potential disaster into a nuisance. Web Services maintains backups for all Development and Production web servers, and some QA servers. Despite having system backups, it is advantageous for customers to maintain their own off-line copies in a secure location to guard against catastrophic backup failures and to speed the process of restoring a file deleted by mistake. Customers may request that files, directories, or even entire sites be restored from backups provided a request is made before the desired data ages out of the backup system.

Details

Backing up data is a critical task in any computer environment. Files may be lost or damaged by:

  • hardware failure
  • software error
  • user error

All Web Services machines are backed up as follows:

  • Systems are backed up by the platform teams on a nightly basis.
  • Backups are nominally retained for 14 days.
  • Files deleted or altered the same day they are created will not have been backed up.
  • Production and Development systems are always backed up. QA systems may be backed up on a system-by-system basis. If QA is not being backed up, we can either restore a copy of a file from Production or a copy from Development, as requested.

Developer Backups

Despite the existence of nightly system backups, it is recommended that developers maintain a copy of their site on departmental storage, perhaps under a revision control system, or in a content management system (such as Cascade). A duplicate copy on the development web server is not adequate and is discouraged because:

  • It wastes space
  • In the event of a failure, the duplicate copy is also likely to be destroyed if it is on the web server
  • It may be accidentally deployed to production quite easily, possibly getting your old site indexed by search engines and discovered

Backups created by WordPress plugins that offer backups as a feature are also inadequate and wasteful. Such features should not be used except in rare circumstances where you need to self-export data. After the backup is copied elsewhere, it should be deleted.

Restore Requests

Restore requests should be submitted promptly (within 1 week) to Web Services and must contain:

  • The full path to the file(s) to be restored, including the server name. In lieu of the server name, the URL and tier (dev, qa, prod) may suffice.
  • The date and time of the last known good copy of the file(s).
  • If you would like us to replace the existing files with the restored files or place the restored files in an alternate location.
  • For faster restores, whether a copy from another tier may be used instead (i.e., could we copy a file from Production to QA or Development).
  • If this is a production restore that is resulting in an outage, please also review the Reporting Outages section of our Support Standard for additional steps you may need to take.

Our goal is to restore a file on a production system within four hours and a non-production system within two business days.

Please note: Database backups (other than WordPress) are not handled by Web Services. If you need a database restored, please contact the Database Administration team for assistance.