ERPNext en servidor dedicado: instalación y requisitos de carga

3. Qué configuramos y por qué

ERPNext es una aplicación web para la gestión empresarial. En una sola instalación se pueden gestionar empresas, contrapartes, facturas, ventas, compras, existencias de almacén, producción, proyectos, empleados y operaciones financieras. El sistema está construido sobre Frappe Framework: el usuario trabaja mediante el navegador, mientras que el servidor ejecuta la lógica de negocio, las tareas en segundo plano y las consultas a la base de datos.

La guía utiliza una arquitectura típica de un solo nodo. Todos los servicios se alojan en un servidor dedicado: MariaDB almacena los datos transaccionales, Redis atiende las colas y la caché, los workers ejecutan tareas en segundo plano y Nginx recibe conexiones HTTPS y reenvía las solicitudes a los procesos de Frappe. Este esquema es adecuado para una primera instalación production si el volumen de datos y el número de usuarios todavía no requieren separar los componentes.

Qué se obtendrá al final

Tras completar los pasos, estará disponible un sitio de ERPNext con un nombre de dominio independiente, un certificado HTTPS y un usuario administrativo. El sistema se iniciará automáticamente tras reiniciar el servidor, las tareas en segundo plano se ejecutarán mediante Supervisor y el acceso a MariaDB y Redis permanecerá local.

La configuración contempla medidas básicas de protección: inicio de sesión mediante clave SSH, un usuario sudo independiente, restricción de puertos mediante firewall, fail2ban, ausencia de acceso público a la base de datos y renovación automática del certificado Let’s Encrypt. Para production, también se deben configurar monitorización, almacenamiento centralizado de logs y comprobaciones periódicas de restauración.

Qué tareas resuelve ERPNext

• Ventas: leads, ofertas comerciales, pedidos de clientes, envíos y facturas.
• Compras: proveedores, solicitudes, pedidos a proveedores, recepciones y facturas.
• Almacén: almacenes, lotes, números de serie, movimientos y valoración de existencias.
• Producción: especificaciones, órdenes de trabajo, operaciones y consumo de materiales.
• Finanzas: plan de cuentas, pagos, asientos, impuestos e informes.
• Proyectos: tareas, esfuerzo laboral, plazos y vínculo con documentos de clientes.
• HR: empleados, vacaciones, asistencia y procesos básicos de recursos humanos.

Self-hosted y cloud-managed

En la nube managed, el proveedor normalmente se encarga de la instalación, las actualizaciones, TLS, las copias de seguridad y parte de la monitorización. Esto reduce los costes operativos del equipo, pero limita el control sobre el SO, el esquema de red, el calendario de actualizaciones y el método de almacenamiento de datos. Además, el coste de una instalación managed suele crecer junto con el número de usuarios y el volumen de almacenamiento.

ERPNext self-hosted en un VPS o dedicated proporciona acceso completo al sistema operativo y a la configuración. El administrador elige por sí mismo la versión de la aplicación, la política de backup, las reglas de red y el método de integración con servicios externos. La contrapartida es la responsabilidad de las actualizaciones, la seguridad, la recuperación y el análisis del rendimiento.

Para una empresa con varias decenas de usuarios, una instalación de un solo nodo suele ser un punto de partida razonable. Cuando la base de datos crece, aparecen informes pesados, importaciones masivas o decenas de procesos en segundo plano, la arquitectura puede dividirse: MariaDB, Redis, workers y archivos pueden trasladarse a nodos independientes.

Limitaciones del esquema de un solo nodo

Si el servidor falla por completo, la interfaz web, la base de datos y las tareas en segundo plano dejarán de estar disponibles simultáneamente. Por ello, tener un backup en el mismo disco no se considera protección suficiente. Como mínimo, se requiere una copia externa de la base de datos y los archivos y, para un sistema crítico, un servidor standby independiente o un procedimiento de restauración comprobado periódicamente en una nueva instancia.

