Instalación de Umami Web

¿Qué configuramos y por qué?

En el mundo digital actual, la recopilación de análisis sobre el tráfico de sitios web es fundamental para comprender el comportamiento del usuario, optimizar el contenido y mejorar la conversión. Sin embargo, las soluciones tradicionales como Google Analytics a menudo plantean preguntas sobre la privacidad de los datos, su propiedad y el cumplimiento de regulaciones estrictas como GDPR o CCPA. Aquí es donde entra en juego Umami Web Analytics.

Umami es una alternativa a Google Analytics simple, rápida y centrada en la privacidad. Le permite recopilar métricas básicas de tráfico (vistas de página, visitantes únicos, fuentes de tráfico, dispositivos y navegadores utilizados) sin usar cookies y sin recopilar datos personales, lo que la convierte en una opción ideal para proyectos donde la privacidad es primordial. Esto significa que, muy probablemente, no necesitará obtener el consentimiento del usuario para el uso de cookies, lo que simplifica significativamente el cumplimiento legal.

Qué obtendrá el lector al final

Al finalizar esta guía, tendrá una instalación de Umami completamente funcional en su propio VPS. Esto significará:

• Control total sobre los datos: Todos sus análisis se almacenan en su servidor, y solo usted tiene acceso a ellos.
• Privacidad por defecto: Umami está diseñada pensando en la privacidad, no recopila PII (información de identificación personal) y no utiliza cookies para el seguimiento.
• Alto rendimiento: Umami es una aplicación ligera, y el uso de Docker y Nginx garantiza una distribución eficiente de los recursos y un funcionamiento rápido.
• Flexibilidad y escalabilidad: La arquitectura basada en Docker permite actualizar fácilmente los componentes, escalar recursos e integrar Umami con otros servicios.
• Ahorro: Ausencia de pagos mensuales por análisis en la nube, especialmente con grandes volúmenes de tráfico.

Qué alternativas existen (cloud-managed vs self-hosted) y por qué self-hosted en un VPS

Existen dos enfoques principales para el análisis web:

• Soluciones gestionadas en la nube (por ejemplo, Google Analytics, Fathom Analytics, Plausible Analytics):
  • Ventajas: Facilidad de configuración (a menudo solo copiar código JS), no es necesario gestionar el servidor, actualizaciones automáticas.
  • Desventajas: Cuota mensual, los datos se almacenan en un tercero (lo que puede ser un problema para la privacidad y el cumplimiento normativo), control limitado sobre la funcionalidad e integraciones.
• Soluciones autoalojadas (por ejemplo, Umami, Matomo, Open Web Analytics):
  • Ventajas: Control total sobre los datos y la infraestructura, ausencia de pagos mensuales por el servicio (solo por el VPS), posibilidad de personalización e integración profundas. Ideal para quienes valoran la soberanía de los datos.
  • Desventajas: Requiere conocimientos técnicos para la instalación y el mantenimiento, la responsabilidad de la seguridad y las copias de seguridad recae en usted.

¿Por qué autoalojado en un VPS? Elegir un VPS para Umami es el punto intermedio ideal. Obtiene las ventajas de una solución autoalojada (control, privacidad, ahorro) con costos de infraestructura relativamente bajos. Un VPS proporciona recursos dedicados, lo que garantiza el funcionamiento estable de sus análisis, a diferencia del alojamiento compartido. Para desarrolladores, fundadores individuales y empresas que valoran el control sobre los datos, esta es la opción óptima. Usted decide dónde y cómo se almacenan sus datos y garantiza su protección de acuerdo con sus requisitos.

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

La elección del VPS adecuado es un paso clave para una implementación exitosa de Umami. Los requisitos de recursos de Umami son relativamente bajos, pero dependen del volumen de tráfico que planee rastrear.

Requisitos mínimos

Para sitios web pequeños o entornos de prueba (hasta 10.000 vistas de página al mes):

• CPU: 1 núcleo (x86-64)
• RAM: 1-2 GB
• Disco: 20-40 GB SSD (un disco rápido es crítico para el rendimiento de la base de datos)
• Red: Puerto de 100 Mbps o 1 Gbps, volumen de tráfico ilimitado o suficiente (normalmente 1 TB al mes es suficiente para la mayoría de los sitios web).
• Sistema operativo: Ubuntu Server 24.04 LTS (recomendado) u otro SO moderno basado en Linux.

Plan de VPS recomendado para la tarea

Para sitios web con tráfico medio (de 10.000 a 100.000 vistas de página al mes) o para aquellos que planean alojar otros servicios ligeros en el mismo VPS:

