Как расшифровать бэкапы, зашифрованные ISPmanager? С версии 5.52.0 используется система резервного копирования на базе ISPtar. И как оно работает?

В ISPmanager версии 5.52.0 и старше, реализована новая система резервного копирования, построенная на основе некоей ISPtar. И работает она... своеобразно. Попробуем разобраться, как именно.

В двух словах

В новой версии нет почти никаких настроек. Все работает (или не работает) само. Если у вас есть доступ в панель, то восстановление происходит очень удобно прямо из нее. Достаточно зайти в систему из-под нужного пользователя, выбрать файл за нужную дату и нажать "Восстановить." Хотя производитель производитель рекомендует иметь столько свободного места, сколько "весят" все Пользователи вместе взятые, по факту для восстановления одного маленького файла из удаленного требуется не более 100 МБ.

Бэкапы создаются настолько сложно странно, что их расшифровка превращается в квест. Все это хорошо работает, если у вас есть доступ в панель, но неудобно во всех остальных случаях.

Чуть подробнее

Создание бэкапов происходит по пользователям. Все данные каждого пользователя (настройки, файлы, базы данных) архивируются, разбиваются на части объемом 100 МБ. и заливаются в Хранилище. Хранилищем может быть как локальный диск, так и удаленный FTP/sFTP, Яндекс-диск и другие облачные сервисы (по личному опыту, все облака непредсказуемо глючат, и вообще-то это неудивительно). Раз в неделю по воскресеньям создается Полный Бэкап, во все остальные дни недели -- инкрементный. Хранится N полных бэкапов, и M инкрементных, и вот это можно настроить. Еще можно настроить шифрование всех архивов с бэкапами, и если вы так и сделали , то скорее всего именно поэтому и читаете эту статью.

Как восстанавливается бэкап, созданный в ISPmanager 5.52 или старше?

Предполагается, что полностью автоматически, для чего в соответствующем разделе из-под нужного нужного пользователя вы можете выбрать дату восстановления и нужные файлы, а после нажать кнопку: "Восстановить". В панели хранится "индекс" всех полных и инкрементных бэкапов, поэтому она каким-то образом выберет и скачает из Хранилища только нужный файл, расшифрует его и восстановит.

Соседняя кнопка «Скачать» на этом этапе работает гораздо менее легко (для случая использования удаленного FTP в качестве Хранилища). Мы немного разобрались с этим.

Что происходит при нажатии «Скачать»

Панель скачивает файлы из Хранилища и в директории /usr/local/mgr5/var/backup/ispmgr слепляет их в один файл, после чего отдает вам ссылку на результат. Этот процесс :

  • требует наличия свободного дискового пространства в объеме, как минимум, объем данных этого пользователя + 100 МБ. + объем самого большого файла в инкрементной части архива;
  • занимает трафика в объеме 2х(объем данных пользователя), что при объемах скажем в 10 ГБ. становится уже вполне затратно по времени.

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

Как восстановить нешифрованные файлы вручную?

Самый простой вариант -- заранее позаботиться о том, чтобы у вас всегда была какая-то панель под рукой. Тогда проще будет импортировать бэкапы в нее и восстановить. Для этого можно поднять виртуальную машину с CentOS и установить на нее бесплатную версию.

Итак, при создании резервной копии, панель разбивает архив части объемом в 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*, достаточно побитно слить все файлы вместе. Если ваши архивы не шифрованы, то вы можете сделать это по инструкции из документации, а потом разархивировать получившийся файл любыми средствами и получить доступ к файлам.

А если ваши архивы шифрованы, то...

Как восстановить шифрованные файлы вручную?

Если вы настроили шифрование, и объем бэкапа < 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 , и просто закидывать шифрованный файл на него. После ввода пароля, рядом с исходным файлом появится его расшифрованная версия:

.bat файл для автоматизации AES-расшифровки
  1. @ECHO OFF
  2. set target=%~1
  3. set extension=%target:~-3,3%
  4. set decrypted=%target:~0,-4%
  5. IF EXIST "%decrypted%" GOTO fileexists
  6. C:\OpenSSL-Win32\bin\openssl enc -d -aes-256-cbc -in "%target%" -out "%decrypted%"
  7. PAUSE
  8. EXIT
  9.  
  10. :fileexists
  11. echo Error: %decrypted% already exists.  Delete it and re-try.
  12. PAUSE
  13. 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 почему-то отказывается корректно дешифровывать "тома", поэтому единственный известный автору способ восстановления многотомного шифрованного архива -- через консоль. Для этого файлы придется залить файлы на сервер, а затем выполнить примерно следующие команды:

Дешифровка, придется повторить ее для каждого файла:
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, но при использовании квот надо быть уверенным, что каждому из ваших пользователей доступен соответствующий дисковый объем (поскольку, как сказано в документации, резервирование происходит с правами пользователя). Метод мы еще не проверяли, но, наверное, это не будет иметь негативных последствий. Положительный эффект в том, что, во-первых, число томов архивов уменьшится, а, во-вторых, инкрементные архивы с большей степенью вероятности будут умещаться в одном томе, что избавит от необходимости морочной расшифровки.

Блог

Как отресайзить картинки батчем?

Все фотографии, которые вы собираетесь отресайзить, должны быть в одной директории, скажем «uploads». Внутри нее можно сохранить любую структуру директорий. Мы научимся создавать копию этой директории, внутри которой все картинки будут отресайзены, причем только в сторону уменьшения разрешения.

далее

Tilda Module: интеграция NetCat с Tilda.cc

Представляем нашу новую разработку, модуль интеграции CMS NetCat с платформой Tilda.cc. Модуль дает возможностью полуавтоматически размещать классные лендинги прямо в структуре вашего сайта!

далее

Как оптимально заархивировать файлы, чтобы распаковать их средствами ISPmanager?

В определенных случаях файлы выгоднее заливать на веб-сервер в виде архива. Во-первых, если данные хорошо сжимаются, или же просто файлов очень много, это сократит время заливки. Во-вторых, в любом случае это обезопасит данные от случайного повреждения, так как при распаковке архива происходит проверка его целостности с помощью контрольной суммы (CRC). Однако, не вполне понятно, какой формат архива и тип сжатия выбирать? Мы провели небольшое экспериментальное исследование на эту тему.

далее

Как расшифровать бэкапы, зашифрованные ISPmanager?

В ISPmanager версии 5.52.0 и старше, реализована новая система резервного копирования, построенная на основе некоей ISPtar. И работает она... своеобразно. Попробуем разобраться, как именно.

далее

Весь блог тут