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.com 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-перевірку, яка перевіряє 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. Усунення несправностей + 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. Зі зростанням кількості користувачів оптимізуйте важкі звіти, додайте ресурси й лише після цього переходьте до багатосерверної архітектури.