JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle® ZFS Storage Appliance Administration Guide
Oracle Technology Network
Print View
search filter icon
search icon

Document Information

Using This Documentation

Chapter 1 Oracle ZFS Storage Appliance Overview

Chapter 2 Status

Chapter 3 Initial Configuration

Chapter 4 Network Configuration

Chapter 5 Storage Configuration

Chapter 6 Storage Area Network Configuration

Chapter 7 User Configuration

Chapter 8 Setting ZFSSA Preferences

Chapter 9 Alert Configuration

Chapter 10 Cluster Configuration

Chapter 11 ZFSSA Services

Chapter 12 Shares, Projects, and Schema

Chapter 13 Replication

Chapter 14 Shadow Migration

Data Migration

Traditional Data Migration

Migration via Synchronization

Migration via External Interposition

Shadow Migration

Shadow migration behavior

Restrictions on Shadow Source

Shadow File System Semantics During Migration

Identity and ACL Migration

Shadow Migration Management

Creating a Shadow Filesystem

Managing Background Migration

Handling Migration Errors

Monitoring Migration Progress

Canceling Migration

Snapshots of Shadow File Systems

Backing Up Shadow File Systems

Replicating Shadow File Systems

Shadow Migration Analytics

Shadow Migration Requests

Shadow Migration Bytes

Shadow migration operations

Migrating Local File Systems

Shadow Migration Tasks

Testing Potential Shadow Migration

Migrating Data from an Active NFS Server

Chapter 15 CLI Scripting

Chapter 16 Maintenance Workflows

Chapter 17 Integration


Migrating Data from an Active NFS Server

  1. Schedule downtime during which clients can be quiesced and reconfigured to point to a new server.
  2. Configure the source so that the ZFSSA has root access to the share. This typically involves adding an NFS host-based exception, or setting the anonymous user mapping (the latter having more significant security implications).
  3. Configure the source to be read-only. This step is technically optional, but it is much easier to guarantee compliance if it's impossible for misconfigured clients to write to the source while migration is in progress.
  4. Create a share on the local filesystem with the shadow attribute set to 'nfs://<host>/<path>' in the CLI or just '<host>/<path>' in the BUI (with the protocol selected as 'NFS').
  5. Reconfigure clients to point at the local share on the SS7000.

    At this point shadow migration should be running in the background, and client requests should be serviced as necessary. You can observe the progress as described above. Multiple shares can be created during a single scheduled downtime through scripting the CLI.