• CPU: 2 núcleos (x86-64)
• RAM: 4 GB
• Disco: 80-160 GB SSD NVMe (para un rendimiento máximo de la BD)
• Red: Puerto de 1 Gbps, 2-4 TB de tráfico al mes.

Para la mayoría de las tareas relacionadas con Umami, un VPS con estas características será suficiente. Es importante elegir un proveedor que ofrezca una infraestructura fiable y soporte de calidad.

Cuándo se necesita un dedicado y no un VPS

Un servidor dedicado (dedicated server) se vuelve necesario cuando:

• Tráfico muy alto: Si espera millones de vistas de página al mes o decenas de miles de usuarios simultáneos, un VPS podría no soportar la carga en la base de datos y la aplicación.
• Muchos servicios: Si, además de Umami, planea alojar en el servidor aplicaciones web de alta carga, bases de datos para otros proyectos, servidores de juegos o sistemas CI/CD exigentes.
• Requisitos especiales de seguridad/cumplimiento: Algunas regulaciones pueden requerir el aislamiento físico del hardware.
• Requisitos de rendimiento: Se necesita un control máximo sobre el hardware, una configuración fina de BIOS/UEFI, arreglos RAID específicos.

Para la mayoría de los usuarios de Umami, incluso con varias decenas de miles de visitantes al día, un VPS bien configurado será más que suficiente.

Ubicación: qué factores influyen

La elección de la ubicación geográfica de su VPS es importante por varias razones:

• Latencia: Aloje el VPS lo más cerca posible de su audiencia objetivo principal. Una menor latencia significa un acceso más rápido al panel de Umami para usted y una ejecución más rápida del script de análisis para sus usuarios (aunque el script de Umami es muy ligero).
• Legislación de datos: Dependiendo de dónde se encuentren sus usuarios y dónde opere su negocio, pueden aplicarse diferentes leyes de almacenamiento y procesamiento de datos (por ejemplo, GDPR en la UE). Elegir la ubicación del VPS de acuerdo con estos requisitos puede ser crítico.
• Precio: Los precios de los VPS pueden variar según la región.

Elija siempre la ubicación que mejor se adapte a sus prioridades de rendimiento y normativas legales.

Preparación del servidor

Preparación del servidor

Antes de proceder con la instalación de Umami, es necesario realizar una configuración básica de su nuevo VPS para garantizar la seguridad y estabilidad de su funcionamiento. Utilizaremos Ubuntu Server 24.04 LTS como sistema operativo.

1. Conexión al servidor

Primero, conéctese a su VPS por SSH, utilizando las credenciales proporcionadas por su proveedor (normalmente el usuario root y una contraseña, o una clave SSH).

ssh root@ВАШ_IP_АДРЕС

Conexión al servidor a través de SSH.

2. Actualización del sistema

Siempre comience actualizando la lista de paquetes y su instalación a la versión más reciente. Esto garantiza que tendrá las últimas versiones de software y parches de seguridad.

sudo apt update && sudo apt upgrade -y

Actualización de la lista de paquetes e instalación de actualizaciones.

3. Creación de un nuevo usuario con permisos sudo

Trabajar como usuario root no es seguro. Cree un nuevo usuario para el trabajo diario y otórguele permisos sudo.

# Reemplace 'ваш_пользователь' con el nombre deseado
sudo adduser ваш_пользователь
sudo usermod -aG sudo ваш_пользователь

Creación de un nuevo usuario y adición al grupo sudo.

Salga de la sesión de root e inicie sesión con el nuevo usuario:

exit
ssh ваш_пользователь@ВАШ_IP_АДРЕС

Salir de root e iniciar sesión con el nuevo usuario.

4. Configuración de claves SSH (recomendado)

Para mejorar la seguridad, se recomienda utilizar claves SSH en lugar de contraseñas. Genere las claves en su máquina local (si aún no lo ha hecho):

# En su máquina local
ssh-keygen -t rsa -b 4096 -C "[email protected]"

Generación de clave SSH (localmente).

Luego, copie la clave pública al servidor (reemplace ваш_пользователь y ВАШ_IP_АДРЕС):

# En su máquina local
ssh-copy-id ваш_пользователь@ВАШ_IP_АДРЕС

Copia de la clave pública SSH al servidor.

Después de esto, desactive el inicio de sesión con contraseña para SSH (recomendado). Edite el archivo /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Apertura del archivo de configuración del servidor SSH.

Encuentre y modifique las siguientes líneas (o agréguelas si no existen):

PasswordAuthentication no
PermitRootLogin no

Desactivación de la autenticación por contraseña y el inicio de sesión para root.

Guarde el archivo (Ctrl+O, Enter) y salga (Ctrl+X). Reinicie el servicio SSH:

