Data Storage Guide

From Storrs HPC Wiki
Revision as of 13:08, 8 August 2017 by Lwm14001 (talk | contribs) (Generating Backups)
Jump to: navigation, search

The Storrs HPC cluster has a number of data storage options to meet various needs. There is a high-speed scratch file system, which allows parallel file writing from all compute nodes. All users also get a persistent home directory, and groups of users can request private shared folders. Once data is no longer needed for computation, it should be transferred off of the cluster to a permanent data storage location. To meet this need, the university offers a data archival service that features over three petabytes of capacity. Data transfer to permanent locations should be done via the web-based Globus service.

HPC Storage (short term)

The Storrs HPC cluster has a number of local high performance data storage options available for use during job execution and for the short term storage of job results. None of the cluster storage options listed below should be considered permanent, and should not be used for long term archival of data. Please see the next section below for permanent data storage options that offer greater resiliency.

Name Path Size Relative Performance Persistence Backed up? Purpose
Scratch /scratch 1PB shared Fastest None, deleted after 30 days No Fast parallel storage for use during computation
Node-local /work 40GB Fast None, deleted after 5 days No Fast storage local to each compute node, globally accessible from /misc/cnXX
Home ~ 50GB Slow Yes Twice per week Personal storage, available on every node
Group /shared By request Slow Yes Twice per week Short term group storage for collaborative work

Notes

  • Data deletion inside the scratch folder is based on directory modification time. You will get 3 warnings by email before deletion.
  • Certain directories are only mounted on demand by autofs. These directories are: /home, /shared, and /misc/cnXX. If you try to use shell commands like ls on these directories they may fail. They are only mounted when an attempt is made to access a file under the directory, or using cd to enter the directory structure.
  • You can recover files on your own from our backed up directories using snapshots within 2 weeks.
  • You can check on your home directory quota.
  • There are read-only datasets available at /scratch/shareddata. More information is available on this page.

Permanent Data Storage (long term)

Once data is no longer needed for computation, it should be transferred off of the cluster to a permanent data storage location. To meet this need, the university offers a data archival service that features over three petabytes of capacity. Data transfer to permanent locations should be done via the web-based Globus service.

Name Path Size Relative Performance Resiliency Purpose
Archival cloud storage /archive 3PB shared Low Data is distributed across three datacenters between the Storrs and Farmington campuses This storage is best for permanent archival of data without frequent access. NOTE: Users must request access to this resource by either creating a ticket or emailing hpc@uconn.edu.
UITS Research Storage Use smbclient to transfer files By request to UITS Moderate Data is replicated between two datacenters on the Storrs campus This storage is best used for long term data storage requiring good performance, such as data that will be accessed frequently for post-analysis.
Departmental/individual storage Use smbclient to transfer files or SCP utilities - - - Some departments and/or individual researchers have their own local network storage options. These can be accessed using SMB Client or SCP utilities.

Generating Backups

The backup process can be automated, please contact us if you need help automating any of the following options.

There are several ways to generate and maintain backups, and depending on what you'd like to use the backups for, you'll prefer some options over the others. Three of the main factors you have to weigh are time to: generate an archive, transfer said archive to permanent storage, and restore from this archive. You must also consider whether you'd only like the most recent backup of the current state, which is what you'd be doing to make sure data on /scratch is resistant to file system failure. Or, if you'd like older versions to exist, so that if you obliterate some of your results you can just restore from a backup. We keep backups like this for the system configuration directories, and your home directories.

Disk Image Style Backups

While you will not be creating an actual disk image, the idea here is to generate an exact copy of the state of all files within a directory at a certain time.

tar -czf backup_name.tar.gz directory_to_make_backup_of/

The main issue with generating backups this way is you have to regenerate the .tar.gz file every time which involves re-indexing and copying of every file. While other methods will re-index they likely will not have to copy all the files over. Though you are moving extra copies to archive with this technique, it can be useful if cluster usage is low, since you can generate the tar ball in an sbatch script. And, as the tar ball is compressed, it will have an easier time travelling through the low bandwidth pipe to /archive/.

You should move the archive to /archive/ for storage, and copy it back onto scratch when you'd like to unpack it. You can extract the archive with:

tar -xvf backup_name.tar.gz

This will extract the archive into the current working directory overwriting files in the directory with their versions in the backup. Check the tar man page for more options.

Rsync Backups

The goal of an rsync based backup is to get the appearance of a mirrored file system, ie the source and destination directories look the same.

rsync -avhu source_dir/ desination_dir/

Will only update files at destination which are older then their source counterparts, meaning that even though your first run of rsync will be as slow/slower than the above tar command, future updates with rsync will be faster.

Restoring from an rsync back up is simple you just swap the source and destination arguments.

Data Transfers using Globus Connect

You can make large data transfers with a service called Globus Connect. This allows you to transfer large data sets between the Storrs HPC and your workstation, or any computer set up as a Globus endpoint. The Globus system is optimized for long-distance data transfers and is particularly useful for sharing data with your collaborators at other institutions.