ERPNext на выделенном сервере: установка и требования по нагрузке

3. Что мы настраиваем и зачем

ERPNext — веб-приложение для управления бизнесом. В одной установке можно вести компании, контрагентов, счета, продажи, закупки, складские остатки, производство, проекты, сотрудников и финансовые операции. Система построена на Frappe Framework: пользователь работает через браузер, а сервер выполняет бизнес-логику, фоновые задачи и запросы к базе данных.

В руководстве используется типовая одноузловая архитектура. Все сервисы размещены на одном выделенном сервере: MariaDB хранит транзакционные данные, Redis обслуживает очереди и кеш, workers выполняют фоновые задания, а Nginx принимает HTTPS-соединения и передает запросы процессам Frappe. Такая схема подходит для первой production-инсталляции, если объем данных и число пользователей еще не требуют разнесения компонентов.

Что будет получено в конце

После выполнения шагов будет доступен сайт ERPNext с отдельным доменным именем, HTTPS-сертификатом и административным пользователем. Система будет запускаться автоматически после перезагрузки сервера, фоновые задачи будут выполняться через Supervisor, а доступ к MariaDB и Redis останется локальным.

В конфигурации предусмотрены базовые меры защиты: вход по SSH-ключу, отдельный sudo-пользователь, ограничение портов firewall, fail2ban, отсутствие публичного доступа к базе данных и автоматическое обновление сертификата Let’s Encrypt. Для production дополнительно следует настроить мониторинг, централизованное хранение логов и регулярные проверки восстановления.

Какие задачи решает ERPNext

• Продажи: лиды, коммерческие предложения, заказы клиентов, отгрузки и счета.
• Закупки: поставщики, заявки, заказы поставщикам, поступления и счета.
• Склад: склады, партии, серийные номера, перемещения и оценка запасов.
• Производство: спецификации, рабочие заказы, операции и списание материалов.
• Финансы: план счетов, платежи, проводки, налоги и отчеты.
• Проекты: задачи, трудозатраты, сроки и связь с клиентскими документами.
• HR: сотрудники, отпуска, посещаемость и базовые кадровые процессы.

Self-hosted и cloud-managed

В managed-облаке провайдер обычно берет на себя установку, обновления, TLS, резервные копии и часть мониторинга. Это сокращает операционные расходы команды, но ограничивает контроль над ОС, сетевой схемой, расписанием обновлений и способом хранения данных. Кроме того, стоимость managed-инсталляции обычно растет вместе с числом пользователей и объемом хранилища.

Self-hosted ERPNext на VPS или dedicated дает полный доступ к операционной системе и конфигурации. Администратор сам выбирает версию приложения, политику backup, сетевые правила и способ интеграции с внешними сервисами. Обратная сторона — ответственность за обновления, безопасность, восстановление и анализ производительности.

Для одной компании с несколькими десятками пользователей одноузловая установка обычно является разумной отправной точкой. Когда база становится большой, появляются тяжелые отчеты, массовые импорты или десятки фоновых процессов, архитектуру можно разделить: вынести MariaDB, Redis, workers и файлы на отдельные узлы.

Ограничения одноузловой схемы

Если сервер полностью выйдет из строя, одновременно будут недоступны веб-интерфейс, база и фоновые задачи. Поэтому наличие backup на том же диске не считается достаточной защитой. Минимально необходима внешняя копия базы и файлов, а для критичной системы — отдельный standby-сервер или регулярно проверяемая процедура восстановления на новом экземпляре.

4. Какой VPS-конфиг нужен под эту задачу

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

Минимальные параметры

Для лабораторной установки или небольшой компании подойдет сервер с 4 виртуальными CPU, 8 ГБ оперативной памяти и быстрым SSD объемом от 80 ГБ. Такой размер рассчитан примерно на 5–10 активных пользователей при умеренной нагрузке. Для демонстрационной среды можно начать с 2 vCPU и 4 ГБ RAM, но это не лучший вариант для production: MariaDB, workers и веб-процессы будут конкурировать за память.

В качестве практичной стартовой конфигурации для небольшой production-команды можно взять VPS с такими характеристиками: 8 vCPU, 16 ГБ RAM, NVMe от 160 ГБ, публичный IPv4-адрес и канал от 500 Мбит/с. Такой запас позволит выделить память MariaDB, запустить несколько web-процессов и сохранить пространство для журналов, файлов и backup-архивов.