sudo systemctl restart sshd

Reinicio del servicio SSH.

5. Configuración del firewall (UFW)

Uncomplicated Firewall (UFW) es una interfaz fácil de usar para iptables. Lo configuraremos para permitir solo las conexiones necesarias.

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh          # Permitir SSH (puerto 22)
sudo ufw allow http         # Permitir HTTP (puerto 80)
sudo ufw allow https        # Permitir HTTPS (puerto 443)
sudo ufw enable
sudo ufw status verbose

Instalación de UFW, configuración de reglas predeterminadas, permiso de SSH, HTTP, HTTPS y activación del firewall.

6. Instalación de Fail2ban

Fail2ban escanea los registros del servidor en busca de actividades sospechosas (por ejemplo, múltiples intentos fallidos de inicio de sesión SSH) y bloquea temporalmente las direcciones IP de los infractores.

sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Instalación de Fail2ban e inicio del servicio.

Cree una copia del archivo de configuración para personalizarlo:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Copia y edición de la configuración de Fail2ban.

En el archivo jail.local, asegúrese de que la sección [sshd] esté activa (enabled = true) y, si lo desea, configure bantime (tiempo de bloqueo) y findtime (período para detectar infracciones).

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Ejemplo de configuración de Fail2ban para SSH.

Guarde y cierre el archivo, luego reinicie Fail2ban:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Reinicio de Fail2ban y verificación del estado del filtro SSH.

Su servidor ahora está preparado y protegido de forma básica. Puede proceder con la instalación del software principal.

Instalación de software — paso a paso

Para desplegar Umami, utilizaremos Docker y Docker Compose. Esto nos permitirá gestionar fácilmente la aplicación Umami y su base de datos PostgreSQL en contenedores aislados, y Nginx actuará como proxy inverso para manejar las solicitudes web y HTTPS.

1. Instalación de Docker Engine

Comenzaremos con la instalación de Docker Engine y Docker Compose. Utilizaremos el script oficial para instalar la última versión estable de Docker, relevante para el año 2026 (suponemos que será la versión 26.x o posterior).

# Instalamos los paquetes necesarios para la instalación de Docker
sudo apt update
sudo apt install ca-certificates curl gnupg lsb-release -y

# Añadimos la clave GPG oficial de Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Añadimos el repositorio de Docker a las fuentes de APT
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Actualizamos la lista de paquetes teniendo en cuenta el nuevo repositorio
sudo apt update

# Instalamos Docker Engine, Docker CLI y Containerd
sudo apt install docker-ce docker-ce-cli containerd.io -y

# Añadimos el usuario actual al grupo docker para no usar sudo con los comandos docker
sudo usermod -aG docker ваш_попользователь

Instalación de Docker Engine y adición del usuario al grupo docker.

Salga de la sesión SSH y vuelva a iniciar sesión para que los cambios en los grupos surtan efecto:

exit
ssh ваш_пользователь@ВАШ_IP_АДРЕС

Reconexión para aplicar los cambios de grupo.

Verifique la instalación de Docker:

docker run hello-world

Ejecución de un contenedor de prueba de Docker.

Debería ver un mensaje de bienvenida de Docker.

2. Instalación de Docker Compose

Docker Compose se instala normalmente como un plugin de Docker CLI; la versión actual para 2026 será 2.x.

# Verificamos si Docker Compose está instalado como plugin
docker compose version

# Si no está instalado, lo instalamos (si es necesario)
# Instalación de Docker Compose como plugin de Docker CLI
sudo apt update
sudo apt install docker-compose-plugin -y

Verificación e instalación del plugin Docker Compose.

Verifique la instalación de Docker Compose:

docker compose version

Verificación de la versión de Docker Compose.

3. Instalación de Nginx

Nginx actuará como un servidor proxy inverso para Umami y proporcionará el manejo del tráfico HTTPS.

sudo apt update
sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

Instalación de Nginx e inicio del servicio.

Verifique el estado de Nginx:

sudo systemctl status nginx

Verificación del estado de Nginx.

Debería ver que Nginx está activo (active (running)).

4. Creación del archivo Docker Compose para Umami y PostgreSQL

Cree un directorio para su proyecto Umami y navegue hasta él:

mkdir umami
cd umami

Creación del directorio del proyecto y navegación al mismo.

Cree el archivo docker-compose.yml:

nano docker-compose.yml

Creación del archivo Docker Compose.

Pegue el siguiente contenido. Tenga en cuenta las versiones de las imágenes: postgres:16 (o postgres:17, actual para 2026) y umami-software/umami:postgresql-latest (o una versión estable específica, por ejemplo, v2.10.1 o v3.x, actual para 2026). Siempre verifique los lanzamientos oficiales de Umami y el Docker Hub para PostgreSQL para las versiones estables más recientes.

