SSCC Policies
It is strictly against University policy and potentially a violation of state and/or federal law for any SSCC resources to be used for commercial or political activity, or for the purpose of harassing anyone. Anyone caught violating this rule will have their account terminated. Each SSCC member accepts responsibility for all the computing done using their SSCC account.
The protection of SSCC resources depends heavily on each member’s careful handling of their account, since any account can serve as an entry point for theft, damage, or unauthorized use of SSCC resources. SSCC members must protect the confidentiality of their accounts, including their passwords, and are expected to exercise reasonable care to ensure that others cannot use their accounts. Sharing accounts is not permitted. Each SSCC member agreed to this policy when they activated their account and failure to abide by it may result in the termination of their account.
Do not try to use more cores than a server actually has, either by running a single job that uses many cores or by running many jobs. (See the Guide to Research Computing at the SSCC for the number of cores in each server.) Trying to use more cores than the server has will force the cores to switch between tasks repeatedly, slowing down the server for everyone, including yourself.
SSCC staff regularly monitor the load on each server. If we notice jobs that are in violation of this policy, we will contact the job owner, but let the job finish as long as it is not causing problems for other users. However, if the job disrupts usage for others, it may be terminated without prior notice.
Other limits are enforced automatically, such as limits on memory usage. These limits are described in the Guide to Research Computing at the SSCC or Using Winsat.
Slurm ensures each user gets their fair share of the cluster’s resources by making the jobs of heavy users a lower priority. It is not a violation of SSCC policies to submit very large numbers of jobs to the Slurm cluster–that’s what it is for.
All computers are subject to regular attempts to gain unauthorized access, and the first line of defense is strong passwords.
Your password must:
- be different from previous SSCC passwords.
- be at least 8 characters (15 for Silo users).
- include at least 3 of the following: uppercase letter, lowercase letter, digit, special character.
Passwords must not:
- be used on other sites. However, you may use your UW NetID password as your SSCC password.
- contain a name, username, or email address.
- be shared with anyone. SSCC staff will never ask you for your password.
- not consist of a single word. Consider combining multiple words (a passphrase).
We recommend using a password manager. All passwords must comply with the University’s IT Password Standard.
This document describes how SSCC protects the integrity of the data it stores.
ResearchDrive, Restricted ResearchDrive, and SMPH’s space in Silo (/smph, mapped as S:) are stored and backed up by DoIT. Their backup policies are described at https://kb.wisc.edu/96394, but the most important part is the following:
- Data stored on ResearchDrive is automatically backed up daily and replicated offsite to an encrypted storage cluster for additional data protection.
- Snapshots are taken once a day and kept for 14 days and weekly snapshots are kept for five weeks
- These data protection features allow you to recover accidentally deleted files or folders within the past month.
What SSCC Backs Up
On SSCC’s Windows file system, home directories (mapped as the U: drive) and project directories (mapped as the X: drive) are considered permanent storage space and are backed up by SSCC staff. SSCC staff do not back up any files stored locally on members’ computers or files stored in the Y: drive (temp30days).
On SSCC’s Linux file systems (both the general file system and the Silo file system), /home and /project directories are considered permanent storage space and are backed up by SSCC staff. Personal and departmental websites are also backed up. /temp30days and /tmp are considered temporary storage and are not backed up.
Frequency of Backups
SSCC backs up data once a day at 6:00PM. At that time, all new or changed files are copied into the backup system.
Test restores are carried out at least once every 90 days to ensure backed up data are usable.
Retention of Backups
Modern backup systems have complex methods for determining how long each copy of a file is kept. Rather than describing those methods in full, we will describe what would be available in the most common scenarios. If you need more information about retention of backups, contact the Help Desk and we’ll be happy to discuss it at whatever level of detail you need.
What if I accidentally delete a file? Assuming the file was backed up once (i.e. it was in a backed up location during at least one backup) the most recent version of the file will be retained for one year from the time it was deleted.
What if I need an older version of a file? If the most recent version of a file becomes unusable due to user or program error, the number of older versions available depends on how recently the file was changed. If the file was changed in the last 30 days, all backed up versions are retained for 30 days. After 30 days, one version is kept per week (the latest version in that week). After 60 days, one version is kept per month (the latest version out of all the weekly versions in that month) for the past year.
What if disaster strikes? The most recent version of every file currently in a backed up directory is stored in two physical locations: the SSCC data center in the Sewell Social Sciences Building and a DoIT Datacenter in Fitchburg. If a disaster, whether technical or physical, were to destroy some or all of the data in SSCC’s file system, we would be able to restore it to its state as of the most recent backup. If the SSCC data center itself were destroyed, we would restore the data from the copy in Fitchburg (presumably after buying new equipment).
Excluding Sensitive Data from Backups
SSCC members are sometimes required by the data providers to agree to not make backup copies of the data they are given. If members have data of this type, they need to notify SSCC’s Help Desk that they do not want these data included in SSCC’s backups.
Note that all backups are encrypted and unusable outside our backup system.
Use of the SSCC web server is governed by University computing policies, including accessibility requirements. Departments and other agents of the University are generally responsible for enforcing these policies rather than the SSCC, unless a website violates Acceptable Use policies.
In addition, a member’s use of the web server must not require an inordinate amount of server resources or interfere with other uses of the server. This will be monitored by SSCC staff in the course of normal operations and will be enforced by SSCC staff as needed.
SSCC members are regularly subjected to “phishing” attacks, where criminals try to trick members into revealing their SSCC usernames, passwords, or other personal information by sending email claiming to come from the SSCC.
All legitimate email from the SSCC, including automated messages, will contain the personal name of an SSCC staff member. Visit our SSCC Staff page for a list of SSCC staff members. Legitimate SSCC email will not come from “the ssc.wisc.edu team” or a similarly generic term. However, it would be easy for phishers to look up the names of SSCC staff. Messages claiming to be from the SSCC that do not contain the name of an SSCC member can be immediately disregarded as phishing, but messages should not be trusted just because they contain the name of an SSCC staff member.