Our backups are primarily for disaster recovery - in the event of a significant failure, software, hardware or facility, we expect to restore a reasonably recent (at best, it would be from the previous night's backup) copy of the data so that the University can resume normal operations as quickly as possible. We are not, at this time, preserving backups of the file server (Causeway, the Netware cluster) or the email server for archival purposes. A files or email message would have to exist at the time a backup ran for it to be included in a backup. Currently, if someone deletes a departmental folder during the day, the best we can do is restore it to its state from the previous night. That day's work would be lost since we do not have the software and hardware needed to make either snapshot or continuous backups during the day.
If there has not been any loss of hardware, we would expect to be able to bring a major system online in a day. However, even though our backups are reliable and we do restore data frequently enough to act as a general test, restoring backups takes time. If we had to rebuild several large data volumes, it could take as long as a few days to get things running again, even without additional complications. We can now test complete volume restores periodically, and every month we select different volumes or data to test our ability to restore from backups.
If we have suffered hardware losses, we would need sufficient hardware on-site to hold the data as we restore it. Our new secondary array can hold the data, but may not be able to support the full range of campus services for performance reasons. Service levels would be far lower while we waited for a new parimary SAN disk array. Depending on the type of damage our facilities, fiber optic lines used to connect buildings to the network could be damaged as well, cutting off services to buildings or areas.