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

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

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

ЕЩЕ БОЛЬШЕ ПОЛЕЗНОСТЕЙ У НАС В TELEGRAM

Чек-листы

Готовые промты

Таблицы для генерации контента

ПЕРЕЙТИ В TELEGRAM

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

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

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

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

1. Вкладка импорта пользователей в ISP Manager 5.

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

Причины:

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 файла вместе в архиве (в случае если сайт небольшой) – мы получали ошибку вида:

2. Ошибка

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

3. Ошибка

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

Попытка #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. Т.к. базовая версия архива не является самой свежей, то необходимо распаковать остальные инкрементальные архивные части и добавить их в базовую версию, переписав изменённые файлы.

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

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

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