Новый взгляд на резервное копирование в версии 12.0

Друзья, приветствую!

Хочу рассказать о том, что изменилось в системе резервного копирования 12.0. Улучшена архитектура, оптимизированы алгоритмы, добавлены фичи. Всё это не очевидно для пользователя. Но могу сказать, что это самое значимое обновление резервного копирования с момента его появления в 5-й версии. Помимо новых суперских фич мы изменили концепцию.
[spoiler]

До сих пор мы предлагали своего рода конструктор бэкапа, который позволял при уверенном знании архитектуры битрикса получать разные формы бэкапа для различных узкоспециализированных задач. Но для простого пользователя это часто приводило к проблемам выбора правильных настроек.


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



При этом вся гибкость настройки осталась, но теперь она не будет путать обычного пользователя:



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

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

Тогда мы сказали себе, что надо чтобы любой пользователь мог создать полноценный бэкап и был спокоен за свои данные.


Так появился облачный бэкап 1С-Битрикс

Нам потребовалось создать действительно сложное технологическое решение чтобы это было просто для пользователя. Задачи, которые мы решили для этого:

- человек должен быть спокоен, что случайные люди не получат бэкап по прямой ссылке (помним про мегафон),
- сотрудники 1С-Битрикс не должны иметь доступ к пользовательским данным,
- создание бэкапа должно быть действительно простым, без сложных процедур активаций, заполнения форм и пр.
- увольнение администратора сайта не должно создавать дополнительные трудности,
- старый администратор (или разработчик) не должен иметь доступ к свежим бэкапам,
- восстановление из бэкапа должно быть возможно на новом месте без каких-то затруднений.

Это вообще возможно?

Нет, сказали разработчики Сергею Рыжикову, но если создать небольшие затруднения, то можно... Нет, сказал Сергей Рыжиков, подумайте... Через несколько итераций появилось решение


С самого начала было ясно, что нужно научиться шифровать бэкапы. При этом сохранить пошаговость, скорость, возможность сжатия. Потребовалось серьезно оптимизировать алгоритмы работы с файлами. В результате теперь зашифрованный бэкап создается в 2 раза быстрее (!), чем раньше незашифрованный. Требуется php модуль MCrypt.

Теперь вопрос: как не дать получить архив (чтобы избежать возможность брутфорса), не зная его пароль? Нужно хранить пароль пользователя. Но нельзя, все шифрование должно без нашего участия проходить на стороне пользователя. Тогда мы решили следующее: при создании бэкапа на наш сервер передается хеш пароля пользователя, который позволяет проверить корректность пароля, но не дает возможности распаковать архив.

При этом список резервных копий привязывается к лицензионному ключу (для многосайтовой установки облачное хранилище будет общее). А вот задачка: если временный разработчик утянул ключ, он не должен иметь возможность переполнить хранилище этого ключа. Мы решили этот вопрос используя алгоритм системы обновлений: записывать резервные копии можно только с оригинально установки (но допускается еще одна копия для разработки). Повторный ввод ключа блокирует запись бэкапа.



Резюмирую сказанное

Бэкап в облако 1С-Битрикс создается на основе лицензионного ключа (он должен быть активен) и пароля пользователя.
Для восстановления из бэкапа нужно ввести ключ и пароль этого конкретного бэкапа (для каждой резервной копии можно задать свой пароль).
Пароль шифрования бэкапа никуда не уходит с сервера, где работает сайт. Таким образом, без знания этого пароля восстановить бэкап не удастся.

Для проверки стойктости шифрования мы сделали скрипт перебора паролей. На современной офисной машине перебирается порядка 10 000 паролей в секунду. Т.е. пароль из 6 знаков, состоящий только из цифр, подбирается влёт. Но если добавить хотя бы один знак препинания, то перебор займет несколько недель в многопоточном режиме.
Пароль более 8 символов со знаками препинания будет подбираться годами.

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

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



Очень скоро


Есть прототип, который позволит создавать бэкапы из консоли (с использованием cron) и отправлять их в облака. Вы получите возможность автоматического создания бэкапов, полностью совместимых с restore.php.

На этапе тестирования мы сформировали ряд пожеланий, которые сделают процесс создания бэкапов еще понятнее, проще и нагляднее, будем внедрять.