CPU, память и диск

CPU требуется для обработки веб-запросов, сериализации данных, генерации PDF, импорта документов и фоновых задач. Частота одного ядра важна для интерактивного интерфейса, а количество ядер — для параллельных workers и нескольких пользователей. Если пользователи жалуются на задержку при открытии форм, а CPU постоянно занят, сначала проверьте медленные SQL-запросы и количество gunicorn-процессов, а не только увеличивайте тариф.

Оперативная память особенно важна для MariaDB и Redis. В системе с 8 ГБ RAM следует оставить запас минимум 1–1,5 ГБ для ОС, Nginx, Supervisor и временных операций. При включенном swap сервер может пережить кратковременный пик, но swap не заменяет RAM: постоянная работа через swap резко ухудшает задержку запросов.

Для ERPNext лучше использовать NVMe или другой SSD с низкой задержкой. Диск должен вместить операционную систему, базу данных, public- и private-файлы, логи, временные архивы и запас роста. Практическое правило — резервировать минимум в два раза больше текущего объема данных. Backup не следует хранить на том же разделе как единственную копию.

Сеть и IP-адрес

ERPNext не требует большого канала для обычной работы, но публичный IPv4 упрощает DNS, выпуск сертификата и интеграции. Для передачи файлов, резервных копий и массового импорта полезен канал от 100 Мбит/с. Веб-доступ должен идти через порты 80 и 443, SSH лучше ограничить по IP-адресам администратора или вынести за VPN.

Когда нужен dedicated

Выделенный сервер оправдан, когда система постоянно использует много CPU или RAM, требуется предсказуемая производительность диска, есть несколько больших компаний в одной инсталляции или на узле работают дополнительные сервисы. Он также удобен для ресурсоемких отчетов, массовой синхронизации с маркетплейсами, генерации большого количества PDF и хранения крупного файлового архива.

Если основная причина выбора dedicated — только опасение нестабильности VPS, сначала проверьте SLA и тип виртуализации. Хороший VPS с выделенными ресурсами и NVMe может быть достаточен для десятков пользователей. Dedicated становится особенно полезным при требованиях к физической изоляции, лицензированию, локальному RAID, большим объемам памяти или постоянной высокой загрузке.

Локация сервера

Регион влияет на задержку интерфейса, скорость загрузки файлов и соответствие требованиям к размещению персональных данных. Для сотрудников в одной стране выбирайте дата-центр ближе к ним, но проверяйте не только географическое расстояние, а реальную задержку и качество маршрутизации. Для интеграций с платежными системами, телефонией и внешними API следует дополнительно проверить доступность нужных адресов из выбранной сети.

5. Подготовка сервера

Ниже предполагается чистый сервер с Ubuntu Server 24.04 LTS, настроенной DNS-записью erp.example.com и доступом под пользователем, созданным провайдером. Команды выполняются от имени пользователя с правами sudo. Замените домен, имя пользователя и часовой пояс на свои значения.

Обновление системы и базовые утилиты

# Обновляем индекс пакетов и устанавливаем последние исправления
sudo apt update && sudo apt full-upgrade -y

# Устанавливаем инструменты администрирования и сборки
sudo apt install -y \
  git curl wget vim htop unzip jq ca-certificates \
  software-properties-common build-essential \
  python3-dev python3-pip python3-venv python3-setuptools \
  libffi-dev libssl-dev libmariadb-dev pkg-config

# Устанавливаем корректный часовой пояс
sudo timedatectl set-timezone Europe/Moscow

# Проверяем время, версию ядра и релиз Ubuntu
timedatectl
uname -a
lsb_release -a

ERPNext формирует даты и отчеты с учетом часового пояса сервера и настроек сайта. Для распределенной команды лучше заранее определить, будет ли сервер работать в UTC, или используется часовой пояс основной организации. Изменение timezone после появления документов может привести к путанице при анализе границ дня.

Создание отдельного пользователя

# Создаем системного пользователя для Frappe Bench
sudo adduser --disabled-password --gecos "" frappe

# Разрешаем пользователю выполнять административные команды через sudo
sudo usermod -aG sudo frappe