4. Qué configuración de VPS se necesita para esta tarea

Los requisitos de ERPNext no dependen solo del número de cuentas. La carga se ve afectada por los usuarios que trabajan simultáneamente, el número de sitios, el tamaño de la base de datos, la frecuencia de las tareas en segundo plano, la complejidad de los informes, las importaciones CSV, la cantidad de productos y el historial de documentos. No se puede evaluar un servidor únicamente por el número de usuarios registrados: cien usuarios que trabajan por turnos generan menos carga que veinte usuarios que ejecutan informes pesados al mismo tiempo.

Parámetros mínimos

Para una instalación de laboratorio o una empresa pequeña, es adecuado un servidor con 4 CPU virtuales, 8 GB de memoria RAM y un SSD rápido desde 80 GB. Este tamaño está diseñado para aproximadamente 5–10 usuarios activos con una carga moderada. Para un entorno de demostración se puede comenzar con 2 vCPU y 4 GB de RAM, pero no es la mejor opción para production: MariaDB, los workers y los procesos web competirán por la memoria.

Como configuración inicial práctica para un equipo pequeño de production, puede elegir un VPS con estas características: 8 vCPU, 16 GB de RAM, NVMe desde 160 GB, una dirección IPv4 pública y un canal desde 500 Mbit/s. Este margen permitirá asignar memoria a MariaDB, ejecutar varios procesos web y conservar espacio para logs, archivos y archivos de backup.

CPU, memoria y disco

La CPU es necesaria para procesar solicitudes web, serializar datos, generar PDF, importar documentos y ejecutar tareas en segundo plano. La frecuencia de un núcleo es importante para la interfaz interactiva, mientras que la cantidad de núcleos lo es para los workers paralelos y varios usuarios. Si los usuarios se quejan de retrasos al abrir formularios y la CPU está constantemente ocupada, primero compruebe las consultas SQL lentas y el número de procesos gunicorn, en lugar de limitarse a aumentar el plan.

La memoria RAM es especialmente importante para MariaDB y Redis. En un sistema con 8 GB de RAM, se debe dejar una reserva de al menos 1–1,5 GB para el SO, Nginx, Supervisor y operaciones temporales. Con swap habilitado, el servidor puede sobrevivir a un pico breve, pero swap no sustituye a la RAM: el funcionamiento constante mediante swap empeora drásticamente la latencia de las solicitudes.

Para ERPNext es mejor utilizar NVMe u otro SSD de baja latencia. El disco debe alojar el sistema operativo, la base de datos, los archivos public y private, logs, archivos temporales y margen de crecimiento. Una regla práctica es reservar al menos el doble del volumen actual de datos. El backup no debe almacenarse en la misma partición como única copia.

Red y dirección IP

ERPNext no requiere un gran canal para el funcionamiento normal, pero una IPv4 pública simplifica DNS, la emisión de certificados y las integraciones. Para transferir archivos, copias de seguridad e importaciones masivas, es útil un canal desde 100 Mbit/s. El acceso web debe realizarse a través de los puertos 80 y 443; es mejor restringir SSH a las direcciones IP del administrador o situarlo detrás de una VPN.

Cuándo se necesita dedicated

Un servidor dedicado está justificado cuando el sistema utiliza de forma constante mucha CPU o RAM, se requiere un rendimiento de disco predecible, hay varias empresas grandes en una misma instalación o se ejecutan servicios adicionales en el nodo. También es conveniente para informes que consumen muchos recursos, sincronización masiva con marketplaces, generación de grandes cantidades de PDF y almacenamiento de un archivo de documentos voluminoso.

Si el principal motivo para elegir dedicated es solo el temor a la inestabilidad de un VPS, primero compruebe el SLA y el tipo de virtualización. Un buen VPS con recursos dedicados y NVMe puede ser suficiente para decenas de usuarios. Dedicated se vuelve especialmente útil cuando existen requisitos de aislamiento físico, licenciamiento, RAID local, grandes volúmenes de memoria o una carga alta constante.

