Case against ZFS

The question about disabling services essentially depends on the services themselves:

• Are they actively writing to the file system you plan to move ?
• Are they storing persistent data you want to keep.

In any case, sending a ZFS file system might take a long time. It is possible to minimize service unavailability by keeping them online most of the time that way:

• create a snapshot

• send that snapshot the way previously suggested but while keeping all services active

• when the fs is received on the other pool, disable the critical services bounds to that file system. Make sure the new file system on the destination pool is not modified as changes will be discarded later anyway.

• create a second snapshot (e.g. snapshot2)

• send that second snapshot incrementally, that will be much quicker that the previous transfer. e.g.:

  zfs send -i rpool/filesystem@snapshot rpool/filesystem@snapshot2 \
      | zfs receive -F destinationpool/filesystem
  

• when done, move the filesystem mount point from the old dataset to the new one. e.g.:

  zfs set mountpoint=/application/directory.old rpool/filesystem
  zfs set mountpoint=/application/directory destination/filesystem
  

  You need to make sure no process is bound to /application/directory (e.g.: accessing files or having it as its current directory) to achieve that.

• re-enable the service(s) and you are done.

I feel like we answer variants of this question often on Server Fault.

You can do all of this with NexentaStor's commercial offering, using either asynchronous replication (ZFS Send/Receive over ssh/netcat or rsync) or synchronous replication (with another commercial plugin).

There are vendors who package and certify these setups with custom hardware. The easiest example is the Pogo Linux Storage Director series.

I personally own a Sun x4540 that used to run OpenSolaris, but is now running Nexenta Enterprise. The Sun hardware is a little sketchy after only two years though, and I've seen found more value in building my own. I'm currently using HP hardware to build single storage nodes, but I can expand to external storage with LSI enclosures. People have documented SuperMicro-based solutions as well. In the HP systems, I'm replacing the Smart Array controllers with LSI 6GB SAS controllers; 9211-8i for internal use, and 9200 for external. You would need to do something similar in the Dell case.