Have you ever been tasked with shipping Microsoft a large amount of data that isn’t feasible over a network transfer? If you have created this type of colossal Azure Import job, then you are likely familiar with the painstaking process of using the WAImportExport tool to load a previously encrypted drive. The actual use of this tool is documented fairly well, however, everyone’s environment is a little different so challenges often arise in this process.
Recently, we ran into a particularly interesting challenge that may be a common one for our blog readers. This was a lack of free storage space to store several large files on the machine from which the data needed to be extracted.
The project where we ran into this challenge was roughly 1.5 terabytes worth of SQL Server database backups. Below is a screenshot of the scenario we were faced with. As you can see in the image, there were six total drives attached to the machine we are working on. The C, D, E, and F drives do not have capacity to hold an additional 1.5 terabytes. Additionally, the G drive is an external USB drive that is not accessible. The performance of USB 2.0 eliminates this drive from as an option because the performance is not optimal for this process.
We needed a landing zone for the 1.5 terabyte database backups before we used the Azure Import Export tool. The challenge here is that the WAImportExport tool does not let you use the same source and target drive. This means that we were unable to land the database backups on the Y:\ and use WAImportExport to “reload” the data to the Y:\ in the correct format for the Azure Import Job.
The solution to this challenge was to create a Windows “symlink” on the D:\ which points to the folder on the Y:\ that houses the database backup files. By doing this, we are kind of “tricking” the Azure Import Export tool into using the symlink’ed Y:\ as the source via the D:\. We can then successfully use Y:\ as the target. These are identified in the CMD window below as “/srcdir:D\DBBackup_Y” and “/t:Y” respectively.
After using the Azure Import Export tool to load the database backup files, the drive now has two copies of the database backups, one prepped for the Azure Import Job and one that can be moved off, archived, or deleted if no longer needed.
This solution allows you to successfully ship your drive to Microsoft and continue Azure Import job process without concerns for storage space.
For more insight into Microsoft Storage options, contact a BI professional at 813.265.3239 or email@example.com.