Резервное копирование зависает на 71%
11.50058
Примерно в конце января начал наблюдать странности при работе с резервным копированием рабочих станций (Windows 7 x64 со всеми обновлениями) по существующим планам.
Прогресс застывает на 71% и может так висеть несколько часов, при этом в окне состояния висит следующий статус:
Скриншот свежий, снят в 16 часов.
Ступор случается на 71% и 75%, потом случается некий таймаут (от 6 до 24 часов).
Этот план резервного копирования одинаков со всеми остальными (разное только время запуска).
Скриншот с задания, который на 71%
Понаблюдав несколько дней за происходящим пришёл к выводу, что проблема затрагивает все подключенные к серверу управления хранилища.
Даже то, которое я специально для тестов создал и подключил на днях.
И это независит от количества бекапов, находящихся в хранилище.
В данном конкретном случае бекап создался с 0 за 9 минут, но после этого больше 40 минут висит на 70%
Hello alexdexter.
What is the build number of your Acronis Backup Advanced 11.7 version?
Этот план резервного копирования одинаков со всеми остальными (разное только время запуска).
According to this backup plan screenshot, consolidation option is turned on.
проблема затрагивает все подключенные к серверу управления хранилища.
Даже то, которое я специально для тестов создал и подключил на днях
Is your test location also located on a centralized vault?
I recommend that you collect Acronis System Report from a machine where Acronis Storage Node is installed and from any workstation with Acronis Agent which suffers from this issue.
Please upload both reports on FTP link that I've sent you in a private message for analysis.
What is the build number of your Acronis Backup Advanced 11.7 version?
Изначально сервер управления (как и агенты) на крайнем российском релизе 50058.
После того, как начались подобные проблемы обновил сервер управления до английской версии 50230 (на рабочих станциях через утилиту очистки были удалены все компоненты Core/Agent от 50058 и установлены соответствующие от 50230). Так что сейчас все компоненты сервера управления/узла хранения/сервера лицензий/агентов - всё на англоязычной 50230.
According to this backup plan screenshot, consolidation option is turned on.
Консолидация вообще всегда была включена, и подобных проблем раньше не было. Данный сервер управления работает уже больше трех лет, и описываемая проблема началась только в прошедшем январе.
Is your test location also located on a centralized vault?
Да. На сервере управления подключено 3 узла хранения: для рабочих станций (дедупликация включена, ~100 планов резервных копий по 5 бекапов в каждом, суммарно 400 бекапов), для серверов (дедупликация включена, ~35 планов резервных копий, в среднем по 7 бекапов в каждом), тестовое (дедупликация выключена, туда перенес около 10 планов резервных копий от рабочих станций).
Все физически расположены на разном оборудовании.
I recommend that you collect Acronis System Report from a machine where Acronis Storage Node is installed and from any workstation with Acronis Agent which suffers from this issue.
Сейчас организую.
Hello alexdexter.
Thank you for detailed issue description and screenshots - this data was very helpful in understanding the situation and settings.
Консолидация вообще всегда была включена, и подобных проблем раньше не было.
At any case, the consolidation is a very resource-consuming and intensive operation. It reads the data from the archive, creates a new slice where it stores the data from the previously created archive and then deletes it. It takes time almost equal restore + backup operations. You could have not noticed this before because either retention rules were different or the number of backups in the archive did not exceed 5.
We recommend that you change your backup scheme by adding full backup creation and disabling consolidation and marking archives for deletion. It will not occupy too much space since deduplication (which is also a quite resource-consuming operation) is on.
Спасибо за рекомендацию. Продолжу брутфорс вариантов планов.
Последний вопрос:
В связи с тем, что придется перелопачивать больше сотни планов резервного копирования - есть ли инструмент (может команда для mssql), чтобы всем планам массово отключить консолидацию?
Изменил планы для серверов. Всем поменял план резервного копирования с инкрементного на полный, убрал консолидацию - теперь помечается для удаления. Подождал несколько дней. Результат не изменился:
Примерно та же история с пользовательскими бекапами. На части из них проделал примерно такую же операцию, но безрезультатно. Висит 60 задач. В течении дня вырастет до 80-90.
Hello alexdexter,
Изменил планы для серверов. Всем поменял план резервного копирования с инкрементного на полный, убрал консолидацию - теперь помечается для удаления. Подождал несколько дней. Результат не изменился
Thanks for sharing the outcome.
Висит 60 задач. В течении дня вырастет до 80-90.
This also could be the root of the problem. Thank you for pointing attention on this.
ASN is limited in a number of clients connections. Please increase them up to 100 as described in this KB article.
Maria Belinskaya wrote:Hello alexdexter,
Изменил планы для серверов. Всем поменял план резервного копирования с инкрементного на полный, убрал консолидацию - теперь помечается для удаления. Подождал несколько дней. Результат не изменился
Thanks for sharing the outcome.
Висит 60 задач. В течении дня вырастет до 80-90.
This also could be the root of the problem. Thank you for pointing attention on this.
ASN is limited in a number of clients connections. Please increase them up to 100 as described in this KB article.
Странная вещь, но на узлах хранения значения ключей:
HKLM\SOFTWARE\Acronis\ASN\Configuration\StorageNode\FastOperationConnectionLimit to 30 HKLM\SOFTWARE\Acronis\ASN\Configuration\StorageNode\FastOperationQueueLimit to 100
Было по 2000. Я совершенно точно раньше в этот раздел реестра не заходил ни на одном узлов хранения.
Что странно, проблема появилась где-то в январе еще когда был установлен русскоязычный релиз 50058. При этом само обновление 50058 устанавливалось за год до этих событий.
После изменения параметров в реестре, согласно KB54824 и перезагрузки обоих узлов хранения, позитивных изменений в работе не наблюдаю. 71% на всех выполняемых планах резервного копирования серверов этой ночью.
Еще одно наблюдение: часть заданий после этого временного зависания на 71%/75% отваливаются со статусом ошибки:
При этом если открыть историю, то резервная копия снялась успешно:
Hello alexdexter,
could you please download and share an activity log for this latest backup job?
Загрузил на фтп лог по конкретной рабочей станции со скриншота и всю активность за последние сутки на сервере управления.
Рабочие станции со статусом ошибок после 8 часов действия плана резервного копирования
Hello alexdexter.
Finally, I have found an error message in the activity log from the Agent PC:
<event Owner="" module="307" code="20 119 553(0x1330001)" message="ProtectionAggregation: Protection object update error, some information may be incorrect.|Additional info: |--------------------|Error code: 1|Module: 307|LineInfo: ec69ad9eeeb1a08e|Fields: $module : agent_protection_addon_vs_50230|Message: ProtectionAggregation: Protection object update error, some information may be incorrect.|--------------------|Error code: 10|Module: 249|LineInfo: 6298a2d9c3a1e7c3|Fields: $module : mms_vs_50230|Message: The service is being stopped at the moment.|--------------------"
There was a similar issue Job registry is being stopped at the moment (ABR-87968) registered in our system. It has been resolved in Acronis Backup 12 (which is now updated to Acronis Backup 12.5 version).
После рестарта самого узла управления (он же один из узлов хранения), время выполнения заданий вроде бы нормализовались. Хотя по KB54824 рекомендовалось перезапускать только службы узлов хранения.
В общем помониторю на будущей неделе по рабочим станциям, но по крайней мере на серверных планах больше не замечаю зависания на 71%/75%
Спасибо за помощь!
Похоже рано начал радоваться. Репликация/очистка отработала быстро, все остальные процессы по старому:
Hello alexdexter.
Unfortunately, as I have noted above, this issue does not depend on the software settings because this is a known bug which was fixed in a newer version - Acronis Backup 12.5.
Я понял про баг. Мне просто интересно было - с чего это вообще изначально всплыло. Всё прекрасно работало с декабря 2015 (еще с установки 11.5). А тут январь 2019 и случилось.
На сервере управления/узлах хранения, да и на рабочих станциях изменения происходили только со штатным обновлением Windows, ну и антивируснное ПО (Dr.Web ESS).
Впрочем ладно. Спасибо за помощь.
Интересный кумулятивный эффект от данной ошибки.
Для Акрониса вот эти задания резервного копирования зависшие на 71%/75%, в активном статусе, а значит пока оно не прекратится, новая резервная копия по заданному расписанию не снимется.
А так как внутреннего таймаута для данной операции в природе не существует, это означает, что надежность продукта сильно падает.
Костыль (пока не найдем альтернативу данному ПО) это принудительный ежедневный рестарт сервера управления.
Hello alexdexter.
Since our developers do not fix any issues in Acronis Backup 11.7 anymore, I would advise that you kill the service_process.exe in Task Manager.
На сервере управления/узле хранения такого не наблюдаю:
Hello alexdexter.
The service_process.exe launches a task on the Agent's. Please kill it on the Agent which backup is stalled. Please also check on that Agent whether the mms.exe process is started.
У меня ежедневно (в течении рабочего дня) висит примерно 50-90 одновременно выполняющихся заданий. Предлагается на этих рабочих станциях убивать указанный процесс?
Hello alexdexter.
I asked you to export and share your backup plan in the neighbor thread. I hope that it will spread more light on possible workarounds.
Hello alexdexter.
Unfortunately, I can't provide you with any other workaround for the bug ABR-87968.
Please download and test the trial version for Acronis Cyber Backup 12.5.