Ubicación del servidor

La región afecta a la latencia de la interfaz, la velocidad de carga de archivos y el cumplimiento de los requisitos de alojamiento de datos personales. Para empleados en un mismo país, elija un centro de datos más cercano a ellos, pero compruebe no solo la distancia geográfica, sino también la latencia real y la calidad del enrutamiento. Para integraciones con sistemas de pago, telefonía y API externas, se debe verificar adicionalmente la disponibilidad de las direcciones necesarias desde la red seleccionada.

5. Preparación del servidor

A continuación se presupone un servidor limpio con Ubuntu Server 24.04 LTS, un registro DNS configurado erp.example.com y acceso con el usuario creado por el proveedor. Los comandos se ejecutan con un usuario que tiene permisos sudo. Sustituya el dominio, el nombre de usuario y la zona horaria por sus propios valores.

Actualización del sistema y utilidades básicas

# Обновляем индекс пакетов и устанавливаем последние исправления
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 genera fechas e informes teniendo en cuenta la zona horaria del servidor y la configuración del sitio. Para un equipo distribuido, es mejor determinar de antemano si el servidor funcionará en UTC o si se utilizará la zona horaria de la organización principal. Cambiar la zona horaria después de que existan documentos puede provocar confusión al analizar los límites del día.

Creación de un usuario independiente

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

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

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

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

No ejecute Bench como root. Un usuario independiente limita las consecuencias de un error en la aplicación del usuario y simplifica la gestión de permisos. Los comandos que requieren modificar servicios del sistema se ejecutan mediante sudo, mientras que los comandos de Bench se ejecutan como frappe.

Claves SSH y desactivación de contraseñas

Primero añada la clave pública a /home/frappe/.ssh/authorized_keys. Si se ha conectado con el usuario inicial, puede crear el directorio y establecer los permisos de la siguiente forma:

# Создаем каталог 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

Compruebe el acceso en una nueva sesión SSH antes de desactivar las contraseñas. Para proteger SSH, puede crear un archivo drop-in independiente:

# Создаем настройки 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

Si SSH está disponible desde Internet, restrínjalo a determinadas fuentes cuando sea posible. No cierre la sesión actual hasta haber comprobado el nuevo acceso. La pérdida de acceso debido a una regla de firewall o una configuración SSH incorrecta normalmente requiere utilizar la consola del proveedor.

Firewall y 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

Si se cambia el puerto SSH, permita primero el nuevo puerto en UFW y solo después reinicie SSH. Cambiar el número de puerto por sí solo no constituye una protección completa; la protección principal consiste en desactivar las contraseñas, restringir las fuentes y supervisar los intentos de acceso.

Swap para un servidor pequeño

Swap resulta útil como búfer de emergencia durante una importación o un pico breve, especialmente en un servidor con 8 GB de RAM. Para producción con 16 GB de memoria, normalmente basta con un archivo swap de 2–4 GB si la carga está controlada.

# Создаем 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. Instalación del software — paso a paso

En esta sección se instalan ERPNext 15 y Frappe Framework 15. Para producción utilizamos Python 3.12, Node.js 18 LTS, MariaDB 10.11 del repositorio de Ubuntu 24.04, Redis de Ubuntu, Yarn y el instalador oficial de Bench mediante Python package. Antes de comenzar, compruebe la matriz de compatibilidad actual de Frappe para la versión minor seleccionada: las versiones de las dependencias pueden cambiar entre lanzamientos.

Instalación de 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

En el asistente de MariaDB, elimine los usuarios anónimos, prohíba el acceso remoto de root y elimine la base de datos de prueba. El usuario root de MariaDB se utilizará localmente para crear la base de datos del sitio, pero su acceso no debe estar abierto a través de la red.

ERPNext requiere codificaciones y parámetros de InnoDB correctos. Cree un archivo de configuración independiente:

# Создаем параметры 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

