chain doc dot ok back item-arrow angle-left angle-right vk instagram linkedin facebook play-button mail-ic winged-letter nda
Все статьи Бизнес-wiki

Восстанавливаем сайт из резервной копии ISP Manager

Святослав Волков
Задать вопрос

Ситуация: никому не пожелаешь. Сервер с сайтами клиентов перестает отвечать в середине рабочего дня. Клиенты ведут рекламные кампании, поэтому первым делом останавливается реклама и параллельно разворачивается кампания «Попробуй узнай, что случилось, а лучше исправь». Хостинг не выходит на связь, и ты начинаешь чувствовать, что пауза в работе может затянуться.

Через час безуспешных попыток добиться от хостинга вразумительного ответа, принимается решение - экстренно разворачивать сайты на другом, рабочем сервере.

Мы справились с реанимацией сайтов за 3 часа. Если бы у нас была эта инструкция, «подняли» бы их быстрее. Предполагаем, что наш опыт будет полезен коллегам в экстренных ситуациях.

Итак, на упавшем сервере стоит/стояла панель ISP Manager, инкрементальная резервная копия сохраняется каждый день во внешнее облако. Инкрементальность резервной копии заключается в том, что раз в неделю делается полная резервная копия пользователя на сервере (в том числе и сайтов), а в течение недели изменения дописываются в последующие ежедневные копии.

Казалось, все хорошо – резервная копия есть, выполнена в ISP Manager и сайты будут развернуты на другом сервере, где есть ISP Manager.

Попытка #1. Пытаемся сделать импорт пользователя через ISP

 Это не работает. 

Причины:

  1. Пункты: «URL архива», «из панели управления ISPmanager 5 (через rsync)», «из панели управления ISPmanager 5 (через backup)» отбрасываем, т.к. сервер-источник отключен.
  2. Пункты: «из локального архива ISPmanager 4» и «из панели управления ISPmanager 4» также не подходят, т.к. мы работаем с последней версии ISP 5.
  3. Остаются только пункты: «загрузить архив» и «из локального архива или каталога». По сути это одно и тоже, только в первом случае мы сразу загружаем архив резервной копии прямо с нашего компьютера, а во втором предварительно загружаем архив в определенную папку на принимающем сервере.

НО чтобы мы не делали у нас не получалось восстановить архив.

В каждой архивной версии содержится три и более файла:

  • 2020-02-11.user_name.info – содержит информацию о текущем архиве, об этом чуть ниже в пункте 2 «Ручное извлечение архивной версии сайта».
  • 2020-02-11.user_name.tgz – содержит полный перечень файлов, входящих в архив.
  • F2020-02-11.user_name.tgz – собственно, архив всех файлов, базы данных и других данных пользователя, неполная версия – инкрементальная вместо буквы F в начале имеет букву I.

В случае если архив занимает более 100 Мб, то он дробится на части:

  • F2020-02-16. user_name.tgz.part1
  • F2020-02-16. user_name.tgz.part2
  • F2020-02-16. user_name.tgz.partN

Где partN – порядковый номер части архива, а user_name – имя пользователя в ISP.

При попытках загрузить каждый файл по отдельности или загрузить все 3 файла вместе в архиве (в случае если сайт небольшой) – мы получали ошибку вида:

Хотя версия ISP донора и версия ISP акцептора совпадают: ISPmanager Lite 5.232.2.

А в случае если мы грузим большую архивную версию сайта, например, сайт размером ~25 Гб, то загрузка/распаковка зависала на 100% и дальше не двигалась.

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

Попытка #2. Извлекаем резервную копию сайта вручную из backup ISP

 Это работает.  Особенно с большими сайтами.

  1. Сначала открываем *.info – файл последней свежей версии архива. Его содержание примерно такое:
     
    base= user_name/2020-01-05/F2020-01-05.user_name.tgz
    created=2020-01-10 03:17:17
    duration=38
    finished=2020-01-10 03:17:55
    last-slice= user_name/2020-01-10/I2020-01-10.user_name.tgz
    type=incremental
    
    Это означает, что перед нами инкрементальная версия архива сайта (т.е. только лишь зафиксированные изменения, а не полностью весь архив пользователя). На это указывает параметр
    type=incremental
    (для полной версии архива мы бы увидели: type=full), а параметр
    base= user_name/2020-01-05/F2020-01-05.user_name.tgz
    указывает нам, где можно найти свежую версию архива со всеми файлами от которой можно будет отталкиваться.
  2. Скачиваем базовую и инкрементальные версии архива до ближайшей к нам дате.
  3. Т.к. сайт большой, то базовая версия архива содержит 251 часть и мы имеем множество файлов, оканчивающихся на *.tgz.partN (где N – порядковый номер архивной части). Чтобы объединить все архивы в один, можно воспользоваться стандартной консольной утилитой TAR на *Unix-системах – побитное склеивание файлов (MAC/Linux - устройства):
    cat ./F2020-02-11.user_name.tgz.part1 ./F2020-02-11.user_name.tgz.part2 > tar -xz

    на PC можно использовать Total Commander, выполнив команду «Собрать файл» в пункте меню «Файлы»:

    Для этого необходимо выбрать файл, оканчивающийся на part1, кликнуть по «Собрать файлы…», и вы получите единый архивный файл.

  4. Сборка даст единый файл вида «F2020-02-11.user_name.tgz», разархивировав который, получим файл вида «F2020-02-11.user_name.tar», который также необходимо разархивировать.
  5. В корне распакованных файлов будет две папки .system – где содержатся все базы данных, закрепленные за текущим пользователем, и папка «data» внутри которой по пути /data/www/site_name.ru содержатся файлы сайта.
  6. Т.к. базовая версия архива не является самой свежей, то необходимо распаковать остальные инкрементальные архивные части и добавить их в базовую версию, переписав изменённые файлы.

Важно: резервные копии баз данных не создают инкрементальных частей – каждый раз база данных архивируется полностью, поэтому при ручном восстановлении базы данных достаточно распаковать последний выполненный архив системой ISP Manager.

Бонус! Распаковка зашифрованного архива

Если Вам «исключительно» повезло и Ваша резервная копия зашифрована, то предстоит сделать следующее:

  1. Выполнить расшифровку каждого файла в отдельности в *Unix-системе (адекватного метода расшифровки в Windows-системах мы не нашли):
    openssl enc -aes-256-cbc -d -in ./I2020-02-11.user_name.tgz.aes.part1 -out ./I2020-02-11.user_name.tgz.part1 -pass pass:********
  2. Побитно склеить каждый файл:
    cat ./I2020-02-11.user_name.tgz.part1 ./F2020-02-11.user_name.tgz.part2 > ./I2020-02-11.user_name.tgz
  3. И собственно произвести распаковку архива.

В итоге

Бонусный вариант нам не достался – архивы не были зашифрованы, поэтому мы за 30 минут выкачали все необходимые части архива, собрали их в один, распаковали и развернули на новом сервере. Сменили A-записи на NS-серверах Yandex и через 15 минут сайты начали открываться по новому месту прописки. Ура!

UPD. С момента падения сервера прошла неделя, но вразумительного ответа от хостинг-компании нет: сервер так и не работает. Вскоре выяснилось, что сервер отключен за неуплату со стороны более крупной хостинг компании, у которой наш «хостинг» брал их в аренду.