# Переключаемся на нового пользователя
sudo -iu frappe

# Проверяем владельца и домашний каталог
id
pwd

Не запускайте Bench от имени root. Отдельный пользователь ограничивает последствия ошибки в пользовательском приложении и упрощает управление правами. Команды, требующие изменения системных сервисов, выполняются через sudo, а команды Bench — от имени frappe.

SSH-ключи и отключение паролей

Сначала добавьте публичный ключ в /home/frappe/.ssh/authorized_keys. Если вы подключились под первоначальным пользователем, можно создать каталог и установить права так:

# Создаем каталог SSH и задаем безопасные права
sudo install -d -m 700 -o frappe -g frappe /home/frappe/.ssh

# Добавьте сюда собственный публичный ключ одной строкой
sudoedit /home/frappe/.ssh/authorized_keys

# Ограничиваем доступ к файлу ключей
sudo chown frappe:frappe /home/frappe/.ssh/authorized_keys
sudo chmod 600 /home/frappe/.ssh/authorized_keys

Проверьте вход в новой SSH-сессии до отключения паролей. Для защиты SSH можно создать отдельный drop-in-файл:

# Создаем настройки SSH без изменения основного файла
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
EOF

# Проверяем синтаксис и перечитываем конфигурацию SSH
sudo sshd -t
sudo systemctl reload ssh

Если SSH доступен из интернета, ограничьте его источниками, когда это возможно. Не закрывайте текущую сессию, пока не проверили новый вход. Потеря доступа из-за ошибочного правила firewall или SSH-конфигурации обычно требует консоли провайдера.

Firewall и fail2ban

# Устанавливаем firewall и защиту от перебора паролей
sudo apt install -y ufw fail2ban

# Разрешаем SSH, HTTP и HTTPS до включения политики deny
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Запрещаем остальные входящие соединения и разрешаем исходящие
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Включаем firewall и проверяем активные правила
sudo ufw enable
sudo ufw status verbose

# Запускаем fail2ban при загрузке и сразу активируем его
sudo systemctl enable --now fail2ban
sudo fail2ban-client status

Если SSH-порт изменяется, сначала разрешите новый порт в UFW и только затем перезапускайте SSH. Изменение номера порта само по себе не является полноценной защитой; ключевая защита — отключенный пароль, ограничение источников и мониторинг попыток входа.

Swap для небольшого сервера

Swap полезен как аварийный буфер во время импорта или кратковременного пика, особенно на сервере с 8 ГБ RAM. Для production с 16 ГБ памяти обычно достаточно swap-файла 2–4 ГБ, если нагрузка контролируется.

# Создаем swap-файл размером 4 ГБ
sudo fallocate -l 4G /swapfile

# Разрешаем доступ только root и включаем swap
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Подключаем swap после перезагрузки
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Проверяем состояние памяти и swap
free -h
swapon --show

6. Установка ПО — пошагово

В этом разделе устанавливается ERPNext 15 и Frappe Framework 15. Для production используем Python 3.12, Node.js 18 LTS, MariaDB 10.11 из репозитория Ubuntu 24.04, Redis из Ubuntu, Yarn и официальный установщик Bench через Python package. Перед началом проверьте актуальную матрицу совместимости Frappe для выбранного minor-релиза: версии зависимостей могут меняться между выпусками.

Установка MariaDB

# Устанавливаем сервер базы данных и клиентские библиотеки
sudo apt install -y mariadb-server mariadb-client libmariadb-dev

# Включаем MariaDB при загрузке и запускаем сейчас
sudo systemctl enable --now mariadb

# Проверяем состояние сервиса
sudo systemctl status mariadb --no-pager

# Запускаем интерактивное удаление небезопасных настроек
sudo mariadb-secure-installation

В мастере MariaDB удалите анонимных пользователей, запретите удаленный вход root и удалите тестовую базу. Root MariaDB будет использоваться локально для создания базы сайта, но доступ к нему не должен быть открыт по сети.

Для ERPNext нужны корректные кодировки и параметры InnoDB. Создайте отдельный файл конфигурации:

