The first hard drive (c1t0d0) failed a few days ago, and Sun shipped out a replacement today. I have replaced the drives and the mirrors are currently resyncing.

The replacement procedure is as follows:

• Install new drive in spare drive slot, then run devfsadm to make Solaris recognize the new drive.

• Run dd if=/dev/rdsk/c#t#d#s2 of=/dev/rdsk/c#t#d#s2 and cancel shortly thereafter to copy the partition table to the new drive (input is remaining good drive, output is new drive).

• Remove the new drive from the spare drive slot.

• For each mirror on the mirror set, run metadetach -f MIRROR SUBMIRROR followed by metaclear SUBMIRROR. This removes the failed drive from the mirror set.

• If there are any state database replicas on the failed drive, run metadb -d c#t#d#s# to remove them.

• Remove the failed drive.

• Insert the new drive.

• Run devfsadm to rebuild the devices.

• Run metadevadm -u c#t#d# to tell SVM about the new drive information.

• Recreate the state database replicas on the new drive with metadb -a -c # c#t#d#s#

• For each mirror, run metainit SUBMIRROR 1 1 c#t#d#s# for the new drive, followed by metattach MIRROR SUBMIRROR to attach the mirror and begin resyncing.

The other two 500GB Xserve RAID volumes were added together to make another 1TB Veritas volume for groups directory storage; we are in the process of migrating this data from PAX to RAHU.

All home directories have finally been transferred off of PAX and onto RAHU.

With this transition, we applied filesystem quotas to all users, basing the quotas on either the group base quota or the amount of space in use (whichever was greater). These quotas were imported into the Self Service Quota tool. At this point filesystem quotas are live and functional just as they are on KE for e-mail.

With the change, we have also changed the drive mapping in the ECS domain for H: from \\PAX\Homes to \\RAHU\Homes. Although not required for data access, this makes it so that the disk size reported over SMB is the quota size. Home directories are still accessible through PAX in all the ways that they used to be.

We have also added a drive mapping for Z: which connects to \\RAHU\Backup, which is a username based share that connects to the home directory snapshot. This gives users access to the snapshot directly. Snapshots are made shortly before midnight Sunday through Friday nights.

The new file server, RAHU, with the Xserve RAID storage array, is in production, and we are beginning to migrate user acounts to it.

The new home directory storage area is using a 1 TB set on the Xserve RAID. The remaining space on the RAID will be used for future growth, group storage, or possibly other uses. While we do not have quotas enabled yet, we will be doing this after the end of the semester when we have the self-service quota system installed and ready for use.

In the near term, users will not see any operational differences between the current configuration and RAHU. Migration of accounts will be completely transparent, and PAX will continue to be the access point for all home directories. User restores from the snapshot system will be allowed starting in August — in time for Fall semester.

We have installed and are currently testing a new storage server, RAHU.

RAHU (Estonian) is a new SunFire V240 with an attached Apple Xserve RAID storage system. The Xserve RAID gives us a total of 2 terabytes of usable storage. By attaching it to a Sun server, we are able to use standard Solaris tools for operating system management and the VERITAS volume manager and filesystem for storage management.

We will be migrating user accounts from PAX to RAHU over the remainder of the semester. Prior to summer, we will be notifying people with high disk usage of their usage and our plans to enable quotas. Over the summer we will turn on quotas.

The VERITAS products will give us an extremely high performance filesystem and the ability to easily create point-in-time snapshots for backup purposes. We will be creating snapshots on a nightly basis for quick restores and backing up these snapshots on a weekly basis. Snapshots will have a maximum lifetime of two weeks. It is unclear at this point whether we will make these snapshots directly available to users to perform their own file restores, and if so, how we woudl do that.