Server Uptime, Reboots and When to Log Out
There are two classes of desktop machines in our environment.
A) One is supported fully by Physics Computer Services (PCS) and typically is made up of administrative staff, emeritus and G1/G2 students's computers as well as the public machines in the library and G1/G2 commons areas. These machines log directly into our domain and are dependent on our file and login servers for full functionality.
B) The other is user-supported machines, typicaly faculty, research and post-docs. These machines typically store their data locally and do not require our services to be online to function (but, consequently, are not generally backed up). A few may make use of our file servers to mount home directories (HETG machines, for instance), but are supported by a local group administrator.
This document is directed mostly towards type A, but does touch upon issues of interest to type B (especially those dependent upon our file or login servers). Where e-mail is concerned, this document is relevant to all Physics users.
Weekends
In general, it's a good idea to log out and sleep or shut down your machine over weekends or during periods where you'll be away. This is especially true, and strongly suggested, for those of type A. FAS and PCS are more likely to make network or server modifications over weekends and reboots or interruptions may affect any machines logged into our environment. Users of type B should make up their own mind but, if asked, our opinion would be to at least log out, if not shut down, over weekends.
Weekdays
While we encourage everyone to log out each day, it is not absolutely critical. Sometimes one is in the middle of something and wnats to pick up again where they left off. That said, however, if one decides to stayt logged in always save whatever you are working on. A network outage overnight could ruin your day when you return to find that document gone because it was never saved.
Server Reboots
Occasionally updates must be applied to our servers or network outages occur and we need to reboot one or more servers. Apart from unexpected outages, which we obviously cannot control, our planned reboots will occur on Sundays evenings. Please bear this in mind if you are running an experiment which requires one or more of our services (file server, e-mail, etc.) and let us know if you are at a critical point. If a Sunday reboot requirement arises, we can work with you to lesses or negate the impact. Otherwise, such reboots are short and usually go un-noticed (unless you are logged in and the reboot affects your workstation).
Our current mandate does not require us to be a 24/7 environment, but we do our best to meet that model anyway. Your understanding when maintenance needs require a short downtime is greatloy appreciated.
Disaster Recovery Information
All data for each staff user and the documents they generate or maintain is stored on a redundant RAID file server which resides in our server room. Workstations are interchangeable and no data is stored on local desktop machines. Server room key entry is limited to computer support staff and building facilities personnel. The server room resides within the director's/chair's office area which is locked after hours and key access is limited to residing staff, computing support and building facilities personnel. (i.e.- During business hours, one limited-distribution key is required to enter the server room, after hours two limited-distribution keys are required.)
Backups of the Physics file servers is performed nightly and a monthly full tape backup is stored off-site. In the event of minor data deletion, a restore of missing data can be performed within 2 - 6 hours. In the event of catastrophic loss of data, a restore from on-site backups can be performed within 12 - 24 hours. In the event of a catastrophic loss of hardware, a full restore can be performed within 12 - 48 hours of procuring new hardware. In the event of full facilities loss, a full restore can be performed from the last off-site backup within 12 - 48 hours of procuring new hardware.
