When a volume has Data Deduplication enabled, the files it contains are not stored as ordinary contiguous data; unique data chunks are stored once in a chunk store and files are represented as reparse points that reference those chunks, with a filter driver reconstructing the original file content on the fly whenever it is opened. That reconstruction only works on a server where the Data Deduplication feature (and its filter driver) is installed; without it, the operating system cannot correctly interpret the deduplicated reparse points, and files can appear zero-byte, corrupted, or simply inaccessible even though the underlying chunk data is intact on the disk. Because Disk2 was deduplicated on Server1 and has now been physically connected to Server2, the fastest path to full, correct access to every file on Disk2 is to install the Data Deduplication server role/feature on Server2, after which Windows recognizes and properly serves the deduplicated volume exactly as it did on Server1 --- no data movement or restore is required, since the data itself already arrived with the disk. Creating a storage pool is unrelated to reading an existing, already-provisioned basic or dynamic disk's deduplicated content. Restoring files from Azure Backup would work eventually but is far slower than simply reading the disk that is already physically attached and intact. Installing the File Server Resource Manager role manages quotas and file classification and has no bearing on the ability to read deduplicated data.