Para un servidor con 8 GB de RAM, el valor de innodb-buffer-pool-size debe reducirse aproximadamente a 2–3 GB. No copie el valor 4G en un servidor pequeño: la base de datos, los workers y el sistema operativo deben disponer de memoria libre.

Instalación de Redis y 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

La respuesta PONG significa que Redis acepta solicitudes locales. No se necesita acceso externo a Redis. Compruebe que, en la configuración de Redis, la dirección de escucha no esté abierta en una interfaz pública.

Instalación de Node.js 18 y 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 normalmente utiliza Node.js 18 LTS. Si una versión específica de ERPNext requiere Node.js 20, siga su tabla oficial de compatibilidad y no mezcle versiones arbitrarias. Después de cambiar Node.js, es necesario volver a compilar los assets mediante Bench.

Instalación de wkhtmltopdf

ERPNext utiliza wkhtmltopdf para algunos formularios impresos y para generar PDF. La versión del repositorio de Ubuntu puede diferir de la recomendada. Instale el paquete indicado en la documentación de la versión compatible y compruebe el resultado.

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

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

Si los formularios impresos de su versión requieren una compilación de wkhtmltopdf con patched Qt, utilice el paquete oficial indicado en la documentación de Frappe para Ubuntu. No descargue archivos deb aleatorios de foros: el generador de PDF se ejecuta en el servidor y debe actualizarse desde una fuente de confianza.

Instalación de 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

El comando bench init creará la estructura del proyecto, el entorno virtual y el código fuente de Frappe. El directorio del proyecto del ejemplo se denomina frappe-bench.

Creación de Bench e instalación de Frappe

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

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

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

Si bench init finaliza con un error de compilación, compruebe el espacio disponible, la versión de Python, el paquete python3-dev y el acceso a GitHub. No vuelva a ejecutar el comando a ciegas: primero lea las últimas líneas de la salida y los registros de instalación.

Creación del sitio 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

Durante bench new-site, establezca una contraseña larga para el administrador de MariaDB y una contraseña independiente para el usuario Administrator de ERPNext. No guarde las contraseñas en el historial del shell ni las pase en la línea de comandos. Si el dominio aún no está configurado, para la comprobación inicial puede utilizar localmente el nombre del sitio y activar HTTPS después de crear el registro DNS.

Comprobación en modo de desarrollo

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

El comando inicia los procesos en el terminal actual y no está destinado a producción. Desde otro terminal, compruebe el puerto 8000 mediante un túnel SSH:

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

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

Detenga el servidor de desarrollo con la combinación Ctrl+C. En producción, los procesos estarán gestionados por Supervisor y Nginx.

Generación de la configuración de producción

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

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

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

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

El comando crea configuraciones en los directorios del sistema. Los nombres de los procesos dependen de la versión de Bench y del nombre de usuario. Si Supervisor muestra FATAL o BACKOFF, consulte el registro del proceso correspondiente y compruebe las rutas de Python, Node.js y del proyecto.

7. Configuración

DNS y dominio

Cree un registro A erp.example.com que apunte a la dirección IPv4 pública del servidor. Si se utiliza IPv6, agregue un registro AAAA solo después de verificar el firewall y el enrutamiento. Antes de emitir el certificado, asegúrese de que el dominio se resuelva desde una red externa y que el puerto 80 esté disponible.

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

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

Configuración de Nginx y HTTPS

Bench genera una configuración básica de Nginx para el sitio. Una vez que el DNS apunte al servidor, habilite HTTPS mediante el comando integrado de Bench o utilice Certbot. Para una instalación típica con una configuración ya generada:

# Проверяем синтаксис сгенерированной конфигурации 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

El comando Let’s Encrypt requerirá un dominio disponible y el puerto 80 para el desafío HTTP-01. Si el certificado no se emite, compruebe el DNS, el firewall externo, las reglas de UFW y la presencia de otro proxy inverso. Después de la instalación, verifique la renovación automática mediante el temporizador systemd de Certbot o el procedimiento creado por Bench.

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

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