version: '3.8'

services:
  umami:
    image: umami-software/umami:postgresql-latest # O una versión específica, por ejemplo v2.10.1, v3.0.0
    container_name: umami
    restart: always
    ports:
      - "3000:3000" # Umami escucha en el puerto 3000 dentro del contenedor
    environment:
      # ¡Reemplace estos valores con los suyos! APP_SECRET debe ser una cadena aleatoria larga.
      DATABASE_URL: postgresql://umami:your_db_password@db:5432/umami
      APP_SECRET: your_super_secret_key_for_umami_app
      # Opciones adicionales, si son necesarias, por ejemplo, para notificaciones por correo electrónico
      # SMTP_HOST: smtp.example.com
      # SMTP_PORT: 587
      # SMTP_USER: [email protected]
      # SMTP_PASS: your_smtp_password
      # SMTP_SENDER: [email protected]
    depends_on:
      - db
    volumes:
      - ./umami-data:/app/umami-data # Para almacenar archivos, si Umami los utiliza

  db:
    image: postgres:16 # O postgres:17, actual para 2026
    container_name: umami-db
    restart: always
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: your_db_password # ¡Reemplace con una contraseña segura!
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

Configuración de Docker Compose para Umami y PostgreSQL.

IMPORTANTE:

• Reemplace your_db_password con una contraseña compleja y única.
• Reemplace your_super_secret_key_for_umami_app con una cadena larga y aleatoria. Puede generarla con el comando openssl rand -base64 32.
• Asegúrese de que DATABASE_URL en el servicio umami coincida con las credenciales para db.

# Ejemplo de generación de APP_SECRET
openssl rand -base64 32

Generación de clave aleatoria para APP_SECRET.

Guarde el archivo (Ctrl+O, Enter) y salga (Ctrl+X).

5. Inicialización de la base de datos de Umami

Antes de iniciar Umami, es necesario inicializar la base de datos. Esto se hace con el comando db-push, que crea las tablas necesarias.

# Iniciamos solo el servicio de la base de datos para que esté listo
docker compose up -d db

# Esperamos unos segundos a que la base de datos se inicie
sleep 10

# Inicializamos la base de datos de Umami
docker compose exec umami yarn db-push

Inicio de la base de datos e inicialización de Umami.

Si ve un mensaje como "Database is already in sync", significa que las tablas ya han sido creadas.

6. Inicio de Umami y PostgreSQL

Ahora que la base de datos está inicializada, podemos iniciar todos los servicios:

docker compose up -d

Inicio de todos los servicios de Docker Compose en segundo plano.

Verifique el estado de los contenedores en ejecución:

docker compose ps

Verificación del estado de los contenedores.

Ambos contenedores (umami y umami-db) deben estar en estado running.

