You have a pool created and ready, but you have a need to either migrate this pool to another SoftNAS instance, for example to break up the load, or you have a need to shift data (at the pool level) from one pool to another, such as when changing the underlying EBS volume to improve throughput or even migrate from EBS to S3 or vice versa.

Purpose: 

This document will highlight the different methods available to migrate a pool data and offer the pros and cons of each method at a high level. Then we will show you how these tasks are performed.

Migrating a Pool within the same instance

The following are the two primary methods for migrating a pool within the same instance:

• EBS Volume Snapshots
  If using EBS volume Snapshots to migrate data from one pool to another, the benefits are no overhead and a simpler process. However, this method can incur more downtime, and you can only migrate between EBS volume types (no migrations to or from S3 disks).
  
  
• ZFS Send and Receive
  Migrating using ZFS send and receive will result in lower downtime, can be performed to and from S3 disks, as well as between EBS volume types. The main drawback of this methodology is that it will incur significant I/O overhead. For this reason, it is recommended to perform this action outside of business hours (or peak business hours if operating 24-7). You will also need to make sure that your license capacity permits such method.

NOTE: For large amount of data ZFS Send and Receive might not be efficient and will cause a huge performance degradation, so you may consider migrating to another instance then importing the resulted pool to the current instance 

Migrating a Pool to another SoftNAS instance

The following methods can be used if migrating a pool to another SoftNAS ® Instance: 

If in the same Availability Zone: 

• Zpool Export (and import from the secondary instance UI
  This is the fastest method, incurs little to no overhead, and does not incur AWS charges, as you are still using the same EBS disks.It is just a matter of detaching then attaching the same disks to another instance in the same Availability Zone. You will need to migrate the services configuration files.
• Migrate using SnapReplicate™
  SnapReplicate™ is the easiest method and results in less downtime, and the ability to transfer your pool data to a different EBS volume types, or to and from S3. It results in I/O overhead, so should be performed outside of peak business hours. It will take care of the configuration files.

If migrating between different Availability Zones:

• EBS Volume Snapshots
• Using SnapReplicate™

EBS Volume Snapshots Method (migrating pools on the same instance or different instance).

      Note: If you are in a RAID array setup it is highly recommended to use our Backup & Restore applet from UI to backup your pool(s) which will make it easier for future pool restoration

1. Stop any write operations on that pool during the snapshot operations.
   
   
2. Create a snapshot for each volume participating in the pool from AWS console based on AWS documentation:
   
   http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
   
   
3. Use the snapshot(s) to create a new volume(s) of the desired volume type [they must be in the same Availability Zone of the instance you are planning to attach them to]. 
   
   http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html
   
   
4. Attach the volume(s) to the instance. But make sure that the mappings of the new volumes ( /dev/sdx ) are the same as the original volumes.
   
   
5. If it is on the same instance you will need to export the old pool first using command line

      zpool export pool-name

1. From the UI go to Storage Pools>Import> and choose the pools and import the volumes.
   
   
   
2. If it is a different instance, Perform final housekeeping tasks, such as modifying or moving the required sharing config files, ( “/etc/exports /etc/target/saveconfig.json /etc/samba/smb.conf”) starting the needed services, and directing your clients or applications to use the IP address of the new share.

ZFS send & receive (Migrating pools on the same instance)

1. From the SoftNAS UI create the desired pool with the desired backend volumes. 
   
   https://www.softnas.com/docs/softnas/v3/html/create_a_storage_pool.html
2. SSH into your instance. 
   
   1. For guidance on how to connect to your Linux instance, click here.
3. Create the first pool snapshot using the below command. This step will not require downtime. 
   
   zfs snapshot –r source-pool@Full



4. Send this snapshot to the destination pool, using the below command.  This step will cause some performance degradation while transferring the data, so it is recommended to be performed outside of peak business hours.
   
   zfs send -R source-pool@Full | zfs receive -s -F destination-pool
   
   
5. Turn off write activity on the source volume, by bringing any applications using NFS, CIFS, and/or iSCSI offline, or from SoftNAS itself by using the following commands:
   
   service monit stop
/var/www/softnas/scripts/stop-nasservices.sh
   
   
6. Take the final snapshot.
   
   zfs snapshot –r source-pool@Final
   
   
7. Incrementally send the volume using the final snapshot. This will send only the data modified between the time of the full snapshot and the final snapshot, incurring very little overhead.
   
   zfs send -R -i source-pool@Full source-pool@Final | zfs receive destination-pool


8. Now you can export source-pool and remove its disks,then rename the destination-pool as the source pools as below:

   zpool export source-pool

   zpool import source-pool destination-pool

9. Now you can bring back your clients/applications up and remount your volumes, OR start SoftNAS storage services again, if they were stopped in step 5.
   
   service monit start
/var/www/softnas/scripts/start-nasservices.sh

The pool is now migrated, you can return to the SoftNAS user interface and check the results.

Notes:

In case of sending the full snapshot failed for whatever reason, you can resume it again using the below command:

zfs send  -t  $(zfs get -H -o value receive_resume_token destination-pool)  | zfs receive  -s  destination-pool

ZFS export (and import from a new SoftNAS® Instance)

1. SSH into your instance. 
   
   1. For guidance on how to connect to your Linux instance, click here..
2. From CLI run the following command:
   
   zpool export POOL-NAME 
   
   
3. From the AWS console,  detach the EBS volumes that the pool is based on.
   
   
4. From AWS console, attach the EBS volumes to the new instance using their exact mappings i.e (/dev/sdx). As mapping the wrong volume name to the wrong /dev/sdx may lead to data corruption during pool import 
   
   
5. Log into the new SoftNAS instance using your browser. In the new instance's UI,  go to Storage Pools, and click  Import, then choose the pool and import it.
   
   
6. Perform final housekeeping tasks, such as modifying or moving the required sharing config files, ( “/etc/exports /etc/target/saveconfig.json /etc/samba/smb.conf”) starting the needed services, and directing your clients or applications to use the IP address of the new share.
   
   
   

SnapReplicate™ (Migrating to a new SoftNAS® Instance)

SnapReplicate™ is the easiest way to migrate your pool to a new instance, whether in a different availability zone, or in the same one. With SnapReplicate, you don't have to worry about cleaning up config files or services. 

To use SnapReplicate™, follow the instructions in our documentation: 

• SnapReplicate™