1.1.1 Product Consulting
1.1.1.1 What are the application scenarios of the ZOS migration tool?
When you need to migrate data of other cloud service providers to eSurfing Cloud, you can use the ZOS migration tool to orderly, securely, conveniently and easily migrate digital assets to eSurfing Cloud, in part or in full, while ensuring the availability, security and continuity of applications on the cloud.
1.1.1.2 Does the ZOS migration tool support migration from Alibaba Cloud, eSurfing Cloud, and other cloud platforms to eSurfing Cloud?
Yes.
The ZOS migration tool can migrate data of mainstream cloud service providers in the market to eSurfing Cloud, such as Alibaba Cloud, eSurfing Cloud, AWS and Tencent Cloud.
1.1.1.3 Does the ZOS migration tool support the migration of data on eSurfing Cloud to other cloud service providers or on-premises servers?
No.
For the ZOS migration tool, you can only select eSurfing Cloud as the migration target and thus you cannot migrate data on eSurfing Cloud to an on-premises server or other cloud service providers.
1.1.1.4 Can I ask eSurfing Cloud engineers to help me with the migration when I use the ZOS migration tool?
eSurfing Cloud engineers are not directly involved in your business migration. You can conduct your migration by referring to the Help Center.
If your issues are not mentioned in the Help Center, you can submit your issues on the page, and our engineers will provide supplementary content later.
If you need professional migration solutions and customized technical support, you can order our migration services to help you smoothly migrate applications, shorten the downtime, reduce the impact of cloud migration on your business continuity, relieve your concerns about cloud migration, and focus on business development.
1.1.1.5 Does the ZOS migration tool support resumable transfer?
Yes.
When data transmission is interrupted due to network exceptions, the transmission can be automatically resumed after the network resumes normal operation.
1.1.1.6 How to migrate ZOS data from one account to another?
When you need to migrate resources from Account A to Account B, you must follow the following steps:
1. Log in to the management console as Account B.
2. Click Service List and go to Migration > ZOS Migration Tool.
3. The ZOS Migration Tool page is displayed.
4. Click Data Source Management.
5. Enter the AK/SK of Account A in the Add AK/SK field on the source node, and enter the AK/SK of Account B in the Add AK/SK field on the target node.
6. Click Task Management.
Create a task and bind the source node to the target node.
For more information on steps, see Create a Single Migration Task.
1.1.1.7 How to migrate data in a ZOS bucket from one region to another?
If you need to migrate data in a ZOS bucket from one region to another according to your business needs, for example, from South China-Guangzhou to North China-Beijing 1. When creating a migration task, select a bucket in South China-Guangzhou as the source bucket and a bucket in North China-Beijing 1 as the target bucket. For more information, see Create a Single Migration Task.
1.1.1.8 How to migrate multiple buckets on the source server to a ZOS bucket in eSurfing Cloud?
Assuming there are two buckets on the source server, you can create two migration tasks:
Create migration task 1: Bucket A on the source server > bucket C in eSurfing Cloud
Create migration task 2: Bucket B on the source server > bucket C in eSurfing Cloud
If objects with the same name exist: migrate bucket A: /xxxx/xxx/file0001.txt on the source server first and then bucket B: /xxxx/xxx/file0001.txt on the source server. The last migrated object in bucket C in eSurfing Cloud will overwrite the previous migrated object. That is, only the /xxxx/xxx/file0001.txt object in bucket B on the source server is retained in bucket C.
1.1.1.9 How to migrate data in the root directory?
There are two methods to select and migrate data in the root directory:
Selecting file/folder
When creating a task, select File/Folder as the migration mode.
Click Select. In the pop-up window, select the data you need to migrate (the data in the root directory is displayed by default) and confirm your selection.
Configure the required advanced parameters and create a task. Then, you can migrate the selected data in the root directory.
Specifying an object prefix
When creating a task, Select Enter Object Prefix as the migration mode.
In the input box, type the object prefix (including the data in the root directory) you need to migrate and click Add.
If you need to migrate multiple objects with different prefixes, you can add more prefixes.
Configure the required advanced parameters and create a task. Then, you can migrate the added data in the root directory.
1.1.1.10 Does the migration have any impact on the data on the source server?
The migration has no impact on the data on the source server.
Data on the source server is not modified during migration.
Objects on the source server are not locked during migration.
Data on the source server will not be deleted after the migration is complete.
1.1.1.11 How can I ensure data consistency using the ZOS migration tool If data is written to ZOS all the time?
This problem can be explained in the following two aspects:
How to ensure incremental data is properly migrated?
For more information, see Incremental Data Migration.
How to synchronize data updates on the source server?
You must initiate full data migration again. The ZOS migration tool will automatically identify the updated objects which overwrite previous ones. For details about the overwriting conditions, see "Does the migration affect existing data in the bucket on the target server?".
1.1.1.12 What is the storage type of data migrated to the target bucket if the storage type of the target bucket is archival storage?
The storage type of data after migration is the same as the default data storage type of the target bucket. For example, if the storage type of the target bucket is archival storage, the storage type of the data migrated to the target bucket is still archival storage.
To change the data storage type, you can adjust the lifecycle of objects.
For details about migrating data of archival storage type, see Migrate Archival Storage Data.
1.1.1.13 What are the applicable scenarios of migration tasks?
A migration task is applicable to migrate less than 3 TB of data in a bucket or less than 5 million objects. You can rapidly migrate object data by creating a ZOS migration task. For more information see Create a Migration Task.
1.1.1.14 Can the deletion actions on the source server be synchronized?
The deletion actions on the source server cannot be synchronized.
You can use a script to enumerate objects on the target server and check whether the objects deleted from the source server exist based on the enumeration result. If objects deleted from the source server exists in the enumeration result, delete them manually.
1.1.1.15 What is the verification policy for the ZOS migration tool ensure the consistency of migrated data?
After an object is migrated, the system verifies the object for consistency. If inconsistency is detected, the system records the object in the failed object list. The ZOS migration tool records the number of objects that fail in migration. You can view the task details to check whether the object in the verification policy meets the following conditions. If no, the verification fails and the object is recorded in the failed object list.
Check whether the encryption status of the objects on the target server is the same as the KMS encryption enable status for tasks. For more information, see What should I do when a migration fails due to KMS status error?
The size of objects on the source server is the same as that of objects on the target server.
The last modification time of objects on the target server is not earlier than that of objects on the source server.
1.1.1.16 Why is the number or size of objects in the bucket on the target server different from that of objects in the bucket on the source server after the migration is complete?
The number/size of objects on the source server is higher than that of objects on the target server.
The number of objects on the source server is higher than that of objects on the target server.
Possible cause: There are incremental objects on the source server or a scanning error occurs on the source server.
Diagnosis method: Create a data migration task again and perform incremental data migration. Check whether the number of objects scanned in the bucket on the source server is the same as that collected in the last migration, and confirm the new objects in an object list. If the scanning results are different, you can confirm the new objects in an object list. If the scanning results are consistent, a scanning error occurs on the source server.
Solution: If there are new objects on the source server, you can migrate the new objects to the bucket on the target server by incremental data migration. If there is a problem with scanning on the source server, please submit a ticket.
The size of objects on the source server is higher than that of objects on the target server.
Possible causes:
Fragmented files exist on the source server.
The ZOS migration tool cannot migrate fragmented files.
Objects of different versions exist on the source server.
By default, the ZOS migration tool only migrates objects of the latest version. Objects of different versions cannot be migrated. You must manually migrate these objects.
The cloud service provider of the source server uses a different object statistics rule from eSurfing Cloud.
eSurfing Cloud collects data statistics based on the actual size of objects. However, when the size of objects is less than 64 KB, some source cloud service providers collect statistics based on 64 KB, resulting in capacity inconsistency. Check the object statistics rule used by the cloud service provider on the source server. If the object statistics rule used by the cloud service provider on the source server bases on 64 KB when the size of objects is less than 64 KB, you must check whether the size of objects is smaller than 64 KB.
The number/size of objects on the source server is smaller than that of objects on the target server.
The number of objects on the source server is smaller than that of objects on the target server.
Possible causes:
Statistical data collected by the ZOS migration tool and the console may be delayed to some extent, and you may need to wait for a short period of time after the migration is complete.
The bucket on the target server contains the object list file uploaded by the newly added objects automatically written after the customer's business system switches to eSurfing Cloud.
The size of objects on the source server is smaller than that of objects on the target server.
Possible causes:
The bucket on the target server contains the configuration files uploaded.
You can clear related configuration files. After this, the related migration reports cannot be restored.
The bucket on the target server contains residual fragmented files. If a task is not resumed from the suspended status, fragmented files exist on the bucket on the target server by default.
You can clear residual fragmented files from the bucket on the target server.
1.1.1.17 Does the migration affect existing data in the bucket on the target server?
The impact of the ZOS migration on existing data in the bucket on the target server depends on whether the bucket on the target server has objects with the same names as the objects in the bucket on the source server.
If no objects with the same names exist, the ZOS migration tool has no impact on the existing data in the bucket on the target server.
Existing data in the bucket on the target server will not be modified during migration.
Existing data in the bucket on the target server will not be deleted after the migration is complete.
If objects with the same name exist, existing data in the bucket on the target server will be overwritten by the objects with the same names in the following cases:
The size of objects on the source server is different from that of objects on the target server.
The last modification time of objects on the target server is earlier than that of objects on the source server.
1.1.2
1.1.2.1 What are the compatibility lists?
For more information, see the Compatibility List.
1.1.2.2 What are the restrictions when using the ZOS migration tool to migrate object data to a parallel file system?
The following restrictions apply (restrictions on a parallel file system) when you use the ZOS migration tool to migrate object data to a parallel file system:
If an object name ends with /, the object size must be 0. Otherwise, migration is not supported.
An object name cannot contain consecutive /, for example, test//test.
1.1.2.3 Can the migration proceed on the migration source using the shared bandwidth?
No.
The ZOS migration tool supports only exclusive bandwidth for migration, instead of shared bandwidth. Otherwise, the network condition on the migration source may not be obtained.
1.1.2.4 What are the important disclaimers for the ZOS migration tool?
For more information, see Disclaimer in the Database Migration section.
1.1.3
1.1.3.1 How can I view the progress of a migration task?
Generally, the reference value for the migration speed of ZOS is 10-20 TB a day. The migration speed depends on the number and size of objects on the source server and transmission distance over Internet. We recommend that you create a real data migration task to test the actual migration speed. The actual maximum migration speed is five times the average speed of a single task. A maximum of 5 concurrent tasks are supported in a Region.
You can view the real-time migration speed of a single migration task on the Migration Task page.
If you choose to use the SMN function when creating a migration task, the migration task results will also be sent to you via email, SMS, and your custom URL.
1.1.3.2 How long will a migration task take?
You can estimate the migration duration before migration starts using the following formula: Migration duration = Total data volume/Bandwidth size/8*1.25. For more information about duration estimation, see Evaluate Migration Duration and Test Transfer Speed.
1.1.3.3 What determines the migration bandwidth?
The minimum bandwidth among the following three bandwidth specifications shall be used:
· Egress bandwidth of data source.
· Ingress bandwidth on the target server.
1.1.3.4 How do I know if a task gets stuck?
· Check whether the current speed displayed on the ZOS migration tool (migration speed, auditing number) is normal.
· Check the migration log on the source server. If the log is not refreshed for an extended period of time, the task may be abnormal.
1.1.3.5 Why is the migration speed sometimes much lower than the bandwidth size?
The reasons for this phenomenon are generally but not limited to the following:
· Too many large files
· Too many sparse files
1.1.4 store from Abnormal Conditions
1.1.4.1 What should I do if I fail to create a migration task?
If you fail to create a migration task, a message indicating that "You failed to create a task" is displayed in the upper left corner of the migration task list.
Retry the failed migration task in the following steps.
Click Retry Failed Task in the upper left corner of the task list. The Retry Failed Task page is displayed.
Select the task you need to retry, enter the AK/SK of the source and target server, and click OK.
1.1.4.2 What should I do if the migration fails because the ZOS on the source server is accessed too frequently?
To ensure a high migration speed, the ZOS migration service will invoke the ZOS API at a high frequency when a migration task is being executed. The ZOS on some source servers limits the access frequency. Migration tasks fail when the access frequency is too high.
Solution:
Contact your cloud service provider to modify the access frequency limit of the ZOS to meet migration requirements.
Create a task using the API and use a low thread_num value (the number of threads used by the migration task) to reduce the frequency of accessing migration threads.
1.1.4.3 How to create a migration task again after the migration is complete?
Rebind a target node to the data source and reconfigure the task.