Справка

Бэкапы

Система позволяет сделать четыре вида бэкапов:

  • Архивация всей системы целиком (ядро, данные, файлы)
  • Только ядро
  • Только данные
  • Только файлы

Можно настроить автоматическую архивацию файлов и данных раз в сутки. Также можно настроить максимальное количество архивов (старые архивы будут удаляться).

Система запаковывает бэкапы тремя способами (в зависимости от их вида):
gzip, tar, php-self-extractor.

Последний полезен для запаковки ядра или всей системы целиком.

Откат до бэкапа

Для отката системы до нужного бэкапа, необходимо в разделе настройки поменять название базы данных. После этого появится диалог загрузки дампа. Кроме этого, можно откатиться до “чистой” системы (вариант данных, с которого система была установлена). Такой автоматический откат возможен только для базы данных. Для отката файлов или ядра используйте ручную распаковку.

Перенос системы с сервера на сервер

Используя первый вид бэкапа (архивация всей системы целиком) пользователь получает объёмный PHP-файл, содержащий в себе запакованные данные и инструкции по распаковке для сервера.

По сути, действия пользователя в этом случае сводятся к получению архива на одном сервере и копированию этого архива на другой сервер. Далее, при первом доступе к конечному сайту (на сервере-приёмнике), происходит распаковка архива.

Если по каким-то причинам распаковка невозможна, пользователь увидит соответствующую ошибку. В этом случае можно воспользоваться переносом системы с помощью TAR-архива (который необходимо “руками” распаковать на сервере-приёмнике).

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

Удалённая установка на сервер

В некоторых случаях можно воспользоваться сервисом удалённой установки. Для этого необходимо ввести FTP и MySQL реквизиты сервера-приёмника, после чего система попытается закачать архив через FTP и произвести его распаковку и установку.

Клонирование системы

Сервис переноса системы можно использовать для создания клонов.

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

При этом сервером-обновлений для клиентов будет являться центральная система.

В некоторых случаях необходимо иметь цепочку систем. Dev => Prod => Clients.

В этом случае первая (Dev) система служит площадкой для разработчиков.

С неё обновляется вторая (Prod) система. Обновляя только нужный функционал, который необходимо сделать доступным для всех клиентов.

А уже с этой системы обновляются все остальные (Clients).

Создавая публичный модуль, который планируется распространять таким образом, разработчики обязаны обеспечить бесшовное обновление для пользователей. Если планируются серьёзные изменения, которые нарушают целостность пользовательских данных, то такой функционал рекомендуется создавать в качестве дочернего модуля.

Также, при создании клона системы, можно указать другой сервер обновлений (например, главный сервер обновлений http://rucms.org/new/update_server).



Читать далее про "Работа под нагрузкой"