Nov 14

In October we finalized our approach to our home storage and backup needs and ordered the equipment to address the first phase. Now that we received the equipment, we embarked on the first stage of setting up our new home storage and backup environment. This post covers our initial experience.

Equipment Recap

The following equipment has been installed:

Hardware Setup

Setting up the hardware and performing the initial configuration has been very straightforward. I followed the TS-109 and MX-1 product instructions to install one of the HDDs in the TS-109 and the remaining two HDDs in the eSATA HDD enclosures.

I attached one of the external HDDs to the eSATA port of the TS-109 and configured the TS-109 to format it using the ext3 filesystem and to manage it using Q-RAID 1, QNAP’s proprietary means of mirroring the content of the internal HDD to the external HDD.

Here’s the main screen of the TS-109 NAS Server:

The main admin screen:

And the external eSATA drive setup:

Defining New Shares

I used the TS-109′s web interface to create two new shares:

  • documents
  • pictures

documents holds all of our shared documents.

pictures holds all of our shared pictures.

I also defined several groups and users to enable only selected people, my wife and I, to perform read, write and delete operations on these shares.

  • family
  • family-secure

family includes my wife and I and our son whereas family-secure includes only my wife and I. family-secure has write capability for all of the shares. A predefined Public share is writeable by everyone – including guests.

You can easily apply quotas to any share, but we have not yet played with that feature.

List of shares currently defined:

Access Protocol

We’re currently using SMB/CIFS as the file sharing protocol. However, since we’re running a mix of Linux and Mac clients, we’ll be experimenting with NFS-based access down the road.

Consolidating Shared Documents

I’ve moved all of our shared documents from various PCs and a shared external USB HDD to the NAS server. While doing so, I was able to monitor the external HDD on the NAS server and see that Q-RAID 1 feature appeared to be working properly. I noticed that when transferring large amounts files to the NAS server, there’s a lag time for the external HDD to catch up. (I read about this lag in a forum thread while researching the product). Since we’re not running a data center, we don’t really need real-time mirroring in a true RAID-1 sense.

Music Consolidation

During the migration of our shared files to the NAS server, we’re taking the opportunity to clean house by reripping and reencoding our CD collection and merging the resulting files with various MP3 files that we’ve acquired over the years. Why? I wanted to ensure that all of our files were at least at 192Kbps and have up-to-date MP3 tags.

Since we have a lot of duplicate files during this consolidation process, our HDD usage is up to 27% of our 500 GB capacity! I expect the consumption to go back down to perhaps 15% once we’re finished with our photo and music clean up efforts. Since there’s so much space taken up by the photos and music files and we don’t expect to dramatically increase the size of our music archive, I’m comfortable with our 500 GB capacity.

Photo Management

We’re hosting the iPhoto library on the “pictures” share. iPhoto has a setting that allows you to specify the location of the iPhoto library. We simply moved the entire iPhoto library from my wife’s Mac laptop to the NAS server and configured iPhoto to use the new location.

It’s not clear whether we’ll be able to easily use other photo management apps to manage the photos. Worst case is that we’ll standardize on using iPhoto to download photos from our cameras and to manage them on an on going basis.

iTunes Server

Since the predefined Qmultimedia share is used by the iTunes server feature of the TS-109, we’re housing all of our MP3 files under this share. It was a pleasant surprise to see that the iTunes server feature works fine out of the box. We’re able to start iTunes on one of our Macs and immediately see our NAS server named “network-disk” under the “Shared” area of the iTunes application. Clicking on “network-disk” causes iTunes to load song information from the iTunes server (the NAS server) into the iTunes window. Then you can select whatever songs you’d like to stream from the iTunes server to the Mac.

Fortunately, the iTunes server feature does not require any special folder organization under the Qmultimedia share. You just dump audio files into the share at any level of your custom folder layout and the iTunes server simply serves up all of the files and embedded song information to iTunes clients.

iTunes Client

We have yet to try using iTunes to manage the music collection as hosted on the NAS server. I’d prefer to not have iTunes change the layout of the music files under the Qmultimedia share, but whether it has to do so requires further investigation.

NFS Access

We successfully experimented with NFS access to the network shares. We were annoyed that some of the case insensitivity of the Windows file sharing was getting in the way of our attempts to clean up our audio file names. Simple operations such as “mv Inxs inxs” would fail because we were using SMB/CIFS as the network file access approach. Once we switched over to NFS, these Windows style limitations went away.

  1. On Ubuntu, we had to install the nfs-common package and its dependencies to enable NFS client support. (For you nerds out there, the portmapper is installed and started as a dependency of the nfs-common package).
  2. On the NAS server, we had to enable the NFS service and enable access via NFS to the shares of interest.
  3. On the Ubuntu client, we:
    1. Created a mount point: % mkdir -p /home/ckamps/mount/documents
    2. Mounted the share of interest: %sudo mount -t nfs network-disk:/documents

Another benefit of using NFS from a Linux client is that access performance has improved dramatically. When using SMB, it could take a minute or more to copy a typical album of MP3 audio files from our laptop to the network share. With NFS, the copy times have been reduced by 1/2 to 30 seconds or so on average.

