Нужен ли встроенный бэкап ManageEngine ServiceDesk

ServiceDesk logoДобрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз я вам рассказывал, как можно произвести обновление ManageEngine ServiceDesk 9400 до версии 10016. В момент обновления сервисдеск штатными средствами делает резервную копию, которая будет длиться продолжительное время, все зависит от размера количества ваших заявок и вложенных файлов в них. Я вам показывал, как это пропускать, но вопрос не в этом, так как такая же задача у вас запускается каждый день, в виде архивации данных. И вот собственно вопрос нужна ли она вообще и на сколько она быстро вам поможет восстановить данные.

Вся папка ManageEngine ServiceDesk в моем случае весит 52 ГБ, это означает, что одно архивирование данных занимает 3,5-4 часа и требует лишних 60 ГБ свободного места.

Сколько времени нужно на восстановление ManageEngine ServiceDesk

Представим ситуацию, что в какой-то момент у вас ломается ManageEngine ServiceDesk, не важно по какой причине и вы не можете его восстановить. Алгоритм действий был такой при восстановлении. Вы удаляли текущий ManageEngine ServiceDesk, потом заново его переустанавливали. Запускали в командной строке скрипт восстановления C:\ManageEngine\ServiceDesk\bin\restoreData.bat, указывали файлы вашей резервной копии и уходили готовить себе кофе, так как данный процесс длился так же часа 3-4, и это у меня на SSD дисках, страшно подумать сколько бы это заняло времени, если бы это было на обычных SATA HDD. Как видите данная схема резервного копирования узкое место, так как:

  • Вы постоянно напрягаете ваши диски при моменте создания резервной копии
  • Долго ее ждете
  • Требуется лишнее время
  • Долгое время восстановления, где нет гарантий, что архив не повредится или вообще задание выполнится

Восстановление ManageEngine ServiceDesk

Что предлагаю я

Если у вас ManageEngine ServiceDesk все еще располагается на физическом железе, то я вам советую установить гипервизор VMware ESXI 6.5 или выше. Далее я вам советую мигрировать вашу физическую машину в виртуальную, так называемая P2V миграция. Удобство данного варианта в том, что у вас как минимум пропадает привязка к железу. Далее я вам советую, чтобы ваша база данных ManageEngine ServiceDesk располагалась на другом виртуальном или физическом сервере. Вам осталось теперь наладить регулярное резервное копирование БД ServiceDesk и раз в день, бэкапить виртуальную машину с приложением. Теперь в момент аварии вы максимум потратите минут 30-35 на восстановление всей этой инфраструктуры, так как их можно делать параллельно и резервное копирование будет идти в разы быстрее. Бэкапить виртуальные машины ESXI лучше через Veeam Backup Replication.

Где отключить встроенные задания бэкапа

Открываете админку ManageEngine ServiceDesk и переходите в раздел "Общие параметры - Архивирование данных"

Отключение бэкапа ManageEngine ServiceDesk

Снимите галку "Активировать запланированную Архивацию Данных".

Отключение бэкапа ManageEngine ServiceDesk-2

Когда приложение в работе, то оно создает кучу архивов по одному гигабайту.

список архивов при бэкапе ManageEngine ServiceDesk

Благодаря такой политике резервного копирования вы снизите нагрузку на дисковую подсистему вашего сервиса и ускорите процесс восстановления при аварии. На этом у меня все, с вами был Иван Семин, автор и создатель портала Pyatilistnik.org.

Оцените статью
Настройка серверов windows и linux
Добавить комментарий

  1. Александр

    Эти архивы из бекапа да, создаются по умолчанию в директории Service Desk, но по финалу бекапа должны вынестись в папку «backup».
    То что они там остаются после завершения задания бекапа говорит скорее всего о том что прошел он не гладко и надо взглянуть на логи.

    Кстати у них сейчас есть на линуксе сервер, на 8й версии не было, работает побыстрее, но с винды туда не очень удобно мигрироваться конечно..

    Снепшот VM проще и быстрее) тут вопросов нет

  2. Дмитрий

    Архивирование данных это не резервное копирование, а перенос заявок в архив, из базы в отдельную папку, по сути это история, что бы база не росла.