3. Обслуживание системы
Система запущена на серверном оборудовании, которое подвержено износу и поломкам, не зависящим от программного обеспечения, развернутого на нем.
Очень важно иметь и поддерживать в актуальном состоянии резервные копии и уметь правильно восстановить систему с минимальными потерями.
Опишем части системы и меры по обеспечению их сохранности в случае сбоя
3.1. Операционная система с зависимостями
После установки системы на ваших серверах необходимо создать копию настроенной виртуальной машины. Вы можете оставить ее и скопировать все данные из директории, куда она установлена в безопасное место. Это разовая операция, зависит от средств виртуализации и подробно описывать ее не не будем.
3.2. Исходный код системы
С момента запуска системы и установки обновлений и доработок, исходный код не менятся, он находится под системой управления версиями [git](https://git-scm.com) Необходимо поддерживать несколько мест, где хранится репозиторий с актуальными доработками. Мы вам предоставим нашу копию (СтретоСфера) репозитория
3.3. База данных
База данных изменяется при работе системы. Важно хранить и актуализировать состояние базы данных за пределами рабочего сервера. Есть 2 способа резервного копирования баз данных:
Полный когда создается полная копия базы данных в виде файла и перемещается в безопасное место. Эту процедуру время от времени нужно повторять. Для больших баз данных этот способ подходит плохо, потому что:
Файл занимает место, сопоставимое с размером самой базы данных
При создании значительно нагружает базу данных и систему в целом
При восстановлении получим достаточно старый слепок данных, зависящий от периодичности
При этом, это простой способ, не требующий особых настроек. Восстановление из такой копии происходит относительно быстро.
Инкрементный когда делается полная копия базы данных, и все изменения, которые происходят после этого, сохраняются в виде небольших (16 Мб по умолчанию) файлов лога
При восстановлении, необходимо восстановить данные из полной копии и дополнительно применить к ней все изменения, которые происходили после того, как эта копия была создана.
Примечание
При работе, СУБД все изменения базы хранит в оперативном логе (xlog) По умолчанию, эти несколько файлов лога, которые выделены СУБД, переиспользуются по кругу. После заполнения очередного файла, СУБД затирает самый старый и начинает писать в него и так по кругу. Предусмотрен режим работы с архивацией логов, когда заполненные файлы с логом можно скопировать в безопасное место (на другой сервер). При восстановлении, можно шаг за шагом применить то, что делала СУБД. В этом случае, тставание данных будет тем меньше, чем более интенсивное изменение данных (логи наполяются быстрее и уходят на архивацию). В то время, когда сервер выполняет мало работы и файлы лога наполняются не очень интенсивно и рекомендуется в конфигурации задать время, в течении которых лог пойдет на архивацию, даже ели будет не до конца заполнен.
Операция восстановления в этом случае будет занимать больше времени, но зато позволит уменьшить отставание данных при восстановлении до нескольких минут. Более подробно о этом можете прочитать в разделе СУБД PostgreSQL
3.4. Файлы пользователей
При работе системы, пользователи загружают файлы, прикрепляют их к карточкам документов.
Все эти файлы хранятся в директории media в корне системы в директориях по /media/<year>/<month>/<day>/
Необходимо настроить копирование этих файлов в безопасное место по расписанию.
Описание приведем чуть ниже.
Более подробно о этом можете прочитать в разделе Файлы