Configuración principal del sitio

La configuración de ERPNext y Frappe se almacena en archivos JSON del sitio. Los secretos no deben colocarse en el repositorio git, configuraciones públicas de Nginx ni scripts de shell. El archivo site_config.json debe estar disponible solo para el usuario de la aplicación y 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

Los parámetros de Redis, las conexiones a MariaDB y las claves de cifrado se crean automáticamente mediante Bench. No los sustituya por valores aleatorios sin comprender las consecuencias: la pérdida de una clave de cifrado puede hacer que los valores cifrados de la base de datos sean inaccesibles.

Número de procesos web y en segundo plano

En un servidor pequeño, comience con dos procesos web y un worker para cada cola, si la RAM lo permite. Aumentar el número de procesos no garantiza una aceleración: cada proceso consume memoria y MariaDB también necesita un buffer pool. Realice cambios después de observar la CPU, la RAM, la latencia y la longitud de las colas.

# Показываем текущие настройки 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

Para tareas prolongadas en segundo plano, por ejemplo, importaciones masivas o generación de informes, separe las colas por prioridad. En producción no se deben ejecutar tareas pesadas sin limitar la concurrencia: pueden ocupar toda la CPU y la memoria, haciendo que la interfaz interactiva deje de responder.

Verificación de la aplicación y 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

Para la monitorización, utilice una comprobación HTTP externa que verifique el código de respuesta HTTPS y el tiempo de respuesta. Además, controle el espacio libre, el uso de inode, la RAM, el swap, el llenado de las colas y la antigüedad del último backup. Comprobar solo el puerto 443 no indica que MariaDB y los workers en segundo plano funcionen correctamente.

Registros

# Смотрим журналы 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

Los registros deben rotarse. Si un registro ocupa una parte significativa del disco, configure logrotate y no elimine manualmente los archivos activos mientras los procesos estén en ejecución. Primero determine el origen del error recurrente, luego corrija la causa y solo después elimine los registros acumulados.

8. Backups y mantenimiento

Qué es necesario respaldar

El backup mínimo de ERPNext consta de un volcado de MariaDB y los archivos del sitio. La base de datos contiene documentos, configuraciones, usuarios, permisos y la mayoría de los datos empresariales. El directorio sites/erp.example.com/private/files puede contener archivos adjuntos privados, y public/files, imágenes y documentos públicos.

• Base de datos: volcado completo de MariaDB, creado mediante Bench o mysqldump.
• Archivos privados: archivos adjuntos privados y documentos de usuarios.
• Archivos públicos: imágenes, formularios imprimibles y recursos accesibles por URL.
• Configuración: site_config.json, configuración de Bench, Supervisor y Nginx.
• Claves: claves SSH, claves de cifrado y credenciales de integraciones externas.

La contraseña de administrador de ERPNext por sí sola no sustituye un backup. Tampoco se debe copiar únicamente el directorio del proyecto sin la base de datos: dicha copia no restaurará un estado coherente de los documentos. Se recomienda conservar varios puntos diarios, copias semanales y una copia mensual independiente.

Creación de backup mediante 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

El comando guarda los archivos localmente. Esto es solo la primera etapa. Si el servidor o el disco se dañan, la copia local desaparecerá junto con el sistema en funcionamiento, por lo que los archivos deben enviarse a almacenamiento externo.

Ejemplo de envío a almacenamiento compatible con S3 mediante 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

El acceso a S3 debe utilizar una clave independiente con permisos mínimos. No incluya secretos en la línea de comandos, un repositorio git público ni un archivo accesible para todos los usuarios. Para protegerse contra eliminaciones, configure versioning y object lock, si el almacenamiento elegido lo admite.

Script de backup sencillo

Cree el script como root, pero ejecute Bench como el usuario frappe. En el ejemplo, los archivos se conservan siete días localmente y luego se envían a almacenamiento compatible con 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

