Symptoms

 As the need to have backups on production data becomes more and more relevant, SoftNAS customers are often tasked with having an exact replica of their production data to a second environment for DR purposes. This will ensure business continuity in-terms of unforeseen circumstances.

Purpose

This KB will explore the different DR setups available to configure on SoftNAS without hurting overall system performance. There are currently 2 short term DR solutions (that we will explore shortly in great detail). However, SoftNAS is also committed to integrate a long term solution that will be part of the product in a future release.

Resolution

Zfs Send/Recv Solution:

Script located HERE(and linked again in below sections)

This Solution uses the native ZFS send and receive method that replication uses to send data over to a DR environment. It can be run as a stand alone command, scheduled as a cron job, or run as a NiFi processor to replicate a volume to another softnas which is faster than rsync and consumes less resources.

NOTE: The Script needs to be run from Source

This script takes two arguments; -v <volname> -r <remote_ip>

...

1. Next, please ensure that  a pool of the same name exist at the DR node, (volume not required).

   
   
2. Next, download a copy of the dr_copy.sh script from HERE if you have not done so yet.
   
3. Once the script in step #2 above has been downloaded, there are many ways in which you can be able to transfer it to SoftNAS. For the purpose of this KB, an SFTP client (Filza) was used.
   
   
4. Now we are ready to run the script that was downloaded on step #2 either as a standalone, via cron or NiFi processor if you have Platinum License. The script requires to be run with Volume name as first argument and remote IP as second argument.
   
   # Example 

   './dr_copy.sh -v pool0/vol0 -r 10.100.1.5'

   
   

5. If the keys are added, then you should get output like below when you run your command:

...

        */30 * * * *  /bin/bash ~/dr_copy.sh -v pool1/vol1 -r 10.10.1.199

Controlled Rsync Solution: 

As the heading implies, This type of rsync setup will ensure that once an rsync job is kicked off the process must run completely before another process is spawned. Since rsync is a resource intensive service, this approach  will minimize the performance impact it usually poses on production systems during heavy read/write operations by minimizing multiple rync processes of the same job while still ensuring DR compliance.

...