Почему я получаю сообщение «ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ ЗАВЕРШЕНО НЕОБХОДИМО» (ошибка 3013) при восстановлении из хранилища BLOB-объектов Azure на SQL Server 2014

Наш рабочий сервер базы данных каждую ночь выполняет резервное копирование своих баз данных в хранилище BLOB-объектов Azure с помощью BACKUP TO URL в SQL Server 2014 Standard. Сейчас я пытаюсь восстановить эти резервные копии на новую виртуальную машину SQL Server, которую мы создали в Azure, которая также работает под управлением SQL Server 2014 Standard. Я выполняю следующую команду SQL:

RESTORE DATABASE Example FROM URL = 'https://exampleaccount.blob.core.windows.net/livedbbackups/ExampleBackup-2015-10-15T01-13-08.bak';
WITH CREDENTIAL = 'AzureBackupCredential', 
MOVE 'Example' TO 'C:\Databases\Example.mdf',
MOVE 'Example_log' TO 'C:\Databases\Example.ldf',
STATS = 5;

Когда я это делаю, восстановление длится более 10 минут, и я вижу, как оно идет, в окне «Сообщения» SQL Server Management Studio. Однако прямо перед тем, как он будет выполнен на 100%, отображается следующее сообщение об ошибке.

Вывод на виртуальной машине Azure под управлением Microsoft SQL Server 2014 - 12.0.4213.0 (X64) Standard Edition (64-разрядная версия) в Windows NT 6.3 (сборка 9600:) (гипервизор):

85 percent processed.
90 percent processed.
95 percent processed.
Msg 3013, Level 16, State 1, Line 5
RESTORE DATABASE is terminating abnormally.

Поиск в Google по запросу «Ошибка SQL Server 3013» или «Восстановление базы данных SQL Server завершается ненормально» приводит к появлению большого количества страниц, предполагающих, что мой файл базы данных поврежден. Однако я не думаю, что это так, потому что я могу бегать тот же SQL на моем ноутбуке с SQL Server 2014 Express, и я получаю следующий результат:

Вывод на портативном компьютере с Microsoft SQL Server 2014 - 12.0.2269.0 (X64) Express Edition (64-разрядная версия) в Windows NT 6.3 (сборка 10240:) (гипервизор):

85 percent processed.
90 percent processed.
95 percent processed.
100 percent processed.
Processed 233600 pages for database 'Example', file 'Example' on file 1.
Processed 5 pages for database 'Example', file 'Example_log' on file 1.
RESTORE DATABASE successfully processed 233605 pages in 205.802 seconds (8.867 MB/sec).

Оба этих оператора восстановления были запущены для одного и того же URL-адреса с одним и тем же неизмененным файлом резервной копии. Если он правильно восстанавливается на моей локальной копии SQL Server Express, он не может быть поврежден, верно?

Вот еще несколько возможных причин, которые я попытался исключить:

• Несоответствие версий - Резервное копирование выполнялось на сервере под управлением Microsoft SQL Server 2014 - 12.0.2269.0 (X64) Standard Edition (64-разрядная версия). Восстановление было выполнено на сервере под управлением Microsoft SQL Server 2014 - 12.0.4213.0 (X64) Standard Edition (64-разрядная версия). Эти номера версий были определены путем запуска SELECT @@VERSION на каждом из серверов.
• Ошибки Perimssions - Обе RESTORE HEADERONLY и RESTORE FILELISTONLY правильно работать на виртуальной машине Azure, которая не восстанавливает базу данных.
• Свободное место - На диске C: на виртуальной машине Azure свободно более 80 ГБ.
• Подключение к сети - Я не проводил обширного тестирования, но, учитывая, что виртуальная машина, на которой работает SQL Server, работает внутри Azure, а файл резервной копии также находится в Azure, я думаю, что это довольно стабильно. Загрузка файлов и простые тесты в браузере, похоже, указывают на то, что соединение стабильное и быстрое.

При восстановлении рассматриваемая база данных занимает около 2 ГБ с файлом журнала 5 ГБ. У меня есть другие резервные копии той же базы данных, хранящиеся в Azure, и я получаю те же результаты при попытке восстановить любую из них (работает на локальном SQL Server Express 2014, не работает на Azure VM SQL Server Standard 2014).

Есть идеи, что может быть причиной этого и как это исправить?