02.05.2012
Данная статья – повествование о том, как сильно разошлись наши представления и проектная документация и суровая реальность в виде готового приложении для бекапирования (а при необходимости и переноса на новый хостинг) сайтов на Bitrix .Net Forge CMS. Сразу оговорюсь, что на момент написания статьи приложение не было закончено и находилось в режиме закрытого тестирования.
Согласно первоначальной задумке функционал инструмента бекапирования для .Net Forge CMS не должен кардинально отличаться от функционала 1С-Битрикс: управление сайтом (php линейка), а наоборот дополнять его возможностью задания периодического бекапирования (аналог постановка задач для CRON с помощью агентов). Один из первых схематичных набросков (который готовили для себя) выглядел вот так:
Очень многое сразу пришлось делать совершенно иначе, пришлось на первой итерации разработки отказаться от агентов, пришлось слегка изменить внешний вид маски исключений в силу различий в синтаксисе инструментов бекапирования.
На одной из ранних стадий разработке по инициативе ведущего разработчика была предпринята попытка отказаться от шагов бекапирования – приложение не взлетело. Даже на виртуальном сервере приложение банально повисало или отваливалось по таймауту, не говоря уже про виртуальный хостинг. Шаги вернули.
В процессе разработки из-за небольшого непонимания резервные копии стали складывать не в /bitrix/backup/, а в /backup/, что не является критичным на мой взгляд и мы просто закрыли на это глаза.
А вот удобный инструмент индикации прогресса (с указанием размера обработанных данных и количества оставшихся файлов), привычный многим пользователям БУС пока не может быть реализован в рамках .NET Forge. Остановились на простом прогресс-баре, который крутится до бесконечности пока не завершится процесс создания резервной копии и который просто показывает, что процесс идёт.
Как можно заметить, пункт с бекапированием ядра стал в нашем случае обязательным. Мы пришли к выводу, что существует 2 основных сценария инструмента бекапирования:
- Создание полной копии (с базой данных) для последующего восстановления в нештатной ситуации или переноса на новый хостинг.
- Создание копии ядра для быстрого запуска идентичный проектов командой разработчиков (например, чтобы не переносить модули)
Сценарий с резервным копированием только БД, только публички или любого из этих компонентов без ядра был признан маловероятным. Мы прекрасно понимаем в каких ситуациях это может быть необходимо, однако в настоящий момент для таких процедур кажется более целесообразным использование файлового копирования через RDP, FTP или резервного копирования БД силами MS SQL Server. Если вы испытываете большую потребность в подобном функционале, для вас не составит труда написать маску исключения или изменить исходный код приложения. В случае, если задача будет встречаться часто мы готовы взять на себя работу по внесению соответствующих изменений в новом релизе.
Так же в окончательном релизе скорее всего пропадёт возможность пропуска символических ссылок (мы считаем данный сценарий достаточно экзотичным даже для многосайтовости на БУС php линейки, не говоря про .NET Forge CMS).
Как можно заметить первый рабочий вариант инструмента бекапирования уже значительно отличается от своего сородича для php линейки продуктов 1С-Битрикс.
На момент написания статьи шло закрытое тестирование решения. Если вас заинтересовало то, о чём говорится в статье и вы хотите внести свой вклад – мы будем рады предоставить вам возможность совместного тестирования на наших плошадках, либо все необходимые инструменты для автономного проведения эксперимента.
P.S. да, форма генерации имени бекапа так же отличается. В данном случае используется имя корневой дирректории файла, а так же дата и время создания копии, что позволяет исключить корелляции, однако мы отказались от механизма добавления "соли" в название, чтобы имя резервной копии было читабельным и его можно было набирать вручную.
