WHITE PAPER GuardianOS Data Migration Tool Enables Ease of Snap Server Deployment and Data Consolidation Introduction Powered by the GuardianOS™ operating system, the Overland Storage® Snap Server® family of NAS storage servers support numerous file access protocols that provide client access to files in Windows, UNIX, and AFP networks, as well as remote access via FTP and HTTP. Since Snap Servers are a cost-effective file server replacement for so many platforms, a utility that simplifies data migration to Snap Servers was designed as part of GuardianOS. This white paper will describe how to utilize and best leverage the data migration utility built into GuardianOS. Overview of the Data Migration Utility The data migration utility allows administrators to easily copy or move data from any file server that has an accessible Windows (CIFS/SMB) share or UNIX (NFS) mount. It can also preserve permissions in order to make the transition to a new Snap Server seamless to end users and data owners. Previously, only native tools were readily available to move data from older file servers. Now, for consolidating data from multiple sources or performing a technology refresh, the data migration utility simplifies the migration process and reduces the implementation time for the new Snap Server. The Old Way In the past, if an administrator was moving data from a Windows system he could simply drag-and-drop the data if he was unconcerned with preserving permissions. However, if he wanted to maintain any user and group permissions while migrating, he was forced to use other utilities, such as XCOPY, Robocopy, SCOPY, XXCOPY, etc. Each of these tools has its own set of subtle nuances that can make it difficult to work with and can produce inconsistent and unpredictable results. Not to mention that these tools lack the ability to verify the data transfers or restart without overwriting all data that was previously copied after a failed data movement. If the administrator was moving data from a UNIX-based operating system, the task was not as unpredictable, but consolidating multiple systems could, nevertheless, become incredibly cumbersome. In many cases, administrators are replacing or offloading data from existing network attached storage (NAS) systems that do not have local utilities or commands for migrating data from them, requiring the use of a third-party Windows or UNIX system to move that data. Permissions on both the source and target must be painstakingly set to allow the operation. The third-party system will become bogged down moving data instead of doing other productive work. This can especially be a problem if the administrator’s own workstation is used. A Better Way Now, with an integrated data migration utility on GuardianOS-powered Snap Servers, administrators can easily move data, streamlining the integration of a new Snap Server. This makes it less daunting to offload shared data from servers that were not originally intended for file serving, perform a technology refresh on older file servers that cannot keep up with the current performance and capacity requirements, or even to centralize the storage of multiple file servers to one high-capacity and high-performance solution. 1 The benefits of using the embedded data migration utility over other copy or move tools are simplicity and centralization. The simplicity comes from having a centralized single interface for copying or moving data from any server or storage platform that can be mounted using either CIFS/SMB (Windows) or NFS (UNIX/Linux/Solaris/Mac OS X). Administrators will no longer have to learn any command-line switches to make sure that the permissions are included. No manual verification that the data was successfully migrated is required. Everything an administrator needs to successfully perform data migration from other servers is on one easy-to-use screen within the web browser administration tool of Snap Server systems. Since the data migration utility runs natively on the Snap Server, all migration processing is done locally on the Snap Server and does not require any other system to facilitate the migration of data from the source. Just getting the data where it needs to be on a new file server can be the most difficult part of integrating a new data storage device. With the data migration utility, administrators can now easily accomplish this task. Use Case Scenarios for the Data Migration Utility There are several scenarios where the data migration utility can simplify the task of getting data moved over to the new Snap Server. The following use case scenarios outline some of the ways that in which the data migration utility can be used. Figure 3.1 shows just two examples of these use cases. Snap Server 520, 620 or Snap Server with Expansion Figure 3.1 The data migration utility is designed to be a single-direction, single-instance tool for moving data from a source system to a target system. In the first usage case above (Performing a Technology Refresh with the Data Migration Utility) the usage of the data migration utility is illustrated as a single operation for each server that is being replaced with a more current Snap Server system. In the second usage case above (Consolidating Multiple File Servers with the Data Migration Utility) the data migration utility is run repeatedly for each source system that is being consolidated and/or replaced by the more current Snap Server system. 2 Use Case #1 – Migrating Data from a Server Running Windows (CIFS/SMB) Migrating data from a Windows source server requires the existence of a Windows share to provide access to the data by the Snap Server. The source server can be in a Windows Workgroup, an NT Domain, or an Active Directory Domain. The data migration utility can retain permissions for servers in a Windows NT or Active Directory Domain as long as the Snap Server is joined to the domain prior to executing the migration. If the Windows source is part of a Windows Workgroup, permissions can not be retained as all local user and group accounts are only relevant on the source server. Local Windows user and group security identifiers (SIDs) are not transferable, and therefore, the permissions cannot be recreated. In all cases, a proper administrative user account will be required to access the data on the source machine in order to properly transfer the data and permissions. If the source data contains filenames with extended characters other than common Western European characters (CP 1252), it may be advisable to enable Unicode on the Snap Server. Then, convert the file system to the proper mode before migration in order to properly retain the extended characters. Note: SMB must be enabled on the Snap Server to perform migration using the Windows network protocol option. This is enabled by default in the Network – Windows screen of the web browser administration tool. A valid Windows share must also exist that allows write access to the target path in order to properly preserve permissions and DOS attributes. Use Case #2 – Migrating Data from a Server Running UNIX or Linux (NFS) When moving data from a UNIX-based file server via NFS, the source server must have a valid NFS mount point for access to the data by the Snap Server. The file server can be part of a NIS Domain, but does not have to be. If permission preservation is enabled, the data migration utility preserves permissions and ownership for all user identifiers (UIDs) and group identifiers (GIDs) verbatim, regardless of whether an equivalent UID/GID is known to the Snap Server. This means that if all UIDs/GIDs are created on the target and match the source, permissions will be properly retained. A proper administrative user account will be required to access the data on the source machine in order to properly transfer the data and permissions. The migration will take place with the UID of the local Snap Server user logged into the UNIX machine as the migration user (note that the name may not have an equivalent on the target machine – only the UID is relevant). Filenames are transferred over NFS verbatim as a “bag of bytes”. Therefore, extended characters in filenames may not be properly retained if encoded on the source with a character set that does not match the character set used on the Snap Server's file system (ISO 8859-1/CP 1252 if Unicode is disabled, or UTF-8 if Unicode is enabled). Note: When connecting to the NFS source, the Snap Server tries to connect using NFSv3 by default, but will fall back to NFSv2 if necessary. It will, likewise, try to use TCP as the default transport protocol, but fall back to UDP. Use Case #3 – Migrating Data from a GuardianOS-Powered Snap Server Migrating data from another GuardianOS-powered Snap Server to a new Snap Server with the data migration utility works just as if you were moving data from any other file server source. Be sure to choose the appropriate protocol for the migration job with respect to the security model of the data being migrated. For example, if the data is in 3 a Windows SnapTree, use Windows, and if the data is in a UNIX SnapTree, use NFS to migrate the correct permissions. The rest works the same as any other Windows or UNIX data migration as described in Use Cases #1 and #2. To properly retain any extended characters in filenames, make sure the target Snap Server is configured for the same Unicode state (enabled/disabled) as the source Snap Server. Note: If the source location contains both Windows and UNIX SnapTrees and you want to preserve permissions, split the migration operation into multiple jobs, one for each SnapTree for the given security model, using the appropriate protocol per job.