En una configuración real, sustituya remote por el nombre del remote de rclone configurado. Después de ejecutarlo manualmente, compruebe que aparezca un objeto nuevo en el bucket y que el proceso finalice con el código 0. Para datos confidenciales, habilite el cifrado del lado de S3 o utilice el remote crypt de rclone.

Ejecución mediante cron

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

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

Un backup se considera funcional solo después de su restauración. Una vez al mes, despliegue una copia en un servidor temporal independiente, restaure la base de datos y los archivos, compruebe el inicio de sesión en ERPNext y la presencia de archivos adjuntos. Registre el tiempo real de restauración —RTO— y la pérdida de datos admisible —RPO—.

Actualizaciones

La actualización de ERPNext consta de modificar el código de la aplicación, migraciones de la base de datos, recompilación de assets y reinicio de procesos. Antes de actualizar, lea las release notes y los requisitos de la versión de Frappe. No actualice producción automáticamente justo después de que aparezca un nuevo commit sin realizar pruebas en 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

Para un sistema pequeño, utilice una ventana de mantenimiento durante la cual los usuarios no trabajen en ERPNext. Una actualización rolling solo es posible con varios nodos y un esquema de base de datos compatible; en un solo servidor prácticamente no ofrece ventajas. Revertir el código sin revertir las migraciones de la base de datos puede causar incompatibilidades, por lo que el plan de rollback debe incluir la restauración de la base de datos desde un backup.

Mantenimiento periódico

• Compruebe semanalmente el espacio libre, el crecimiento de la base de datos y el tamaño de los directorios de archivos.
• Controle diariamente el último backup correcto y el estado de las colas.
• Pruebe mensualmente la restauración en un servidor independiente.
• Antes de actualizar Ubuntu, compruebe la compatibilidad de Python, MariaDB, Node.js y Frappe.
• Elimine sitios no utilizados y archivos antiguos solo después de revisar la política de retención.
• Supervise la vigencia de los certificados TLS y la disponibilidad del DNS.

9. Resolución de problemas + preguntas frecuentes

¿Por qué aparece el error 502 Bad Gateway?

El error 502 significa que Nginx no recibió una respuesta correcta del proceso web. Primero compruebe sudo supervisorctl status y, a continuación, los registros logs/web.error.log y /var/log/nginx/error.log. Si los procesos están detenidos, consulte la causa en Supervisor. Las causas frecuentes son la falta de memoria, una ruta incorrecta al entorno virtual, una compilación dañada de assets o un error de migración. Después de corregirlo, reinicie el proceso concreto, no todo el servidor.

¿Por qué ERPNext funciona lentamente después de la instalación?

Compruebe la CPU, la RAM, el swap, la latencia del disco y la longitud de las colas: htop, free -h, iostat -xz 1 y bench doctor. Si se ha agotado la memoria, reduzca el número de procesos o aumente la RAM. Si un informe concreto se abre lentamente, la causa puede estar en la consulta SQL o en un gran volumen de historial, y no en Nginx. Realice la importación y la generación de PDF mediante tareas en segundo plano y no ejecute muchas operaciones pesadas simultáneamente.

¿Qué configuración de VPS es mínimamente adecuada?

Para realizar pruebas son suficientes 2 vCPU y 4 GB de RAM, pero esta configuración no debe considerarse un entorno production cómodo. Una opción práctica mínima para una empresa pequeña es 4 vCPU, 8 GB de RAM, un SSD de al menos 80 GB, IPv4 pública y una conexión estable. Si trabajan simultáneamente 20 usuarios o más, se utilizan informes, importaciones y archivos adjuntos, comience con 8 vCPU, 16 GB de RAM y NVMe de al menos 160 GB. Reserve memoria para MariaDB y los workers en segundo plano.

¿Qué elegir: VPS o dedicated para esta tarea?

