We recently helped a Dublin-based firm involved in the area of AI and machine learning. They are currently co-operating on a machine-learning project with a company in Finland. For the last month, a dedicated computer system (a Dell OptiPlex) in their lab had been collecting machine-learning data. The collection phase of the project recently ended and the Irish team had 3.6TB of machine learning data stored on a Samsung Evo 870 Pro 4TB SSD. They cloned the disk to another Samsung Evo 870. The cloning process completed successfully. They put the disk inside a 2.5” USB disk enclosure. They then prepared it for the courier where it would be whisked up the land of reindeer, saunas and old Nokia factories.
However, one of their staff members decided to connect the disk to the OptiPlex to check that it was working. The disk was not even recognised. This was the only Windows system in the office. So, they removed the Evo 870 and connected it directly to a S-ATA port and a power connector of the OptiPlex. But still, the disk was not appearing. They had assumed it had failed prematurely. The courier would be arriving shortly and they were up against a deadline. Luckily, their offices were only a stone’s throw from Drive Rescue. Could we help? We popped in to have a (socially distanced) look.
The problem was simple. The cloned disk had the same disk signature as the disk inside the Optiplex. “Disk collisions” can happen with a lot of disk cloning applications. To fix this problem we simply went into Windows Command Prompt. We used the Diskpart command to select the right disk. We then used the “uniqueid disk” command to give the cloned disk a different ID. (In command prompt you simply type “uniqueid disk id=mickeymouse” or whatever!) The disk became immediately recognised. No data recovery was even needed. Just as we were leaving, the courier was arriving. While their disk ID might not have been good, their timing was absolutely perfect!