# Создаем параметры MariaDB, необходимые для Frappe
sudo tee /etc/mysql/mariadb.conf.d/60-erpnext.cnf > /dev/null <<'EOF'
[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
innodb-file-per-table = 1
innodb-large-prefix = 1
innodb-buffer-pool-size = 4G
max_connections = 200
EOF

# Перезапускаем MariaDB и проверяем отсутствие ошибок
sudo systemctl restart mariadb
sudo journalctl -u mariadb -n 50 --no-pager

Для сервера с 8 ГБ RAM значение innodb-buffer-pool-size следует уменьшить примерно до 2–3 ГБ. Не копируйте значение 4G на маленький сервер: база, workers и ОС должны иметь свободную память.

Установка Redis и Supervisor

# Устанавливаем очередь Redis и менеджер процессов
sudo apt install -y redis-server supervisor

# Включаем сервисы при загрузке
sudo systemctl enable --now redis-server supervisor

# Проверяем ответ Redis
redis-cli ping

# Проверяем состояние обоих сервисов
sudo systemctl status redis-server supervisor --no-pager

Ответ PONG означает, что Redis принимает локальные запросы. Внешний доступ к Redis не нужен. Проверьте, что в конфигурации Redis адрес прослушивания не открыт на публичном интерфейсе.

Установка Node.js 18 и Yarn

# Подключаем официальный репозиторий NodeSource для Node.js 18 LTS
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -

# Устанавливаем Node.js и npm
sudo apt install -y nodejs

# Устанавливаем Yarn для сборки frontend-ресурсов
sudo npm install --global yarn

# Проверяем версии инструментов
node --version
npm --version
yarn --version

Для Frappe 15 обычно используется Node.js 18 LTS. Если конкретный релиз ERPNext требует Node.js 20, следуйте его официальной таблице совместимости и не смешивайте произвольные версии. После изменения Node.js необходимо заново собирать assets через Bench.

Установка wkhtmltopdf

ERPNext использует wkhtmltopdf для части печатных форм и генерации PDF. В репозитории Ubuntu версия может отличаться от рекомендуемой. Установите пакет, указанный в документации совместимого релиза, и проверьте результат.

# Устанавливаем пакет для генерации PDF из HTML
sudo apt install -y wkhtmltopdf

# Проверяем, что бинарный файл доступен
wkhtmltopdf --version

Если печатные формы в вашей версии требуют patched Qt-сборку wkhtmltopdf, используйте официальный пакет из документации Frappe для Ubuntu. Не скачивайте случайные deb-файлы с форумов: PDF-генератор запускается на сервере и должен обновляться из доверенного источника.

Установка Bench CLI

# Переключаемся на системного пользователя приложения
sudo -iu frappe

# Устанавливаем Bench CLI в пользовательский каталог Python
python3 -m pip install --user frappe-bench

# Добавляем локальные бинарники Python в PATH текущей сессии
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
export PATH="$HOME/.local/bin:$PATH"

# Проверяем установленную версию Bench
bench --version

Команда bench init создаст структуру проекта, виртуальное окружение и исходный код Frappe. Директория проекта в примере называется frappe-bench.

Создание Bench и установка Frappe

# Создаем Bench на ветке Frappe version-15
bench init --frappe-branch version-15 frappe-bench

# Переходим в каталог проекта
cd ~/frappe-bench

# Проверяем состояние созданной среды
bench version
bench doctor

Если bench init завершается ошибкой компиляции, проверьте свободное место, версию Python, пакет python3-dev и доступ к GitHub. Не запускайте команду повторно вслепую: сначала прочитайте последние строки вывода и логи установки.

Создание сайта ERPNext

# Создаем новый сайт; команда запросит пароль root MariaDB
bench new-site erp.example.com

# Устанавливаем приложение ERPNext из официальной ветки version-15
bench get-app --branch version-15 erpnext https://github.com/frappe/erpnext

# Устанавливаем ERPNext на созданный сайт
bench --site erp.example.com install-app erpnext

# Устанавливаем сайт как сайт по умолчанию для этого Bench
bench use erp.example.com

# Собираем JavaScript и CSS-ресурсы приложения
bench build

# Проверяем установленные приложения и миграции
bench --site erp.example.com list-apps
bench --site erp.example migrate

Во время bench new-site задайте длинный пароль администратора MariaDB и отдельный пароль пользователя Administrator ERPNext. Пароли не записывайте в историю shell и не передавайте в командной строке. Если домен пока не настроен, для начальной проверки можно использовать имя сайта локально, а HTTPS включить после появления DNS-записи.

Проверка в режиме разработки

# Запускаем временный development-сервер только для локальной проверки
cd ~/frappe-bench
bench start

Команда запускает процессы в текущем терминале и не предназначена для production. С другого терминала проверьте порт 8000 через SSH-туннель:

# Выполняется на вашем локальном компьютере
ssh -L 8000:127.0.0.1:8000 frappe@SERVER_IP

# После подключения откройте локальный адрес
curl -I http://127.0.0.1:8000

Остановите development-сервер комбинацией Ctrl+C. В production процессами будут управлять Supervisor и Nginx.

Генерация production-конфигурации

# Устанавливаем production-конфигурацию Supervisor и Nginx
sudo bench setup production frappe

# Перечитываем конфигурацию Supervisor
sudo supervisorctl reread
sudo supervisorctl update

# Проверяем список процессов Bench
sudo supervisorctl status

# Перезапускаем все процессы после установки приложения
sudo supervisorctl restart all

Команда создает конфигурации в системных каталогах. Названия процессов зависят от версии Bench и имени пользователя. Если Supervisor показывает FATAL или BACKOFF, смотрите журнал конкретного процесса и проверяйте пути к Python, Node.js и проекту.

7. Конфигурация

DNS и домен

Создайте A-запись erp.example.com, указывающую на публичный IPv4-адрес сервера. Если используется IPv6, добавьте AAAA-запись только после проверки firewall и маршрутизации. До выпуска сертификата убедитесь, что домен резолвится с внешней сети, а порт 80 доступен.

# Проверяем DNS-запись домена
dig +short erp.example.com A
dig +short erp.example.com AAAA

# Проверяем HTTP-доступ к серверу по имени
curl -I http://erp.example.com

Настройка Nginx и HTTPS

Bench генерирует базовую конфигурацию Nginx для сайта. После того как DNS направлен на сервер, включите HTTPS встроенной командой Bench или используйте Certbot. Для типовой установки с уже сгенерированной конфигурацией:

# Проверяем синтаксис сгенерированной конфигурации Nginx
sudo nginx -t

# Перезапускаем Nginx после проверки
sudo systemctl enable --now nginx
sudo systemctl reload nginx

# Выпускаем сертификат и включаем HTTPS через Bench
cd /home/frappe/frappe-bench
sudo bench setup lets-encrypt erp.example.com

Команда Let’s Encrypt потребует доступный домен и порт 80 для HTTP-01 challenge. Если сертификат не выпускается, проверьте DNS, внешний firewall, правила UFW и наличие другого reverse proxy. После установки проверьте автоматическое продление через systemd timer Certbot или процедуру, созданную Bench.

# Проверяем сертификаты и таймеры автоматического продления
sudo certbot certificates
systemctl list-timers | grep -i certbot

# Проверяем HTTPS и заголовки ответа
curl -I https://erp.example.com

Основные настройки сайта

Настройки ERPNext и Frappe хранятся в JSON-файлах сайта. Секреты не следует размещать в git-репозитории, публичных конфигурациях Nginx или shell-скриптах. Файл site_config.json должен быть доступен только пользователю приложения и root.

# Переходим в каталог сайта
cd /home/frappe/frappe-bench/sites/erp.example.com

# Проверяем права файла конфигурации
ls -l site_config.json

# Ограничиваем права на конфигурацию сайта
chmod 600 site_config.json

# Просматриваем настройки без вывода секретов в общий лог
bench --site erp.example.com show-config

Параметры Redis, подключения к MariaDB и ключи шифрования создаются Bench автоматически. Не заменяйте их случайными значениями без понимания последствий: потеря ключа шифрования может сделать зашифрованные значения в базе недоступными.

Количество web и background-процессов

На небольшом сервере начните с двух web-процессов и одного worker на каждую очередь, если это позволяет RAM. Увеличение числа процессов не гарантирует ускорения: каждый процесс потребляет память, а MariaDB также нуждается в buffer pool. Изменения делайте после наблюдения за CPU, RAM, latency и длиной очередей.

# Показываем текущие настройки Bench и сайтов
cd /home/frappe/frappe-bench
bench config export

# Смотрим загрузку очередей и состояние workers
bench doctor
sudo supervisorctl status

# Проверяем процессы и потребление памяти
ps aux --sort=-%mem | head -n 15
free -h
uptime

При длительных фоновых задачах, например массовом импорте или генерации отчетов, разделяйте очереди по приоритету. На production не следует запускать тяжелые задания без ограничения concurrency: они могут занять все CPU и память, из-за чего интерактивный интерфейс перестанет отвечать.

Проверка приложения и healthcheck

# Проверяем ответ через публичный HTTPS-адрес
curl --fail --silent --show-error https://erp.example.com/api/method/frappe.ping

# Проверяем статус HTTP и заголовок сервера
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' https://erp.example.com

# Проверяем очередь Redis и состояние базы локально
redis-cli ping
sudo systemctl is-active mariadb
sudo systemctl is-active nginx

# Проверяем миграции и состояние сайта
cd /home/frappe/frappe-bench
bench --site erp.example.com doctor
bench --site erp.example.com migrate

Для мониторинга используйте внешний HTTP-check, который проверяет HTTPS-код ответа и время отклика. Дополнительно контролируйте свободное место, использование inode, RAM, swap, заполнение очередей и возраст последнего backup. Проверка только порта 443 не показывает, что MariaDB и background workers работают корректно.

Логи

# Смотрим журналы Bench и последние ошибки
cd /home/frappe/frappe-bench
tail -n 100 logs/web.error.log
tail -n 100 logs/worker.error.log

# Смотрим системные ошибки Nginx и Supervisor
sudo journalctl -u nginx -n 100 --no-pager
sudo journalctl -u supervisor -n 100 --no-pager

# Проверяем размер каталогов проекта и логов
du -sh sites/ logs/ 2>/dev/null

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

8. Бэкапы и обслуживание

Что необходимо резервировать

Минимальный backup ERPNext состоит из дампа MariaDB и файлов сайта. В базе находятся документы, настройки, пользователей, права и большинство бизнес-данных. В каталоге sites/erp.example.com/private/files могут находиться закрытые вложения, а в public/files — публичные изображения и документы.

• База данных: полный дамп MariaDB, созданный через Bench или mysqldump.
• Private-файлы: закрытые вложения и документы пользователей.
• Public-файлы: изображения, печатные формы и доступные по URL ресурсы.
• Конфигурация: site_config.json, конфигурация Bench, Supervisor и Nginx.
• Ключи: SSH-ключи, ключи шифрования и учетные данные внешних интеграций.

Пароль администратора ERPNext сам по себе не заменяет backup. Также не следует копировать только каталог проекта без базы: такая копия не восстановит согласованное состояние документов. Рекомендуется хранить несколько дневных точек, недельные копии и отдельную месячную копию.

Создание backup через Bench

# Создаем полный backup базы и файлов сайта
cd /home/frappe/frappe-bench
bench --site erp.example.com backup --with-files --compress

# Показываем созданные архивы и их размеры
find sites/erp.example.com/private/backups -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM %s %p\n' | sort

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

Пример отправки в S3-совместимое хранилище через rclone

# Устанавливаем rclone из пакетов Ubuntu
sudo apt install -y rclone

# Создайте конфигурацию удаленного S3-хранилища интерактивно
rclone config

# Проверяем доступ к удаленному bucket
rclone lsd remote:

# Синхронизируем backup ERPNext с внешним хранилищем
rclone copy /home/frappe/frappe-bench/sites/erp.example.com/private/backups \
  remote:erpnext-backups/erp.example.com \
  --transfers 2 \
  --checkers 4 \
  --log-file /var/log/rclone-erpnext.log

Доступ к S3 должен использовать отдельный ключ с минимальными правами. Не помещайте секреты в командную строку, публичный git-репозиторий или файл, доступный всем пользователям. Для защиты от удаления настройте versioning и object lock, если это поддерживает выбранное хранилище.

Простой скрипт backup

Создайте скрипт от root, но запускайте сам Bench от пользователя frappe. В примере архивы сохраняются семь дней локально и затем отправляются в S3-совместимое хранилище.

# Создаем каталог для административных скриптов
sudo install -d -m 750 /usr/local/sbin

# Создаем скрипт backup
sudo tee /usr/local/sbin/backup-erpnext.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

BENCH_DIR="/home/frappe/frappe-bench"
SITE="erp.example.com"
BACKUP_DIR="${BENCH_DIR}/sites/${SITE}/private/backups"

sudo -u frappe bash -lc "cd '${BENCH_DIR}' && bench --site '${SITE}' backup --with-files --compress"

rclone copy "${BACKUP_DIR}" "remote:erpnext-backups/${SITE}" \
  --transfers 2 \
  --checkers 4 \
  --log-file /var/log/rclone-erpnext.log

find "${BACKUP_DIR}" -type f -mtime +7 -delete
EOF

# Закрываем скрипт от обычных пользователей и делаем его исполняемым
sudo chmod 750 /usr/local/sbin/backup-erpnext.sh

# Запускаем проверку вручную
sudo /usr/local/sbin/backup-erpnext.sh

В реальной конфигурации замените remote на имя настроенного rclone remote. После ручного запуска проверьте, что в bucket появился новый объект и процесс завершился с кодом 0. Для чувствительных данных включите шифрование на стороне S3 или используйте crypt remote rclone.

Запуск по cron

# Открываем системное расписание root
sudo crontab -e

# Запускаем backup каждый день в 02:30 и сохраняем журнал
30 2   * /usr/local/sbin/backup-erpnext.sh >> /var/log/backup-erpnext.log 2>&1

Backup считается рабочим только после восстановления. Раз в месяц разверните копию на отдельном временном сервере, восстановите базу и файлы, проверьте вход в ERPNext и наличие вложений. Зафиксируйте фактическое время восстановления — RTO — и допустимую потерю данных — RPO.

Обновления

Обновление ERPNext состоит из изменения кода приложения, миграций базы, пересборки assets и перезапуска процессов. Перед обновлением прочитайте release notes и требования к версии Frappe. Не обновляйте production автоматически сразу после появления нового коммита без проверки на staging.

# Создаем backup перед любым обновлением
cd /home/frappe/frappe-bench
bench --site erp.example.com backup --with-files --compress

# Проверяем текущее состояние и версии
bench version
git status --short

# Обновляем приложения и выполняем миграции
bench update --reset
bench --site erp.example.com migrate
bench build

# Перезапускаем production-процессы
sudo supervisorctl restart all
sudo systemctl reload nginx

# Проверяем сайт после обновления
curl --fail --silent --show-error https://erp.example.com/api/method/frappe.ping

Для небольшой системы используйте maintenance window, когда пользователи не работают в ERPNext. Rolling update возможен только при нескольких узлах и совместимой схеме базы данных; на одном сервере он практически не дает преимуществ. Откат кода без отката миграций базы может привести к несовместимости, поэтому rollback-план должен включать восстановление базы из backup.

Регулярное обслуживание

• Еженедельно проверяйте свободное место, рост базы и размер каталогов файлов.
• Ежедневно контролируйте последний успешный backup и состояние очередей.
• Ежемесячно тестируйте восстановление на отдельном сервере.
• Перед обновлением Ubuntu проверяйте совместимость Python, MariaDB, Node.js и Frappe.
• Удаляйте неиспользуемые сайты и старые архивы только после проверки политики хранения.
• Следите за сроком TLS-сертификатов и доступностью DNS.

9. Troubleshooting + FAQ

Почему открывается ошибка 502 Bad Gateway?

Ошибка 502 означает, что Nginx не получил корректный ответ от web-процесса. Сначала проверьте sudo supervisorctl status, затем журналы logs/web.error.log и /var/log/nginx/error.log. Если процессы остановлены, посмотрите причину в Supervisor. Частые причины — нехватка памяти, неверный путь к виртуальному окружению, поврежденная сборка assets или ошибка миграции. После исправления перезапустите конкретный процесс, а не весь сервер.

Почему ERPNext работает медленно после установки?

Проверьте CPU, RAM, swap, latency диска и длину очередей: htop, free -h, iostat -xz 1 и bench doctor. Если память закончилась, уменьшите число процессов или увеличьте RAM. Если медленно открывается конкретный отчет, причина может быть в SQL-запросе или большом объеме истории, а не в Nginx. Импорт и генерацию PDF выполняйте фоновыми задачами и не запускайте много тяжелых операций одновременно.

Какой VPS-конфиг минимально подойдет?

Для тестирования достаточно 2 vCPU и 4 ГБ RAM, но такую конфигурацию не следует считать комфортной production-средой. Минимальный практичный вариант для небольшой компании — 4 vCPU, 8 ГБ RAM, SSD от 80 ГБ, публичный IPv4 и стабильный канал. Если одновременно работают 20 и более пользователей, используются отчеты, импорт и вложения, начните с 8 vCPU, 16 ГБ RAM и NVMe от 160 ГБ. Оставляйте запас памяти для MariaDB и фоновых workers.

Что выбрать — VPS или dedicated для этой задачи?

VPS подходит большинству небольших и средних установок ERPNext, если у него предсказуемые CPU, быстрый SSD и достаточно RAM. Dedicated имеет смысл при постоянной высокой нагрузке, больших базах, тяжелых отчетах, требованиях к физической изоляции или необходимости большого объема памяти. Решение принимайте по измеренным метрикам: средняя и пиковая загрузка CPU, задержка диска, использование RAM, размер базы и число фоновых задач. Одно только число пользователей не дает точного ответа.

Почему не выпускается Let’s Encrypt-сертификат?

Проверьте, что A-запись домена указывает на правильный IPv4, AAAA-запись не ведет на недоступный IPv6, а порт 80 разрешен во внешнем firewall и UFW. Выпуск также блокируется другим процессом, который уже использует порт 80, или неправильным server_name в Nginx. Выполните dig +short erp.example.com и curl -I http://erp.example.com с внешнего компьютера. После исправления повторите выпуск сертификата и проверьте таймер продления.

Пользователь не получает письма от ERPNext. Что проверить?

Проверьте SMTP-хост, порт, TLS-режим, логин и пароль в настройках Email Account. Не используйте обычный пароль почтового ящика, если провайдер требует application password или OAuth. Посмотрите очередь и журналы фоновых workers: отправка электронной почты выполняется асинхронно. Также проверьте SPF, DKIM и DMARC домена, иначе письма могут уходить из ERPNext, но отклоняться или попадать в спам на стороне получателя.

После обновления не загружается интерфейс или пропали стили

Выполните bench build, затем очистите кеш сайта командой bench --site erp.example.com clear-cache и перезапустите Supervisor. Проверьте, что Nginx обслуживает актуальный каталог assets, а права на файлы принадлежат пользователю frappe. Если браузер продолжает использовать старые ресурсы, откройте страницу в приватном окне и проверьте HTTP-коды запросов к JavaScript и CSS через developer tools. При ошибке миграции сначала сохраните логи, а не повторяйте обновление многократно.

Как понять, что backup действительно пригоден?

Наличие файла в каталоге backup не доказывает возможность восстановления. Возьмите архив, перенесите его на отдельный сервер с совместимой версией ERPNext, восстановите базу и public/private-файлы, затем проверьте вход, документы, вложения и фоновые задачи. Зафиксируйте время восстановления и ошибки. Для критичной системы тестируйте не только ежедневный backup, но и старую недельную или месячную точку, потому что логическая ошибка могла попасть во все свежие копии.

10. Выводы и следующие шаги

В результате развернута одноузловая production-конфигурация ERPNext 15 на Ubuntu 24.04 LTS с MariaDB, Redis, Supervisor, Nginx и HTTPS. Сервер защищен базовыми SSH- и firewall-настройками, сайт проверяется через HTTP healthcheck, а резервная копия включает базу и файлы ERPNext.

Дальше измерьте реальную нагрузку в течение первой недели: CPU, RAM, задержку диска, размер базы, длину очередей и время ответа основных операций. Затем настройте staging-среду для обновлений, протестируйте восстановление backup и при росте нагрузки разделите фоновые workers, базу данных и файловое хранилище на отдельные узлы.

1. Соберите метрики использования и установите пороги оповещений для диска, памяти, очередей и доступности HTTPS.
2. Проведите тест восстановления на чистом сервере и документируйте порядок действий для аварийного запуска.
3. При росте числа пользователей оптимизируйте тяжелые отчеты, добавьте ресурсы и только после этого переходите к многосерверной архитектуре.