Un VPS es adecuado para la mayoría de las instalaciones pequeñas y medianas de ERPNext, siempre que tenga una CPU predecible, un SSD rápido y suficiente RAM. Un dedicated tiene sentido con una carga elevada constante, bases de datos grandes, informes pesados, requisitos de aislamiento físico o necesidad de una gran cantidad de memoria. Tome la decisión basándose en métricas medidas: carga media y máxima de la CPU, latencia del disco, uso de RAM, tamaño de la base de datos y número de tareas en segundo plano. El número de usuarios por sí solo no proporciona una respuesta exacta.

¿Por qué no se emite el certificado de Let’s Encrypt?

Compruebe que el registro A del dominio apunta a la IPv4 correcta, que el registro AAAA no apunta a una IPv6 inaccesible y que el puerto 80 está permitido en el firewall externo y en UFW. La emisión también puede bloquearse por otro proceso que ya utilice el puerto 80 o por un server_name incorrecto en Nginx. Ejecute dig +short erp.example.com y curl -I http://erp.example.com desde un equipo externo. Después de corregirlo, repita la emisión del certificado y compruebe el temporizador de renovación.

El usuario no recibe correos de ERPNext. ¿Qué se debe comprobar?

Compruebe el host SMTP, el puerto, el modo TLS, el nombre de usuario y la contraseña en la configuración de Email Account. No utilice la contraseña normal del buzón si el proveedor requiere una application password o OAuth. Revise la cola y los registros de los workers en segundo plano: el envío de correo electrónico se realiza de forma asíncrona. Compruebe también SPF, DKIM y DMARC del dominio; de lo contrario, los mensajes pueden salir de ERPNext, pero ser rechazados o llegar a la carpeta de spam del destinatario.

Después de la actualización no se carga la interfaz o han desaparecido los estilos

Ejecute bench build, luego borre la caché del sitio con el comando bench --site erp.example.com clear-cache y reinicie Supervisor. Compruebe que Nginx sirve el directorio de assets actualizado y que los archivos pertenecen al usuario frappe. Si el navegador sigue utilizando recursos antiguos, abra la página en una ventana privada y compruebe los códigos HTTP de las solicitudes a JavaScript y CSS mediante las herramientas de desarrollo. Si se produce un error de migración, primero guarde los registros y no repita la actualización varias veces.

¿Cómo saber si el backup realmente es válido?

La presencia de un archivo en el directorio backup no demuestra que sea posible restaurarlo. Tome el archivo, transfiéralo a un servidor independiente con una versión compatible de ERPNext, restaure la base de datos y los archivos public/private y, a continuación, compruebe el inicio de sesión, los documentos, los archivos adjuntos y las tareas en segundo plano. Registre el tiempo de restauración y los errores. En un sistema crítico, pruebe no solo el backup diario, sino también un punto semanal o mensual antiguo, porque un error lógico podría haber afectado a todas las copias recientes.

10. Conclusiones y siguientes pasos

Como resultado, se ha implementado una configuración production de un solo nodo de ERPNext 15 en Ubuntu 24.04 LTS con MariaDB, Redis, Supervisor, Nginx y HTTPS. El servidor está protegido con configuraciones básicas de SSH y firewall, el sitio se comprueba mediante un healthcheck HTTP y la copia de seguridad incluye la base de datos y los archivos de ERPNext.

A continuación, mida la carga real durante la primera semana: CPU, RAM, latencia del disco, tamaño de la base de datos, longitud de las colas y tiempo de respuesta de las operaciones principales. Después, configure un entorno staging para las actualizaciones, pruebe la restauración del backup y, si aumenta la carga, distribuya los workers en segundo plano, la base de datos y el almacenamiento de archivos entre nodos independientes.

1. Recopile métricas de uso y establezca umbrales de alerta para el disco, la memoria, las colas y la disponibilidad de HTTPS.
2. Realice una prueba de restauración en un servidor limpio y documente el procedimiento para un arranque de emergencia.
3. Cuando aumente el número de usuarios, optimice los informes pesados, añada recursos y solo después pase a una arquitectura multiservidor.