Backups Provided for Hosted Services

Backups Provided for Hosted Services


Virtual Servers hosted in VMware

There are no backup services currently provided for virtual machines hosted in VMWare.  Virtual Hosting customers are responsible for making backups to the contents of their VMs. In case of disaster, the virtual machine host will be recreated to allow the customer to reinstall their OS and restore their data from the backup medium that they choose to use.


Windows/CIFS hosted file services

Please see for information about replication and snapshot capability on the Isilon NAS.


Microsoft SQL Database hosting services

The default backup schedule is:

A Full backup of all databases in a hosted instance runs every Sunday night at 8pm.

A Full backup of the system databases (msdb, master)  for each instance runs at 8pm daily.

An Incremental of each database in an instance runs every night at 8pm.

Log backups for each database in an instance run every 6 hours daily for SQL2005. This has been updated to every 3 hours for SQL2008.

All backups are accomplished through the use of Tivoli Data Protection (TDP) software to back up database content directly into the TSM system.

Retention policy: keep 7 iterations. Keep 3 versions of the file after it's deleted for 120 days.


IIS hosted websites

File storage for IIS hosted websites is provided by the Windows/CIFS services described above, and as such, are backed up nightly to the TSM system at approximately 8pm.

The servers that provide the IIS infrastructure are also backed up to TSM on a nightly schedule at approximately 8pm.

Retention policy: Keep two iterations of an active file. After a file is deleted, keep the last version of the file around for 60 days.


MySQL Database hosting

MySQL instances are backed up using mysqldump at least once a day and then included in regular TSM filesystem backups.


Apache web hosting

Apache document roots are backed up at least once a day and we can restore these upon request. We also encourage customers to use a version control system (VCS) to maintain version history of files.  There are several reasons for this.  These include, but are not limited to:

  • Use of the backup system for version control is expensive: it requires staff time at your end and at ours, and interrupts ongoing work on the backup server.
  • Using a VCS is more convenient for developers; it lets them see history, and the rationale behind various changes.
  • The backup system retains inadequate information to serve as a VCS:  only a few versions, and none of the metadata necessary to understand, for example, who made a change and why.
  • Version control provides native tools for automatically ensuring that e.g. a production promotion is identical to the test version.