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.
- If it is not already installed, install the
shadow-migrationpackage on the system where the data is to be migrated, and enable the
shadowdservice to assist with the migration process.
s11sys# pkg install shadow-migration s11sys# svcadm enable shadowd
- Share the file system to be migrated as a read-only file system.
s10sys# share -F nfs -o ro /ufsfs s10sys# share - /ufsfs ro ""
- Create a new ZFS file system with the
shadowproperty set to the file system to be migrated.
s11sys# zfs create -o shadow=nfs://s10sys/ufsfs tank/zfsfs
- 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 . . .
- When the migration is complete, confirm that the
shadowproperty is set to
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.
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.
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:
- Download Oracle Solaris 11
- Access Oracle Solaris 11 product documentation
- Access all Oracle Solaris 11 how-to articles
- Learn more with Oracle Solaris 11 training and support
- See the official Oracle Solaris blog
- Check out The Observatory blog for Oracle Solaris tips and tricks
- Follow Oracle Solaris on Facebook and Twitter
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