|
| 1 | +--- |
| 2 | +title: StorSimple 1200 migration to Azure File Sync |
| 3 | +description: Learn how to migrate a StorSimple 1200 series virtual appliance to Azure File Sync. |
| 4 | +author: fauhse |
| 5 | +ms.service: storage |
| 6 | +ms.topic: conceptual |
| 7 | +ms.date: 2/14/2020 |
| 8 | +ms.author: fauhse |
| 9 | +ms.subservice: files |
| 10 | +--- |
| 11 | + |
| 12 | +# StorSimple 1200 migration to Azure File Sync |
| 13 | + |
| 14 | +StorSimple 1200 series is a virtual appliance that is run in an on-premises data center. |
| 15 | +With the announced end-of-service-life of the StorSimple product line on December 31 2022, the cloud service this virtual appliance is connected to will stop working. |
| 16 | + |
| 17 | +It is imperative to migrate off of any StorSimple device with ample time to spare. |
| 18 | +Azure File Sync is the natural successor technology, with more features and more flexibility than StorSimple offers. |
| 19 | + |
| 20 | +This article provides the necessary background knowledge and migrations steps for a successful migration to Azure File Sync. |
| 21 | + |
| 22 | +## Azure File Sync |
| 23 | + |
| 24 | +Azure File Sync is a Microsoft cloud service, based on two main components: |
| 25 | + |
| 26 | +* File synchronization and cloud tiering. |
| 27 | +* File shares as native storage in Azure, that can be accessed over multiple protocols like SMB and file REST. An Azure file share is comparable to a file share on a Windows Server, that you can natively mount as a network drive. It supports important file fidelity aspects like attributes, permissions, and timestamps. Unlike with StorSimple, no application/service is required to interpret the files and folders stored in the cloud. The ideal, and most flexible approach to store general purpose file server data as well as some application data, in the cloud. |
| 28 | + |
| 29 | +This article focuses on the migration steps. If before migrating you'd like to learn more about Azure File Sync, we recommend the following articles: |
| 30 | + |
| 31 | +* [Azure File Sync - overview](https://aka.ms/AFS "Overview") |
| 32 | +* [Azure File Sync - deployment guide](storage-sync-files-deployment-guide.md) |
| 33 | + |
| 34 | +## Migration goals |
| 35 | + |
| 36 | +The goal is to guarantee the integrity of the production data as well as guaranteeing availability. The latter requires keeping downtime to a minimum, so that it can fit into or only slightly exceed regular maintenance windows. |
| 37 | + |
| 38 | +## StorSimple 1200 migration path to Azure File Sync |
| 39 | + |
| 40 | +A local Windows Server is required to run an Azure File Sync agent. The Windows Server can be at a minimum a 2012R2 server but ideally is a Windows Server 2019. |
| 41 | + |
| 42 | +There are numerous, alternative migration paths and it would create too long of an article to document all of them and illustrate why they bear risk or disadvantages over the route we recommend as a best practice in this article. |
| 43 | + |
| 44 | +:::image type="content" source="media/storage-files-migration-storsimple-shared/storsimple-1200-migration-overview.png" alt-text="Migration route overview of the steps further below in this article."::: |
| 45 | + |
| 46 | +The previous image depicts steps that correspond to sections in this article. |
| 47 | + |
| 48 | +### Step 1: Provision your on-premises Windows Server and storage |
| 49 | + |
| 50 | +1. Create a Windows Server 2019 - at a minimum 2012R2 - as a virtual machine or physical server. A Windows Server fail-over cluster is also supported. |
| 51 | +2. Provision or add Direct Attached Storage (DAS as compared to NAS, which is not supported). The size of the Windows Server storage must be equal to or larger than the size of the available capacity of your virtual StorSimple 1200 appliance. |
| 52 | + |
| 53 | +### Step 2: Configure your Windows Server storage |
| 54 | + |
| 55 | +In this step, you map your StorSimple storage structure (volumes and shares) to your Windows Server storage structure. |
| 56 | +If you plan to make changes to your storage structure, meaning the number of volumes, the association of data folders to volumes, or the subfolder structure above or below your current SMB/NFS shares, then now is the time to take these changes into consideration. |
| 57 | +Changing your file and folder structure after Azure File Sync is configured, is cumbersome, and should be avoided. |
| 58 | +This article assumes you are mapping 1:1, so you must take your mapping changes into consideration when you follow the steps in this article. |
| 59 | + |
| 60 | +* None of your production data should end up on the Windows Server system volume. Cloud tiering is not supported on system volumes. However, this feature is required for the migration as well as continuous operations as a StorSimple replacement. |
| 61 | +* Provision the same number of volumes on your Windows Server as you have on your StorSimple 1200 virtual appliance. |
| 62 | +* Configure any Windows Server roles, features, and settings you need. We recommend you opt into Windows Server updates to keep your OS safe and up to date. Similarly, we recommend opting into Microsoft Update to keep Microsoft applications up to date, including the Azure File Sync agent. |
| 63 | +* Do not configure any folders or shares before reading the following steps. |
| 64 | + |
| 65 | +### Step 3: Deploy the first Azure File Sync cloud resource |
| 66 | + |
| 67 | +[!INCLUDE [storage-files-migration-deploy-afs-sss](../../../includes/storage-files-migration-deploy-azure-file-sync-storage-sync-service.md)] |
| 68 | + |
| 69 | +### Step 4: Match your local volume and folder structure to Azure File Sync and Azure file share resources |
| 70 | + |
| 71 | +[!INCLUDE [storage-files-migration-namespace-mapping](../../../includes/storage-files-migration-namespace-mapping.md)] |
| 72 | + |
| 73 | +### Step 5: Provision Azure file shares |
| 74 | + |
| 75 | +[!INCLUDE [storage-files-migration-provision-azfs](../../../includes/storage-files-migration-provision-azure-file-share.md)] |
| 76 | + |
| 77 | +### Step 6: Configure Windows Server target folders |
| 78 | + |
| 79 | +In previous steps, you have considered all aspects that will determine the components of your sync topologies. It is now time, to prepare the server to receive files for upload. |
| 80 | + |
| 81 | +Create **all** folders, that will sync each to its own Azure file share. |
| 82 | +It's important that you follow the folder structure you've documented earlier. If for instance, you have decided to sync multiple, local SMB shares together into a single Azure file share, then you need to place them under a common root folder on the volume. Create this target root folder on the volume now. |
| 83 | + |
| 84 | +The number of Azure file shares you have provisioned should match the number of folders you've created in this step + the number of volumes you will sync at the root level. |
| 85 | + |
| 86 | +### Step 7: Deploy the Azure File Sync agent |
| 87 | + |
| 88 | +[!INCLUDE [storage-files-migration-deploy-afs-agent](../../../includes/storage-files-migration-deploy-azure-file-sync-agent.md)] |
| 89 | + |
| 90 | +### Step 8: Configure sync |
| 91 | + |
| 92 | +[!INCLUDE [storage-files-migration-configure-sync](../../../includes/storage-files-migration-configure-sync.md)] |
| 93 | + |
| 94 | +> [!WARNING] |
| 95 | +> **Be sure to turn on cloud tiering!** This is required if your local server does not have enough space to store the total size of your data in the StorSimple cloud storage. Set your tiering policy, temporarily for the migration, to 99% volume free space. |
| 96 | +
|
| 97 | +Repeat the steps of sync group creation and addition of the matching server folder as a server endpoint for all Azure file shares / server locations, that need to be configured for sync. |
| 98 | + |
| 99 | +### Step 9: Copy your files |
| 100 | + |
| 101 | +The basic migration approach is a RoboCopy from your StorSimple virtual appliance to your Windows Server, and Azure File Sync to Azure file shares. |
| 102 | + |
| 103 | +Run the first local copy to your Windows Server target folder: |
| 104 | + |
| 105 | +* Identify the first location on your virtual StorSimple appliance. |
| 106 | +* Identify the matching folder on the Windows Server, that already has Azure File Sync configured on it. |
| 107 | +* Start the copy using RoboCopy |
| 108 | + |
| 109 | +The following RoboCopy command will recall files from your StorSimple Azure storage to your local StorSimple and then move them over to the Windows Server target folder. The Windows Server will sync it to the Azure file share(s). As the local Windows Server volume gets full, cloud tiering will kick in and tier files that have successfully synced already. Cloud tiering will generate enough space to continue the copy from the StorSimple virtual appliance. Cloud tiering checks once an hour to see what has synced and to free up disk space to reach the 99% volume free space. |
| 110 | + |
| 111 | +```console |
| 112 | +Robocopy /MIR /COPYALL /DCOPY:DAT <SourcePath> <Dest.Path> |
| 113 | +``` |
| 114 | + |
| 115 | +Background: |
| 116 | + |
| 117 | +:::row::: |
| 118 | + :::column span="1"::: |
| 119 | + /MIR |
| 120 | + :::column-end::: |
| 121 | + :::column span="1"::: |
| 122 | + Allows to run this RoboCopy command several times, sequentially on the same target / destination. It identifies what has been copied before and omits it. Only changes, additions and "*deletes*" will be processed, that occurred since the last run. If the command wasn't run before, nothing is omitted. This is an excellent option for source locations that are still actively used and changing. |
| 123 | + :::column-end::: |
| 124 | +:::row-end::: |
| 125 | +:::row::: |
| 126 | + :::column span="1"::: |
| 127 | + /COPY:copyflag[s] |
| 128 | + :::column-end::: |
| 129 | + :::column span="1"::: |
| 130 | + fidelity of the file copy (default is /COPY:DAT), copy flags: D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info |
| 131 | + :::column-end::: |
| 132 | +:::row-end::: |
| 133 | +:::row::: |
| 134 | + :::column span="1"::: |
| 135 | + /COPYALL |
| 136 | + :::column-end::: |
| 137 | + :::column span="1"::: |
| 138 | + COPY ALL file info (equivalent to /COPY:DATSOU) |
| 139 | + :::column-end::: |
| 140 | +:::row-end::: |
| 141 | +:::row::: |
| 142 | + :::column span="1"::: |
| 143 | + /DCOPY:copyflag[s] |
| 144 | + :::column-end::: |
| 145 | + :::column span="1"::: |
| 146 | + fidelity for the copy of directories (default is /DCOPY:DA), copy flags: D=Data, A=Attributes, T=Timestamps |
| 147 | + :::column-end::: |
| 148 | +:::row-end::: |
| 149 | + |
| 150 | +When you run the RoboCopy command for the first time, your users and applications are still accessing the StorSimple files and folders and potentially change it. It is possible, that RoboCopy has processed a directory, moves on to the next and then a user on the source location (StorSimple) adds, changes, or deletes a file that will now not be processed in this current RoboCopy run. That is fine. |
| 151 | + |
| 152 | +The first run is about moving the bulk of the data back to on-premises, over to your Windows Server and backup into the cloud via Azure File Sync. This can take a long time, depending on: |
| 153 | + |
| 154 | +* your download bandwidth |
| 155 | +* the recall speed of the StorSimple cloud service |
| 156 | +* the upload bandwidth |
| 157 | +* the number of items (files and folders), that need to be processed by either service |
| 158 | + |
| 159 | +Once the initial run is complete, run the command again. |
| 160 | + |
| 161 | +The second time it will finish faster, because it only needs to transport changes that happened since the last run. Those changes are likely local to the StorSimple already, because they are recent. That is further reducing the time because the need for recall from the cloud is reduced. During this second run, still, new changes can accumulate. |
| 162 | + |
| 163 | +Repeat this process until you are satisfied that the amount of time it takes to complete is an acceptable downtime. |
| 164 | + |
| 165 | +When you consider the downtime acceptable and you are prepared to take the StorSimple location offline, then do so now: For example, remove the SMB share so that no user can access the folder or take any other appropriate step that prevents content to change in this folder on StorSimple. |
| 166 | + |
| 167 | +Run one last RoboCopy round. This will pick up any changes, that might have been missed. |
| 168 | +How long this final step takes, is dependent on the speed of the RoboCopy scan. You can estimate the time (which is equal to your downtime) by measuring how long the previous run took. |
| 169 | + |
| 170 | +Create a share on the Windows Server folder and possibly adjust your DFS-N deployment to point to it. Be sure to set the same share-level permissions as on your StorSimple SMB share. |
| 171 | + |
| 172 | +You have finished migrating a share / group of shares into a common root or volume. (Depending on what you mapped and decided that needed to go into the same Azure file share.) |
| 173 | + |
| 174 | +You can try to run a few of these copies in parallel. We recommend processing the scope of one Azure file share at a time. |
| 175 | + |
| 176 | +> [!WARNING] |
| 177 | +> Once you have moved all the data from you StorSimple to the Windows Server, and your migration is complete: Return to ***all*** sync groups in the Azure portal and adjust the cloud tiering volume free space percent value to something better suited for cache utilization, say 20%. |
| 178 | +
|
| 179 | +The cloud tiering volume free space policy acts on a volume level with potentially multiple server endpoints syncing from it. If you forget to adjust the free space on even one server endpoint, sync will continue to apply the most restrictive rule and attempt to keep 99% free disk space, making the local cache not performing as you might expect. Unless it is your goal to only have the namespace for a volume that only contains rarely accessed, archival data. |
| 180 | + |
| 181 | +## Troubleshoot |
| 182 | + |
| 183 | +The most likely issue you can run into, is that the RoboCopy command fails with *"Volume full"* on the Windows Server side. If that is the case, then your download speed is likely better than your upload speed. Cloud tiering acts once every hour to evacuate content from the local Windows Server disk, that has synced. |
| 184 | + |
| 185 | +Let sync progress and cloud tiering free up disk space. You can observe that in File Explorer on your Windows Server. |
| 186 | + |
| 187 | +When your Windows Server has sufficient available capacity, rerunning the command will resolve the problem. Nothing breaks when you get into this situation and you can move forward with confidence. Inconvenience of running the command again is the only consequence. |
| 188 | + |
| 189 | +You can also run into other Azure File Sync issues. |
| 190 | +As unlikely as they may be, if that happens, take a look at the **LINK Azure File Sync troubleshooting guide**. |
| 191 | + |
| 192 | +## Relevant links |
| 193 | + |
| 194 | +Migration content: |
| 195 | + |
| 196 | +* [StorSimple 8000 series migration guide](storage-files-migration-storsimple-8000.md) |
| 197 | + |
| 198 | +Azure File Sync content: |
| 199 | + |
| 200 | +* [AFS overview](https://aka.ms/AFS) |
| 201 | +* [AFS deployment guide](storage-files-deployment-guide.md) |
| 202 | +* [AFS troubleshooting](storage-sync-files-troubleshoot.md) |
0 commit comments