En este punto, Umami está disponible dentro de su VPS en el puerto 3000 (http://localhost:3000). El siguiente paso será configurar Nginx para acceder a ella desde el exterior a través de un nombre de dominio y HTTPS.

Configuración

Después de instalar todos los componentes, es necesario configurar Nginx como proxy inverso para Umami y asegurar una conexión HTTPS segura utilizando Let's Encrypt.

1. Configuración del nombre de dominio

Antes de continuar, asegúrese de tener un nombre de dominio (por ejemplo, analytics.yourdomain.com) y que su registro A apunte a la dirección IP de su VPS. La propagación de los cambios de DNS puede tardar algún tiempo (hasta varias horas), así que asegúrese de hacerlo con antelación.

2. Configuración de Nginx para Umami

Crearemos un nuevo archivo de configuración de Nginx para su dominio. Reemplace analytics.yourdomain.com con su dominio real.

sudo nano /etc/nginx/sites-available/analytics.yourdomain.com

Creación del archivo de configuración de Nginx.

Pegue el siguiente contenido:

server {
    listen 80;
    listen [::]:80;
    server_name analytics.yourdomain.com; # Reemplace con su dominio

    location / {
        proxy_pass http://localhost:3000; # Umami escucha en el puerto 3000 dentro del VPS
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Configuración de Nginx para proxy inverso a Umami.

Guarde el archivo (Ctrl+O, Enter) y salga (Ctrl+X).

3. Activación de la configuración de Nginx

Cree un enlace simbólico al archivo de configuración en el directorio sites-enabled y verifique la sintaxis de Nginx.

sudo ln -s /etc/nginx/sites-available/analytics.yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

Creación de enlace simbólico y verificación de la sintaxis de Nginx.

Si la prueba fue exitosa (syntax is ok, test is successful), reinicie Nginx:

sudo systemctl restart nginx

Reinicio de Nginx.

4. Configuración de TLS/HTTPS con Certbot (Let's Encrypt)

Para asegurar una conexión HTTPS, utilizaremos Certbot para obtener y renovar automáticamente certificados SSL/TLS gratuitos de Let's Encrypt.

# Instalación de Certbot
sudo apt install certbot python3-certbot-nginx -y

# Obtención del certificado (reemplace con su dominio y email)
sudo certbot --nginx -d analytics.yourdomain.com --email [email protected] --agree-tos --no-eff-email

Instalación de Certbot y obtención del certificado Let's Encrypt.

Certbot modificará automáticamente la configuración de Nginx, añadiendo los ajustes HTTPS y la redirección de HTTP a HTTPS. También configurará la renovación automática de certificados a través de un cronjob o un temporizador de systemd.

Verifique que Certbot haya configurado la renovación automática:

sudo systemctl status certbot.timer

Verificación del estado del temporizador de Certbot para la renovación automática.

Debería ver que el temporizador está activo y en ejecución.

5. Verificación de la funcionalidad

Ahora Umami debería ser accesible a través de su dominio por HTTPS.

curl -I https://analytics.yourdomain.com

Verificación de los encabezados HTTP de su dominio.

Debería ver el estado HTTP/2 200 y los encabezados que indican Nginx y el certificado SSL.

Abra un navegador web y vaya a https://analytics.yourdomain.com. Debería ver la página de inicio de sesión de Umami. Las credenciales estándar son:

• Username: admin
• Password: umami

¡Asegúrese de cambiar la contraseña de administrador inmediatamente después del primer inicio de sesión!

Después de iniciar sesión, podrá añadir su primer sitio web para el seguimiento. Umami le proporcionará un pequeño código JavaScript que deberá insertar en la sección <head> de su sitio.

<script async src="https://analytics.yourdomain.com/script.js" data-website-id="SU_ID_DEL_SITIO"></script>
    

Ejemplo de script de seguimiento de Umami.

Reemplace https://analytics.yourdomain.com/script.js con su URL real y SU_ID_DEL_SITIO con el ID que Umami generará para su sitio.

Copias de seguridad y mantenimiento

Las copias de seguridad y el mantenimiento regular son cruciales para cualquier sistema en producción. El incumplimiento de estas prácticas puede llevar a la pérdida de datos y a tiempos de inactividad.

Qué respaldar

Para Umami, desplegado con Docker, PostgreSQL y Nginx, es necesario realizar copias de seguridad regulares de los siguientes componentes:

• Base de datos PostgreSQL: Contiene todos sus datos analíticos. Este es el componente más importante.
• Archivos de configuración de Umami: El archivo docker-compose.yml y cualquier archivo .env relacionado que contenga variables de entorno y secretos.
• Archivos de configuración de Nginx: El archivo /etc/nginx/sites-available/analytics.yourdomain.com y otras configuraciones personalizadas de Nginx.
• Certificados SSL de Let's Encrypt: Aunque Certbot los renueva, tener una copia no está de más. Se almacenan en /etc/letsencrypt/.

Script simple de copia de seguridad automática

Crearemos un script simple en Bash que realizará copias de seguridad de PostgreSQL y de los archivos de configuración. Utilizaremos pg_dump para PostgreSQL y rsync para los archivos.

Cree un directorio para las copias de seguridad en su VPS:

mkdir -p ~/backups/umami

Creación del directorio para las copias de seguridad.

Cree el archivo de script backup_umami.sh:

nano ~/backup_umami.sh

Creación del script de copia de seguridad.

Pegue el siguiente contenido, reemplazando your_db_password con la contraseña real de la base de datos de Umami:

#!/bin/bash

# --- Configuración ---
BACKUP_DIR="/home/su_usuario/backups/umami" # Ruta al directorio de copias de seguridad
DATE=$(date +%Y%m%d%H%M%S)
DB_CONTAINER_NAME="umami-db"
DB_NAME="umami"
DB_USER="umami"
DB_PASSWORD="your_db_password" # Contraseña de la base de datos de Umami
UMAMI_COMPOSE_DIR="/home/su_usuario/umami" # Directorio con docker-compose.yml

# --- Creación del directorio de copia de seguridad para la fecha actual ---
CURRENT_BACKUP_DIR="$BACKUP_DIR/$DATE"
mkdir -p "$CURRENT_BACKUP_DIR"

echo "Iniciando la copia de seguridad de Umami en $CURRENT_BACKUP_DIR..."

# --- Copia de seguridad de la base de datos PostgreSQL ---
echo "Copia de seguridad de la base de datos PostgreSQL..."
# Usamos docker exec para ejecutar pg_dump dentro del contenedor de la base de datos
docker exec "$DB_CONTAINER_NAME" pg_dump -U "$DB_USER" -d "$DB_NAME" > "$CURRENT_BACKUP_DIR/umami_db_backup.sql"
if [ $? -eq 0 ]; then
    echo "Copia de seguridad de la base de datos creada con éxito."
else
    echo "¡Error al crear la copia de seguridad de la base de datos!"
fi

# --- Copia de seguridad de los archivos de configuración ---
echo "Copia de seguridad de los archivos de configuración de Umami..."
rsync -avz "$UMAMI_COMPOSE_DIR/docker-compose.yml" "$CURRENT_BACKUP_DIR/"
rsync -avz "$UMAMI_COMPOSE_DIR/.env" "$CURRENT_BACKUP_DIR/" # Si usa un archivo .env
echo "Copia de seguridad de los archivos de Umami completada."

echo "Copia de seguridad de la configuración de Nginx..."
rsync -avz /etc/nginx/sites-available/analytics.yourdomain.com "$CURRENT_BACKUP_DIR/nginx_umami.conf"
echo "Copia de seguridad de Nginx completada."

echo "Copia de seguridad de los certificados de Let's Encrypt (enlaces simbólicos)..."
# Copiamos solo los enlaces simbólicos, no los certificados en sí,
# ya que pueden ser grandes y contener muchos archivos.
# Para una recuperación completa, es mejor volver a emitirlos con certbot --nginx
rsync -avzL /etc/letsencrypt/live/analytics.yourdomain.com "$CURRENT_BACKUP_DIR/letsencrypt_symlinks"
echo "Copia de seguridad de los certificados de Let's Encrypt completada."

echo "Copia de seguridad completada."

# --- Limpieza de copias de seguridad antiguas (opcional, conservamos los últimos 7 días) ---
echo "Eliminando copias de seguridad antiguas (más de 7 días)..."
find "$BACKUP_DIR" -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;
echo "Limpieza completada."

Script de copia de seguridad para Umami.

Haga el script ejecutable:

chmod +x ~/backup_umami.sh

Concesión de permisos de ejecución al script.

Dónde almacenar (S3 externo / VPS separado)

Almacenar las copias de seguridad en el mismo servidor que los datos originales es extremadamente arriesgado. Si el servidor falla, perderá tanto los datos como las copias de seguridad. Utilice siempre almacenamiento remoto:

• Almacenamiento en la nube (compatible con S3): Servicios como Amazon S3, DigitalOcean Spaces, Backblaze B2 ofrecen almacenamiento fiable y económico. Puede utilizar utilidades como rclone para sincronizar automáticamente las copias de seguridad locales con S3.
• VPS separado: Puede tener un segundo VPS, menos potente, que reciba las copias de seguridad del servidor principal a través de SCP/SFTP o rsync.
• NAS/PC local: Para proyectos muy pequeños, puede descargar periódicamente las copias de seguridad a su ordenador o a un almacenamiento en red.

Por ejemplo, para enviar copias de seguridad a S3 usando rclone (después de su instalación y configuración):

# Añadir al script backup_umami.sh
echo "Enviando copias de seguridad a S3..."
rclone sync "$BACKUP_DIR" "my_s3_remote:umami-backups" # Reemplace con el nombre de su almacenamiento remoto
echo "Envío a S3 completado."

Ejemplo de comando rclone para enviar copias de seguridad al almacenamiento en la nube.

Configuración de Cron para la ejecución automática de copias de seguridad

Edite la programación de Cron para su usuario:

crontab -e

Apertura del archivo crontab para edición.

Añada la siguiente línea para ejecutar la copia de seguridad diariamente, por ejemplo, a las 03:00 de la mañana:

0 3 * * * /home/su_usuario/backup_umami.sh >> /home/su_usuario/backups/umami_backup.log 2>&1

Adición de una tarea Cron para la copia de seguridad diaria.

Esta línea ejecuta el script diariamente a las 3 de la mañana y redirige toda la salida a un archivo de registro umami_backup.log.

Actualizaciones: rolling vs ventana de mantenimiento

Las actualizaciones regulares de software son importantes para la seguridad y para obtener nuevas funciones. Para Umami y sus componentes:

• Actualización de contenedores Docker (Umami, PostgreSQL):

  Esto se puede hacer con un pequeño tiempo de inactividad. Se recomienda planificar una "ventana de mantenimiento" (maintenance window) cuando el tráfico del sitio sea mínimo.

  
  cd ~/umami
  docker compose pull             # Descargar nuevas imágenes
  docker compose down             # Detener y eliminar contenedores antiguos
  docker compose up -d            # Iniciar nuevos contenedores
  

  Actualización de los contenedores Docker de Umami y PostgreSQL.

  Después de la actualización de Umami, puede ser necesaria una reinicialización de la base de datos si hubo cambios en el esquema en la nueva versión: docker compose exec umami yarn db-push.

• Actualización de paquetes del sistema (Nginx, Docker Engine, Certbot, OS):

  Esto debe hacerse regularmente, por ejemplo, una vez al mes. Algunas actualizaciones pueden requerir un reinicio del servidor.

  
  sudo apt update && sudo apt upgrade -y
  sudo apt autoremove -y
  # Si hubo actualizaciones del kernel o componentes críticos, puede ser necesario un reinicio
  # sudo reboot
              

  Actualización de paquetes del sistema.

Siempre revise los registros después de las actualizaciones para asegurarse de que todos los servicios funcionan correctamente.

Solución de problemas + Preguntas frecuentes

Incluso con una configuración cuidadosa, pueden surgir problemas. Esta sección le ayudará a diagnosticar y solucionar los problemas más comunes, además de responder a las preguntas frecuentes.

¿Qué hacer si Umami no se conecta a la base de datos?

Error: Ve mensajes en los registros de Umami o en la página web sobre la imposibilidad de conectarse a la base de datos (Cannot connect to database, Connection refused).

Qué verificar:

• Registros del contenedor PostgreSQL: docker compose logs db. Asegúrese de que PostgreSQL se esté ejecutando sin errores.
• Registros del contenedor Umami: docker compose logs umami. Busque errores relacionados con la conexión a la base de datos.
• Variables de entorno: Asegúrese de que DATABASE_URL en el archivo docker-compose.yml para el servicio umami coincida exactamente con las credenciales de PostgreSQL (nombre de usuario, contraseña, nombre de la base de datos) y el nombre del servicio de la base de datos (db).
• Puertos: Asegúrese de que los contenedores puedan comunicarse entre sí a través de la red interna de Docker (por defecto, Docker Compose crea su propia red).

Cómo solucionarlo: Vuelva a verificar DATABASE_URL y las variables de entorno para PostgreSQL. Asegúrese de que las contraseñas coincidan. Si ha modificado docker-compose.yml, reinicie los contenedores: docker compose down && docker compose up -d. Si PostgreSQL no se inicia, verifique si el servidor tiene suficiente RAM o espacio libre en disco.

Nginx devuelve 502 Bad Gateway o 504 Gateway Timeout.

Error: Al intentar acceder a Umami a través del navegador, ve un error de Nginx 502 o 504.

Qué verificar:

• Estado del contenedor Umami: docker compose ps. Asegúrese de que el contenedor umami esté en estado running.
• Registros de Nginx: sudo tail -f /var/log/nginx/error.log. Busque errores relacionados con el proxy.
• Registros de Umami: docker compose logs umami. Es posible que Umami no se inicie o falle inmediatamente después de arrancar.
• Puerto de Umami: Asegúrese de que Nginx esté haciendo proxy de las solicitudes al puerto correcto (http://localhost:3000) y que Umami realmente esté escuchando en ese puerto dentro del VPS.

Cómo solucionarlo: Si el contenedor Umami no está en ejecución, revise sus registros e intente iniciarlo manualmente. Si el problema está en Nginx, asegúrese de que proxy_pass en el archivo de configuración de Nginx esté especificado correctamente. Es posible que Umami necesite más tiempo para iniciarse y Nginx agote el tiempo de espera; en este caso, puede aumentar proxy_read_timeout en la configuración de Nginx.

Certbot no puede obtener un certificado Let's Encrypt.

Error: certbot --nginx devuelve errores relacionados con la verificación del dominio o la conexión.

Qué verificar:

• Registros DNS: Asegúrese de que el registro A de su dominio (por ejemplo, analytics.yourdomain.com) apunte correctamente a la dirección IP de su VPS. Use dig analytics.yourdomain.com para verificar. Los cambios de DNS pueden tardar hasta 24 horas.
• Cortafuegos UFW: Asegúrese de que los puertos 80 (HTTP) y 443 (HTTPS) estén abiertos. sudo ufw status verbose.
• Nginx: Asegúrese de que Nginx esté en ejecución y escuchando correctamente en el puerto 80. Certbot usa Nginx para la verificación del dominio.
• Límites de tasa de Let's Encrypt: Si ha intentado obtener un certificado muchas veces, es posible que haya alcanzado los límites de tasa de Let's Encrypt. Espere una hora o use la bandera --staging para intentos de prueba.

Cómo solucionarlo: Corrija los registros DNS, abra los puertos en UFW, asegúrese de que Nginx esté funcionando. Si el problema persiste, intente ejecutar Certbot con la bandera --dry-run para simular la obtención de un certificado sin una solicitud real.

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

Para una instalación básica de Umami y el seguimiento de un sitio web pequeño o mediano (hasta 50.000 páginas vistas al mes), un VPS con 1 núcleo de CPU, 2 GB de RAM y 40 GB de disco SSD es mínimamente adecuado. Esto será suficiente para el funcionamiento cómodo de Umami y PostgreSQL, así como para los procesos del sistema. Es importante que el disco sea SSD para garantizar un buen rendimiento de la base de datos.

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

La elección entre un VPS y un servidor dedicado depende de la escala de su proyecto y los requisitos de recursos. Para la mayoría de los usuarios, incluidos desarrolladores, fundadores individuales y propietarios de sitios web medianos, un VPS es la opción óptima. Ofrece suficiente rendimiento, flexibilidad y rentabilidad. Un servidor dedicado solo es aconsejable para cargas muy altas (millones de páginas vistas al mes), cuando se requiere el máximo rendimiento, control total sobre el hardware o si planea alojar muchas otras aplicaciones que consumen muchos recursos junto con Umami.

¿Cómo actualizar Umami y otros componentes?

Para actualizar Umami y PostgreSQL (que se ejecutan en contenedores Docker), vaya al directorio con su docker-compose.yml y ejecute: docker compose pull (para descargar nuevas imágenes) y luego docker compose up -d (para reiniciar los contenedores con las nuevas imágenes). Para actualizar Nginx, Docker Engine y el sistema operativo, use los comandos estándar del gestor de paquetes: sudo apt update && sudo apt upgrade -y. Siempre haga copias de seguridad antes de actualizaciones importantes.

¿Cómo restablecer la contraseña de administrador de Umami?

Si olvidó la contraseña de administrador de Umami, puede restablecerla ejecutando un comando directamente en el contenedor de Umami (o a través de la base de datos PostgreSQL). Para 2026, Umami probablemente tendrá una herramienta CLI para la gestión de usuarios. Si no, se puede hacer a través de una consulta SQL. Ejemplo (verifique la documentación actual de Umami):

# Conéctese al contenedor de Umami
docker compose exec umami bash

# Ejecute el comando para restablecer la contraseña (ejemplo, el comando puede cambiar)
# yarn umami-cli users reset-password admin new_strong_password
# O si no hay una CLI directa, tendrá que trabajar con la base de datos

Ejemplo de restablecimiento de la contraseña de administrador de Umami.

Si no hay una herramienta CLI, tendrá que cambiar directamente el hash de la contraseña en la tabla _User en la base de datos PostgreSQL. Este es un proceso más complejo y requiere conocimientos de SQL y la estructura de la base de datos de Umami.

Conclusiones y próximos pasos

¡Felicidades! Ha instalado y configurado con éxito Umami Web Analytics en su VPS, utilizando Docker, PostgreSQL y Nginx. Ahora tiene una herramienta potente, privada y totalmente controlada para recopilar análisis de su sitio web, que respeta la privacidad del usuario y le otorga soberanía total sobre sus datos. Ha aprendido no solo a implementar una aplicación compleja, sino también a garantizar su seguridad, operatividad y fiabilidad mediante copias de seguridad y mantenimiento.

Próximos pasos

Para aprovechar al máximo su nuevo sistema de análisis y continuar desarrollándose:

• Agregue todos sus sitios web: Inicie sesión en el panel de Umami, agregue todos los proyectos que desea rastrear e inserte los scripts generados en sus páginas.
• Explore las funciones adicionales de Umami: Umami admite el seguimiento de eventos personalizados, lo que le permite obtener una comprensión más profunda de la interacción de los usuarios con su sitio. Configure el seguimiento de clics en botones, envíos de formularios y otras acciones clave.
• Monitoreo del servidor: Instale herramientas de monitoreo (por ejemplo, Prometheus + Grafana, Netdata o Zabbix) para rastrear la carga de la CPU, el uso de la RAM, el espacio en disco y el tráfico de red de su VPS. Esto le ayudará a identificar problemas potenciales de antemano y a planificar la escalabilidad.
• Optimización y escalabilidad futuras: A medida que el tráfico crezca, considere optimizar el rendimiento de PostgreSQL (por ejemplo, ajustando postgresql.conf), el almacenamiento en caché de Nginx o incluso escalar Umami horizontalmente a múltiples instancias de Docker.

Gracias a esta guía, ha sentado una base sólida para su análisis web privado, que puede desarrollarse y adaptarse a cualquier necesidad futura.