A common question we receive for our products is: what's the largest drive that your unit supports? Often, and especially with newer products, there is no effective limit. However, sometimes larger drives have issues with older units, particularly when they are moved from an enclosure or docking station for internal use or vice-versa. This can cause issues such as the drive's data becoming unreadable. This is almost always with hard drives and not solid state drives as the former come in higher capacities and the latter are migrating to NVMe and the M.2 form factor with updated controller support.
The controller, in this case, is a bridge or translation chipset that can communicate between SATA or PCIe and USB. This is generally achieved through the use of analogous SCSI commands which, as far as the drive is concerned, is a perfectly fine solution, although performance may be somewhat compromised by the USB protocol. Even these issues are going away with USB4 and Thunderbolt, but to digress - these controllers need to handle a variety of drives and, especially if the controllers are older, they need to be built for legacy devices and corresponding compatibility. This last area is where some of the problems arise and we will discuss why.
Block diagram for an SATA to USB bridge controller. Source: JMicron
The first thing to address is drive size, with typically 2TB being the cut-off point. This goes back to the days of 32-bit operating systems which restricts the ability to address enough space with a limit around 2.2TB (source: Microsoft). This is due to the typical atomic, or smallest, data unit, also called a sector, which traditionally is 512 bytes in size, disregarding ECC and extra bytes. A 4 kilobyte scheme is more efficient (source: Wikipedia) and performance measurements for SSDs are often given in 4KB. For compatibility, however, there is a requirement for 512 emulation (512e) and also support for 4K native (4Kn), achieved with Advanced Format. A larger sector size means fewer total sectors and can also impact offset size, which is problematic due to how some bridge controllers manage the disks.
"Potential Read Sequence for 512-Byte Emulation". Source: Seagate
The reason for this is that the bridge controller might opt to parse or interpret a drive as using 4KB sectors, in part to increase large-drive compatibility with older operating systems like Windows XP. With sectors 8 times as large you can reach 16TB. This introduces a problem when that drive was originally formatted in logical 512B, and also drives initialized in the enclosure or docking station, as such drives will be re-interpreted as 512B in a normal operating system if later placed internally. This is compounded by the use of MBR rather than GPT partitioning, the former being more limited and also usually being restricted to 2TB when paired with 512B sectors. The data is not gone, but the partition table and offsets are misaligned which makes it appear that it is to the OS.
MBR versus GPT. Source: MustBeGeek
If the only thing that matters is data, it can be recovered with most data recovery or analysis tools, such as DMDE. Full understanding and recovery of the underlying disk can be more complicated (The HDD Oracle). Depending on the capacity of the drive and the partitioning system used, different solutions are required, although essentially in all cases the partition system must be rescanned and rebuilt. It may be possible to locate and restore partitions more specifically and carefully, with perhaps the ability for more advanced reconstruction, with tools like MiniTool Partition Wizard. We in all cases recommend being careful with data, especially if there is no other remaining backup, and you may wish to seek professional assistance with any valuable data.
More generally our advice is to get the data off a drive if that is your goal, and to use an appropriate tool - such as a dedicated cloner, multi-bay solution, or updated backup tool - if you explicitly require cloning to do a drive swap with an older drive or from a very old OS. This particularly applies to HDDs rather than SSDs. Having a full backup solution in place beforehand is also recommended, using a 3-2-1 backup strategy (Backblaze) and also possibley using a grandfather-father-son backup approach (Backblaze). When working with drives for cloning, imaging, and installation, be careful with drive selection, even if that means disconnecting all other drives, but be aware you may unknowingly have boot data on a secondary drive such as the EFI partition - although it's possible to repair this, as well.
3-2-1 and GF-F-S backup schemes. (Sources: StoneFly, NikTips)
Our goal at Sabrent is to make everything as easy as possible for you. If you have any problems with a legacy product, please contact technical support to see if there's updated or modified firmware to fix your specific issue. Informed users are happier users, so we want to also get this information out there to avoid additional confusion. Dealing with data can be an anxiety-ridden process and it is best to approach things calmly and deliberately. Take your time, read up, and consult a professional if necessary. In most cases your HDD data isn't going to disappear, so be patient for the best results.
