Как расшифровать бэкапы, зашифрованные ISPmanager? В версии 5.52.0 и старших используется система резервного копирования на базе ISPtar. И как оно работает?
В ISPmanager версии 5.52.0 и старше, реализована новая система резервного копирования, построенная на основе некоей ISPtar. И работает она... своеобразно. Попробуем разобраться, как именно.
В двух словах
В новой версии нет почти никаких настроек. Все работает (или не работает) само. Если у вас есть доступ в панель, то восстановление происходит очень удобно прямо из нее. Достаточно зайти в систему из-под нужного пользователя, выбрать файл за нужную дату и нажать "Восстановить." Хотя производитель производитель рекомендует иметь столько свободного места, сколько "весят" все Пользователи вместе взятые, по факту для восстановления одного маленького файла из удаленного требуется не более 100 МБ.
Бэкапы создаются настолько сложно странно, что их расшифровка превращается в квест. Все это хорошо работает, если у вас есть доступ в панель, но неудобно во всех остальных случаях.
Если вы пришли сюда потому, что вам нужно расшифровать свои бэкапы из-за уже случившегося сбоя, то у вас есть два варианта:
- прочитать всю статью целиком и сделать это самостоятельно, поняв принцип. Это займет от 3 часов до недели, в зависимости от ваших навыков;
- обратиться к нам, и мы это сделаем за 1-2 рабочих дня.
Стоимость услуги:
- расшифровка 1 зашифрованного архива до 10 ГБ. -- 6000 руб.
- каждые следующие 10 ГБ., и каждый следующий архив по 2500 руб.
Масштабные запросы обсуждаются на индивидуальных условиях.
Невозвратная предоплата составляет 1000 руб., на случай, если архив не раскроется (сами файлы бэкапов битые или неверный пароль), что, увы, можно узнать только в самом конце работы.
Выполнение работ в выходные и праздничные дни возможно, стоимость повышается не менее чем на 20%, но окончательно обсуждается индивидуально.
Чтобы получить услугу, убедитесь, что у вас есть файлы бэкапов и пароль к ним, и после этого позвоните или напишите нам (контакты в шапке сайта).
Чуть подробнее
Создание бэкапов происходит по пользователям. Все данные каждого пользователя (настройки, файлы, базы данных) архивируются, разбиваются на части объемом 100 МБ. и заливаются в Хранилище. Хранилищем может быть как локальный диск, так и удаленный FTP/sFTP, Яндекс-диск и другие облачные сервисы (по личному опыту, все облака непредсказуемо глючат, и вообще-то это неудивительно). Раз в неделю по воскресеньям создается Полный Бэкап, во все остальные дни недели -- инкрементный. Хранится N полных бэкапов, и M инкрементных, и вот это можно настроить. Еще можно настроить шифрование всех архивов с бэкапами, и если вы так и сделали , то скорее всего именно поэтому и читаете эту статью.
Как восстанавливается бэкап, созданный в ISPmanager 5.52 или старше?
Предполагается, что полностью автоматически, для чего в соответствующем разделе из-под нужного нужного пользователя вы можете выбрать дату восстановления и нужные файлы, а после нажать кнопку: "Восстановить". В панели хранится "индекс" всех полных и инкрементных бэкапов, поэтому она каким-то образом выберет и скачает из Хранилища только нужный файл, расшифрует его и восстановит.
Соседняя кнопка «Скачать» на этом этапе работает гораздо менее легко (для случая использования удаленного FTP в качестве Хранилища). Мы немного разобрались с этим.
Что происходит при нажатии «Скачать»
Панель скачивает файлы из Хранилища и в директории /usr/local/mgr5/var/backup/ispmgr
слепляет их в один файл, после чего отдает вам ссылку на результат. Этот процесс :
- требует наличия свободного дискового пространства в объеме, как минимум, объем данных этого пользователя + 100 МБ. + объем самого большого файла в инкрементной части архива;
- занимает трафика в объеме 2х(объем данных пользователя), что при объемах скажем в 10 ГБ. становится уже вполне затратно по времени.
Если вы спрашиваете, зачем это нужно (скачивать архив), то ответ простой. Не всегда нужно именно что-то восстанавливать на прежнее место, очень часто надо лишь посмотреть как оно выглядело раньше.
Как восстановить нешифрованные файлы вручную?
Самый простой вариант -- заранее позаботиться о том, чтобы у вас всегда была какая-то панель под рукой. Тогда проще будет импортировать бэкапы в нее и восстановить. Для этого можно поднять виртуальную машину с CentOS и установить на нее бесплатную версию ISP Manager.
Итак, при создании резервной копии, панель разбивает архив части объемом в 100 МБ. каждый. Это делается для того, чтобы упростить работу с файлами и, например, залить их на удаленный FTP. Мы не знаем как именно это работает, но благодаря этому резервная копия пользователя объемом 5ГБ. успешно заливается на удаленный FTP, когда на диске VDS свободно всего 1 ГБ. То есть вместо того, чтобы создать архив на 5 ГБ., а потом его залить, панель, видимо, создает кусочки по 100 МБ. и заливает их по одному.
На FTP содержимое архива выглядит примерно вот так:
- F2018-09-16.www-root.tgz.part1
- F2018-09-16.www-root.tgz.part2
- ...
Буква F означает, что это часть Полного (воскресного) бэкапа, далее идет дата, имя пользователя, расширение архива и номер "тома". Если же бэкап будет "будничный" инкрементный, файлы назовутся на букву: "I2018-09-16.www-root.tgz.part1" В таком бэкапе содержатся только изменения относительно предыдущего доступного бэкапа
Если весь бэкап будет объемом < 100 МБ., то имя будет "F2018-09-16.www-root.tgz", и его можно будет открыть как обычный архив без каких-либо дополнительных телодвижений. В противном случае, чтобы восстановить оригинальный файл F2018-09-16.www-root.tgz из нескольких .part*, достаточно побитно слить все файлы вместе. Если ваши архивы не шифрованы, то вы можете сделать это по инструкции из документации, а потом разархивировать получившийся файл любыми средствами и получить доступ к файлам.
А если ваши архивы шифрованы, то...
Вы прочитали уже почти всю статью, а значит вас она зацепила! Возможно, вам интересно будет узнать, что мы умеем не только писать статьи, но и разрабатывать необычные веб-проекты, вот такие, например:
- ERP, CRM и Автоматизация всего
- Разработка энциклопедий и баз знаний
- API, веб-сервисы, нестандартные проекты, информационные порталы на CMS NetCat
Весьма вероятно, что вы технический специалист, работа которого связана (внезапно! :)) с резервным копированием, поэтому вам также наверняка зайдет наш кейс Автоматизированная Система Управления Бэкапами. Ну и имейте в виду, что мы специализируемся на качественной техподдержке веб-ресурсов. Потому, собственно, эта статья и была написана.
Как восстановить шифрованные файлы вручную?
Если вы настроили шифрование, и объем бэкапа < 100МБ., то соответствующий файл будет выглядеть примерно вот так: F2018-09-16.www-root.tgz.aes. Чтобы его расшифровать, необходимо:
- либо сделать это на сервере, прямо из консоли ISP-менеджера примерно вот такой командой:
openssl enc -aes-256-cbc -d -in /var/www/www-root/data/www/test/I2019-02-01.www-root.tgz.aes -out /var/www/www-root/data/www/test/I2019-02-01.www-root.tgz -pass pass:********
- либо из Widnows с задачей справляется https://sourceforge.net/projects/openssl/ (и только она, другие утилиты на момент написания статьи не работали)
Для удобства, можете создать .bat , и просто закидывать шифрованный файл на него. После ввода пароля, рядом с исходным файлом появится его расшифрованная версия:
- @ECHO OFF
- set target=%~1
- set extension=%target:~-3,3%
- set decrypted=%target:~0,-4%
- IF EXIST "%decrypted%" GOTO fileexists
- C:\OpenSSL-Win32\bin\openssl enc -d -aes-256-cbc -in "%target%" -out "%decrypted%"
- PAUSE
- EXIT
- :fileexists
- echo Error: %decrypted% already exists. Delete it and re-try.
- PAUSE
- EXIT
Если же вы настроили шифрование, а объем бэкапа > 100МБ., то вас ждет неприятный сюрприз. Файловая структура будет выглядеть примерно следующим образом:
- F2018-09-16.www-root.tgz.aes.part1
- F2018-09-16.www-root.tgz.aes.part2
- ...
Если, следуя общей логике, вы сначала соедините части, а потом расшифруете, то расшифруется только первый "чанк" на 100 МБ., а дальше возникнет ошибка. Поясним: если на входе 2 файла, .part1 = 100МБ и .part2 = 50МБ, то после склейки удастся раскрыть ~66% архива.
Секрет в том, что, оказывается, надо сначала расшифровывать "тома", а потом сливать их. Это было бы более очевидно, если бы разработчики панели задали имя вида F2018-09-16.www-root.tgz.part1.aes для таких бэкапов.
На этом неприятности не заканчиваются. Упомянутый выше OpenSSL для Windows почему-то отказывается корректно дешифровывать "тома", поэтому единственный известный автору способ восстановления многотомного шифрованного архива -- через консоль CentOS (ну или другой схожей ОС). Для этого файлы придется залить файлы на сервер, а затем выполнить примерно следующие команды:
Дешифровка, придется повторить ее для каждого файла:
openssl enc -aes-256-cbc -d -in /var/www/www-root/data/www/test/I2019-02-01.www-root.tgz.aes.part1 -out /var/www/www-root/data/www/test/I2019-02-01.www-root.tgz.part1 -pass pass:********
Побитное склеивание файлов, можно выполнить прямо там же:
cat /var/www/www-root/data/www/test/F2019-02-01.www-root.tgz.part1 /var/www/www-root/data/www/test/F2019-02-01.www-root.tgz.part2 > /var/www/www-root/data/www/test/F2019-02-01.www-root.tgz.aes
Ежели на сервере не хватит места, придется расшифрованные файлы скачивать к себе, и склеивать под Windows:
copy /b F2019-02-01.www-root.tgz.part1 + /b F2019-02-01.www-root.tgz.part2 F2016-11-02.www-root.tgz
После этого, наконец, архив можно будет раскрыть.
Итого
Надеемся, панель уже никогда не поменяет всю эту логику. Ведь мы потратили пару дней, чтобы разобраться в ней.
Отметим, что для нивелирования неприятных особенностей работы с многотомными шифрованнными бэкапами, можно предпринять одно их двух:
- или отказаться от шифрования, если в копиях нет действительно важной информации :)
- или увеличить размер тома резервной копии через конфигурационный файл etc/ispmgr.conf. Поставить 200 МБ. можно командой
BackupSliceSize 200M
, но при использовании квот надо быть уверенным, что каждому из ваших пользователей доступен соответствующий дисковый объем (поскольку, как сказано в документации, резервирование происходит с правами пользователя). Метод мы еще не проверяли, но, наверное, это не будет иметь негативных последствий. Положительный эффект в том, что, во-первых, число томов архивов уменьшится, а, во-вторых, инкрементные архивы с большей степенью вероятности будут умещаться в одном томе, что избавит от необходимости морочной расшифровки.
Комментарии (1)
Петр (2020-07-30, 23:35)
Доброго вечера!
А какой пароль вводить???
root, того пользователя под ккоторым заевдено было? Или оно как то по другому паролилось?
Есть архив, пароль рута, а вот как бекап делался уже не помню.
Для бэкапа есть свой отдельный пароль. Если доступ в панель сохранился, его можно подсмотреть в разделе Инструменты -> Резервные копии, нажав на «глазик».
/usr/local/mgr5/etc/ispmgr.conf
. Можно перенести строку BackupToken arch_password=;path=/backup/;type=local
на другой сервер с установленной панелью, и тогда в её интерфейсе будет отображён пароль.Finar.