We plan on trying NFS from our Mac OS clients as well. The steps outlined in this how to article look like a promising way of defining a persistent connection to the NFS share.

Standby Mode

I believe our NAS server is entering the power saving standby mode because client accesses will be delayed momentarily if the NAS server has not been accessed for an extended period of time. However, I need to check the NAS server’s activity lights to verify that it is going into standby.

Although I had read that standby mode did not work properly with certain HDDs, the HDD type I purchased was reputed to work properly in this respect.

Redeploying External USB HDD to Dish Network PVR

Since we no longer need to use an existing external 200 GB USB HDD for shared files, we redeployed the USB HDD to our Dish Network vip622 satellite receiver/PVR. Unfortunately, Dish charges a one-time fee of $39 dollars to activate this feature. : (

The other downside of this feature is that the PVR doesn’t automatically treat the added storage as just a bunch of disks (JBOD). You have to manually migrate recorded shows from the internal HDD to the external HDD. You can manually schedule multiple shows for migration and carry out the migration in the background while you watch live TV or other recorded shows, but I’d rather have the DVR just treat the total capacity as one big disk! Oh well, I might ask for a refund…

Swapping External HDDs

Once I get all of our shared files organized on the NAS server, I’ll be ready to disconnect the external HDD and replace it with the currently unused external HDD. Then we’ll move the initial external HDD off-site for a month or so before swapping the two external HDDs again as part of our monthly off-site backup and storage regime. I’m interested to see how long it will take for the NAS server to:

  • sync content from the internal HDD to a fresh external HDD
  • and sync content from the internal HDD to an already used external HDD

I’ve read that you must first click on “Eject now…” button in the TS-109 admin console before disconnecting the external HDD. Doing so will ensure that any in-flight mirroring transactions will complete properly prior to disconnecting the external HDD.

Openness of the TS-109

Since we intend to add several applications to the TS-109, we’ve been impressed by the openness of the TS-109 device. In preparation for adding several apps, it’s pretty useful to be able to ssh into the system and poke around its internals. Fundamentally, it’s just an ARM processor-based device running Linux.

Here’s a screenshot of an ssh access to the NAS server. Note the uname – a output and filesystems. The HDx_DATA filesystems represent the user storage portion of the internal and external HDDs.

Next Steps

As we address the following next steps, we’ll publish new blog entries:

  • Do the First Off-site HDD Swap
    • Once we’ve organized all of our shared documents and media files, we’ll perform the first exchange of the external HDDs such that we can move one to our off-site storage location.
    • As part of the first exchange of the external HDDs, we’ll perform some basic tests to ensure that recovery from one of the external HDDs works properly.
  • Migrate thermd Home Monitoring App to NAS Server
    • Our intent is to decommission our current Linux PC server once we migrate the only remaining app, a home monitoring utility, to the NAS server.
    • We’ll need to install Perl and the Perl modules required by the thermd monitoring utility on the TS-109.
    • Thus far, it looks promising based on this forum post. Basically, there’s already a repository of ipkg format packages for Linux on ARM processors. This repo contains Perl and many of the Perl modules required by thermd. Although the ImageMagick library is also in the package repository, we haven’t seen its companion Perl module. We might have to obtain that module separately.
  • Tackle Incremental Backup Approach
    • Incremental backup of recently modified files from the NAS server to our web hosting storage will ensure that we have backups of files that are modified between the monthly off-site backups.
    • Given the open nature of the Linux-based TS-109 NAS server, this task should be pretty easy to accomplish by running a script on the NAS server itself. Our goal is to avoid depending on any of the client PCs or a home server system to carry out the incremental backups.
    • We’ll probably create a script to:
      • recognize which files have changed since the last incremental backup
      • add these files to an archive
      • encrypt and compress the archive
      • use secure ftp to transfer the archive to our web hosting storage area
    • Here’s an example of a scripting approach that we might leverage.

4 Responses to “Initial NAS Setup Experience”

  1. Jason says:

    Hi,
    I found your blog entry on your NAS experience. Did you have an issue running iPhoto off the NAS? I was about to take the same plunge but on the Apple forum boards I see lots of people saying that iPhoto requires the HDD to be formatted as macos extended journeled, which most NASs can only support NTFS and HFS+. Just wanted to see if you had any quirks with moving iPhoto.

    Thanks!
    Jason

    • ckamps says:

      Hi Jason,

      Although we’re not heavy iTunes users, we have added 10K+ tracks from our NAS server into iTunes over NFS without experiencing any issues. But in this case we keep the iTunes metadata on the Mac OS X client rather than on the NAS server. So maybe that’s why we haven’t seen any issues. I’ve considered putting the metadata on the NAS server with the hope that multiple users can share the metadata, but the several times I researched this approach led to dead ends. Historically, iTunes didn’t seem to be designed with NAS servers and shared usage in mind. Perhaps things have changed recently.

      Thanks,
      Chris

  2. Mike says:

    Jason’s question was referring to iPhoto, not iTunes. I’d be interested in knowing that answer as well if you could address it. Thanks!

    • ckamps says:

      Duh on my part. Since we don’t use iPhoto, I haven’t looked into what might be feasible with respect to sharing a common iPhoto DB hosted on the NAS server.

Leave a Reply

preload preload preload