How to Migrate Your Data with ZFS Shadow Migration

by Dominic Kay (updated by Cindy Swearingen)
Published October 2012 (updated February 2014)

Data migration is a fundamental building block of an Oracle Solaris 11 adoption strategy. This article describes shadow migration, which is a technology for moving large amounts of data from one file system to another while the data remains online and accessible to users.

A strong case can be made for migrating data to ZFS, particularly because it makes data management in the cloud easy and it provides a large number of no-cost data services, such as encryption, compression, deduplication, snapshots, and remote replication. These services, along with high availability and performance at scale, are strong incentives to consolidate on Oracle Solaris 11.

ZFS is the preferred data storage mechanism in Oracle Solaris 11 and provides far greater reliability and functionality than UFS.

About Shadow Migration

Shadow migration allows you to migrate data from a legacy file system to a ZFS file system while simultaneously allowing access to and modification of the data during the process. You can use shadow migration to migrate a local or remote file system to a local file system, for example:

  • You can migrate any file system that can be mounted directly on the Oracle Solaris 11 host (UFS, ZFS, VxFS, and so on).
  • You can migrate any remote file system that can be set to "read only" and mounted on the Oracle Solaris 11 host by using NFS.

This capability extends to filers such as NetApp and to other operating systems such as AIX, HP-UX, and Linux.

Shadow migration use cases extend beyond moving data to Oracle Solaris 11. For example, shadow migration can be used to do the following when data needs to be transformed:

  • Rewrite existing ZFS data with a data service enabled, such as compression, deduplication, and encryption
  • Move data from a RAIDZ pool to a mirrored pool, because the file system workload is more appropriate for a mirrored pool

The following steps demonstrate shadow migration that you can try out for yourself. These steps migrate data from a UFS file system on an Oracle Solaris 10 system to a ZFS file system on an Oracle Solaris 11 system. Similar steps can be used to migrate data between two local ZFS file systems.

  1. If it is not already installed, install the shadow-migration package on the system where the data is to be migrated, and enable the shadowd service to assist with the migration process. 
    

s11sys# pkg install shadow-migration
s11sys# svcadm enable shadowd
  2. Share the file system to be migrated as a read-only file system. 
    

s10sys# share -F nfs -o ro /ufsfs
s10sys# share
-              /ufsfs   ro   ""
  3. Create a new ZFS file system with the shadow property set to the file system to be migrated.

    s11sys# zfs create -o shadow=nfs://s10sys/ufsfs tank/zfsfs

  4. Check the progress of the migration. 
    

s11sys# shadowstat
                             EST             
                     BYTES   BYTES           ELAPSED
DATASET              XFRD    LEFT    ERRORS  TIME
tank/zfsfs           121M    2.14G          00:18:40
tank/zfsfs           124M    2.18G          00:18:50
tank/zfsfs           124M    2.19G          00:19:00
tank/zfsfs           125M    2.21G          00:19:10
tank/zfsfs           127M    2.23G          00:19:20
.
.
.
  5. When the migration is complete, confirm that the shadow property is set to none. 
    

s11sys# zfs get shadow tank/zfsfs
NAME                PROPERTY  VALUE   SOURCE
tank/zfsfs          shadow    none    -

As noted above, if you had created /tank/zfsfs as encrypted, this would be the preferred method of encrypting existing data. The same is true for compressing existing data.

Testing and Caveats

The migration of production data requires backup and thorough testing before the live migration. In particular, be aware of the following:

  • Consider testing a smaller subset of the data to be migrated to ensure that access control lists (ACLs) and extended attributes are migrated correctly.
  • If clients attempt to modify the "old" data, which is read-only, they are redirected to the new location automatically.
  • Name service entries for authentication—user and group names that control ownership, and so on—need to be migrated as well as the data.
  • Consider a transition stage, when it is possible that both the "old" and the "new" data sets might require backup.
  • Data is migrated from one file system to another on a one-to-one basis. Consolidation from many file systems to fewer should be attended to as a separate stage in the migration process.

Performance

The shadow migration performance depends on the following:

  • The nature of the data (small files are inherently slower than large ones)
  • The access pattern by clients to new data
  • The relative disk configurations of the source and destination systems
  • The throughput and latency of the networking media

A design goal of shadow migration is that clients continue to access the data they require. If the performance of the data transfer is important, you might not want to use shadow migration, because it is designed to be seamless and "invisible," but not particularly fast.

See Also

Eric Schrock describes the motivation and design and also the engineering internals of shadow migration in his blogs. The formal treatment of shadow migration is in the Oracle Solaris Administration: ZFS File Systems manual.

Here are some additional resources:

About the Author

This article was originally written by Dominic Kay and was updated by Cindy Swearingen, Solaris Product Manager.

Revision 1.0, 10/22/2012

Revision 1.1, 02/19/2014
Updated for Oracle Solaris 11.2