Instalación de SFTPGo en un VPS: servidor SFTP seguro, panel web y almacenamiento S3

1. TL;DR

SFTPGo es adecuado cuando se necesita un portal de archivos y un servidor SFTP propios sin depender de un proveedor SaaS. El servicio proporciona una interfaz web para administradores y usuarios, y admite SFTP, HTTP/S, WebDAV, FTP/S, cuotas y la conexión de almacenes compatibles con S3.

Para un equipo pequeño basta con un VPS con 2 vCPU, 4 GB de RAM y un disco SSD de al menos 40 GB. Si los archivos se almacenan en S3, el disco local se necesita principalmente para los contenedores, la base de datos, los registros y las operaciones temporales. Si se utiliza un sistema de archivos local, el tamaño del disco debe corresponder al volumen de datos, con una reserva de al menos el 25–30 por ciento.

• La interfaz administrativa no se publica en un puerto aleatorio: solo se expone mediante Caddy y HTTPS.
• SFTP funciona en un puerto TCP independiente, por ejemplo, 2022.
• Los datos de SFTPGo y PostgreSQL se encuentran en Docker volumes persistentes.
• Las contraseñas y claves de acceso a la base de datos no se escriben en la configuración del servidor web.
• La copia de seguridad incluye la base de datos, la configuración, Docker Compose y los datos de los usuarios.

2. Contenido

El artículo está dirigido al propietario de un VPS que quiere desplegar SFTPGo por su cuenta y controlar el acceso a los archivos. Los comandos están indicados para Ubuntu Server 24.04 LTS con un usuario que tenga permisos sudo.

1. Primero definiremos la arquitectura: SFTPGo, PostgreSQL, Caddy y S3 externo.
2. Después prepararemos el servidor: actualizaremos el SO, crearemos un usuario independiente y configuraremos SSH, UFW y Fail2ban.
3. A continuación iniciaremos los contenedores y comprobaremos los registros, los puertos y las respuestas HTTP.
4. En el panel web crearemos un administrador, un usuario normal y conectaremos un bucket S3.
5. Por último, configuraremos las copias de seguridad y el procedimiento de actualización.

3. Qué configuramos y por qué

Qué es SFTPGo

SFTPGo es un sistema de servidor para el intercambio seguro de archivos. El protocolo principal de esta guía es SFTP sobre SSH. A diferencia de un usuario normal del sistema Linux, el usuario de SFTPGo se administra desde la aplicación: se le puede asignar una cuota, un directorio de inicio, carpetas virtuales, permisos de carga y descarga, una fecha de caducidad de la cuenta y restricciones por IP.

SFTPGo cuenta con un panel web administrativo independiente. Desde él se crean usuarios, grupos, políticas de almacenamiento, claves SSH y tokens. La interfaz web de usuario permite intercambiar archivos mediante el navegador, por lo que no es obligatorio instalar un cliente SFTP para cargar documentos normalmente.

Esquema objetivo

Resultado final

Después de completar las instrucciones, SFTPGo estará disponible en una dirección como https://files.example.com. El usuario podrá iniciar sesión en el panel web o conectarse desde WinSCP, Cyberduck, FileZilla, la línea de comandos de Linux y otros clientes.

La base administrativa se almacenará en PostgreSQL y los archivos podrán ubicarse en S3. Esto separa la aplicación de los datos: no es necesario combinar el reemplazo del VPS o del contenedor con la migración de un gran volumen de archivos. Sin embargo, la base de datos y la configuración siguen requiriendo copias de seguridad.

Self-hosted o servicio en la nube

Los servicios de intercambio de archivos en la nube son más sencillos de empezar a utilizar: no es necesario actualizar el SO, supervisar TLS ni configurar copias de seguridad. A cambio, hay que pagar una cuota periódica, aceptar las limitaciones de los planes y transferir los datos a un operador externo.

La opción self-hosted en un VPS está justificada si se necesita controlar la ubicación de los datos, aplicar una política de acceso propia e integrarse con S3, LDAP o sistemas internos. El propietario del servidor es responsable de las actualizaciones y las copias de seguridad, pero puede elegir por sí mismo los protocolos, los límites y el esquema de almacenamiento.

Cuándo SFTPGo no es la mejor opción

Si solo se necesita transferir algunos archivos una vez, un servicio completo será excesivo. Para sincronizar directorios de trabajo entre portátiles pueden ser más adecuados Nextcloud, Syncthing o herramientas de backup especializadas. SFTPGo resulta especialmente útil cuando se necesitan cuentas administrables, compatibilidad con SFTP, limitación de permisos y acceso a almacenamiento de objetos.

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

Configuración mínima

Para un administrador y varios usuarios, SFTPGo no requiere una gran cantidad de CPU. La carga principal depende del número de conexiones simultáneas, la terminación TLS, la velocidad del almacenamiento y el tamaño de los archivos. Para una instalación de prueba basta con 1 vCPU y 2 GB de RAM, pero para un uso permanente es mejor comenzar con 2 vCPU y 4 GB de RAM.

Si los archivos están en S3, no es necesario comprar un disco del tamaño de todo el archivo. Pero sigue siendo necesario reservar espacio para PostgreSQL, los registros de Docker, los archivos temporales, las copias de seguridad y las actualizaciones. Una opción básica práctica es 2 vCPU, 4 GB de RAM, un SSD NVMe de 60 GB y una IPv4 pública. Para esta configuración puede elegirse un VPS adecuado con Linux y acceso root completo.

Requisitos de red

Se necesita una dirección IPv4 entrante y, preferiblemente, también IPv6. El nombre DNS files.example.com debe apuntar a la dirección del servidor. Para obtener automáticamente un certificado TLS, Caddy necesita que los puertos TCP 80 y 443 estén abiertos. Para SFTP se utilizará un puerto independiente, por ejemplo, 2022.

Compruebe las restricciones del proveedor sobre las conexiones salientes a S3. Algunas redes bloquean determinados rangos o limitan el número de conexiones. Al trabajar con archivos grandes, no solo importa la velocidad del puerto, sino también la estabilidad de la ruta hasta la región de S3.

Cuándo se necesita un dedicated

Un servidor dedicado está justificado si el volumen de almacenamiento local supera varios terabytes, se necesitan varios discos NVMe rápidos, decenas o cientos de cargas simultáneas, o un aislamiento estricto de otras máquinas virtuales. Para SFTPGo, que utiliza S3 externo, pasar a un dedicated normalmente no es el primer paso de escalado.

Primero deben medirse la CPU, la RAM, la E/S y el ancho de banda de red. Si el cuello de botella es únicamente el almacenamiento, resulta más conveniente trasladar los datos a S3 o conectar un servidor de almacenamiento independiente. Un dedicated tiene sentido cuando se necesita un rendimiento predecible de todos los recursos al mismo tiempo.

Elección de la ubicación

Ubique el VPS cerca de los usuarios principales y de la región de S3. Esto reduce la latencia al trabajar con el panel web y realizar transferencias mediante SFTP. Si los datos están sujetos a requisitos legales o a la política de la empresa, la región del servidor y del almacenamiento de objetos debe cumplir dichos requisitos.

5. Preparación del servidor

Actualización del sistema y nombre del host

A continuación se presupone una instalación limpia de Ubuntu Server 24.04 LTS. Conéctese con un usuario temporal que tenga sudo o como root, establezca el nombre del host y actualice los paquetes.

# Задаём имя сервера
sudo hostnamectl set-hostname sftp-01

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

# Перезагружаем сервер, если обновлялось ядро
sudo reboot

Después de reiniciar, vuelva a conectarse por SSH. Cree un usuario independiente para la administración. Utilice su propio nombre en lugar de deploy.

# Создаём обычного пользователя
sudo adduser deploy

# Добавляем его в группу sudo
sudo usermod -aG sudo deploy

# Проверяем принадлежность к группам
id deploy

Claves SSH

En el ordenador local, genere una clave Ed25519 si aún no dispone de una. No transfiera la clave privada al servidor ni la almacene en el proyecto de Docker.

# Выполняется на вашем локальном компьютере
ssh-keygen -t ed25519 -C "deploy@sftp-01"

# Копируем публичный ключ на сервер
ssh-copy-id deploy@SERVER_IP

Compruebe el acceso en una sesión nueva sin cerrar la sesión root actual. Solo después de comprobarlo correctamente podrá desactivar el acceso mediante contraseña.

# Открываем конфигурацию SSH
sudoedit /etc/ssh/sshd_config.d/99-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
MaxAuthTries 3

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

Firewall

Antes de activar UFW, permita el puerto SSH. En el ejemplo, SSH funciona en el puerto estándar 22. Si lo ha cambiado, sustituya el valor por el suyo.

# Устанавливаем UFW и разрешаем SSH, HTTP и HTTPS
sudo apt install -y ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Отдельный порт SFTPGo
sudo ufw allow 2022/tcp

# Включаем firewall с политикой deny incoming
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

# Проверяем активные правила
sudo ufw status verbose

Fail2ban y utilidades básicas

Fail2ban analiza los registros de inicios de sesión fallidos y bloquea temporalmente las direcciones IP. No sustituye a las claves SSH, MFA ni al firewall, pero reduce la cantidad de intentos automatizados.

# Устанавливаем защиту SSH и служебные инструменты
sudo apt install -y fail2ban ca-certificates curl wget git jq unzip \
    htop ncdu unattended-upgrades apt-transport-https

# Включаем Fail2ban при запуске
sudo systemctl enable --now fail2ban

# Создаём локальную настройку jail для SSH
sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
port = 22
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
EOF

# Перезапускаем Fail2ban и проверяем статус
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Si SSH funciona en otro puerto, cambie el parámetro port en el jail y la regla de UFW. No utilice el cambio de puerto como único método de protección: las claves, la prohibición de root y la limitación de intentos son más importantes.

6. Instalación del software — paso a paso

Paso 1. Instalación de Docker desde el repositorio oficial

Para un despliegue reproducible, utilizaremos Docker Engine y Compose Plugin desde el repositorio apt oficial de Docker. En el momento de preparar estas instrucciones para producción, utilice la versión estable actual de Docker Engine 27.x o una versión compatible más reciente disponible en el repositorio.

# Удаляем конфликтующие старые пакеты
sudo apt remove -y docker.io docker-compose docker-doc podman-docker containerd runc || true

# Добавляем официальный ключ репозитория Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
    sudo tee /etc/apt/keyrings/docker.asc > /dev/null
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Подключаем репозиторий для текущего релиза Ubuntu
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Устанавливаем Docker Engine и Compose Plugin
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
    docker-buildx-plugin docker-compose-plugin

# Включаем Docker при загрузке
sudo systemctl enable --now docker

# Проверяем версии
sudo docker version
sudo docker compose version

Paso 2. Acceso del usuario deploy a Docker

Agregar el usuario al grupo docker permite ejecutar Docker sin sudo, pero en la práctica otorga permisos de nivel root. Hágalo únicamente para un administrador de confianza.

# Добавляем deploy в группу Docker
sudo usermod -aG docker deploy

# Обновляем группу в текущей shell-сессии
newgrp docker

# Проверяем запуск без sudo
docker run --rm hello-world

Paso 3. Creación de la estructura del proyecto

Crearemos un directorio independiente. El archivo .env contendrá los secretos y permanecerá únicamente en el servidor.

# Создаём каталог приложения
sudo mkdir -p /opt/sftpgo
sudo chown -R deploy:deploy /opt/sftpgo
cd /opt/sftpgo

# Создаём файл секретов с закрытыми правами
touch .env
chmod 600 .env

# Проверяем текущий каталог
pwd

Paso 4. Secretos del entorno

Genere contraseñas largas y aleatorias. La contraseña de PostgreSQL no debe coincidir con la contraseña del administrador de SFTPGo. La variable SFTPGO_DEFAULT_ADMIN_PASSWORD se utiliza únicamente durante la inicialización inicial, por lo que debe guardarla en un gestor de contraseñas.

# Генерируем случайные значения
DB_PASSWORD=$(openssl rand -hex 32)
ADMIN_PASSWORD=$(openssl rand -base64 30 | tr -dc 'A-Za-z0-9!@#%+=' | head -c 28)

# Записываем переменные в .env
cat > .env <<EOF
POSTGRES_DB=sftpgo
POSTGRES_USER=sftpgo
POSTGRES_PASSWORD=${DB_PASSWORD}
SFTPGO_ADMIN_USERNAME=admin
SFTPGO_ADMIN_PASSWORD=${ADMIN_PASSWORD}
EOF

# Показываем только имена переменных, не значения
cut -d= -f1 .env

Paso 5. Docker Compose

A continuación se utilizan PostgreSQL 16 y la imagen oficial de SFTPGo. La etiqueta v2.6.x debe sustituirse por la última versión patch estable concreta de 2.6, comprobada antes de la instalación. No utilice permanentemente la etiqueta variable latest en un sistema crítico sin realizar pruebas.

# Создаём Docker Compose файл
cat > compose.yml <<'EOF'
services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    env_file:
      - .env
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - backend

  sftpgo:
    image: drakkan/sftpgo:v2.6.x
    restart: unless-stopped
    env_file:
      - .env
    environment:
      SFTPGO_DATA_PROVIDER__DRIVER: postgresql
      SFTPGO_DATA_PROVIDER__NAME: ${POSTGRES_DB}
      SFTPGO_DATA_PROVIDER__HOST: postgres
      SFTPGO_DATA_PROVIDER__PORT: 5432
      SFTPGO_DATA_PROVIDER__USERNAME: ${POSTGRES_USER}
      SFTPGO_DATA_PROVIDER__PASSWORD: ${POSTGRES_PASSWORD}
      SFTPGO_DEFAULT_ADMIN_USERNAME: ${SFTPGO_ADMIN_USERNAME}
      SFTPGO_DEFAULT_ADMIN_PASSWORD: ${SFTPGO_ADMIN_PASSWORD}
      SFTPGO_SFTPD__BINDINGS__0__PORT: 2022
      SFTPGO_HTTPD__BINDINGS__0__PORT: 8080
      SFTPGO_HTTPD__BINDINGS__0__BIND_ADDRESS: 0.0.0.0
    ports:
      - "2022:2022"
      - "127.0.0.1:8080:8080"
    volumes:
      - sftpgo_data:/var/lib/sftpgo
      - sftpgo_home:/srv/sftpgo
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - backend

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - sftpgo
    networks:
      - backend

volumes:
  postgres_data:
  sftpgo_data:
  sftpgo_home:
  caddy_data:
  caddy_config:

networks:
  backend:
EOF

En Compose se utilizan dos volúmenes persistentes de SFTPGo. El primero almacena la configuración y los datos internos de la aplicación; el segundo está destinado al directorio de inicio local de los usuarios. Aunque el backend principal sea S3, estos volúmenes no deben eliminarse sin una copia de seguridad.

Paso 6. Inicio de la base de datos y SFTPGo

# Проверяем итоговую конфигурацию Compose
docker compose config

# Загружаем образы и запускаем PostgreSQL и SFTPGo
docker compose up -d postgres sftpgo

# Проверяем состояние контейнеров
docker compose ps

# Смотрим журнал запуска SFTPGo
docker compose logs --tail=100 sftpgo

Durante el primer inicio, SFTPGo crea las tablas de PostgreSQL y el usuario administrador. Si el contenedor se reinicia, compruebe primero el registro de la base de datos: la causa más frecuente son variables de conexión incorrectas, un volume dañado o el inicio de la aplicación antes de que PostgreSQL esté listo.

Paso 7. Instalación de Caddy

Caddy funcionará en un contenedor independiente y hará proxy de la interfaz web de SFTPGo. Las conexiones SFTP no pasan por Caddy: el puerto 2022 se publica directamente mediante el contenedor de SFTPGo.

# Создаём Caddyfile с доменным именем
cat > Caddyfile <<'EOF'
files.example.com {
    reverse_proxy sftpgo:8080

    header {
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        X-Frame-Options "SAMEORIGIN"
    }

    encode zstd gzip
}
EOF

# Запускаем reverse proxy
docker compose up -d caddy

# Проверяем все сервисы
docker compose ps

Sustituya files.example.com por su propio nombre DNS antes de iniciar Caddy. Si el DNS aún no se ha actualizado, el contenedor funcionará, pero no podrá obtener el certificado automático.

7. Configuración

Comprobación de DNS, HTTPS y SFTP

Primero, asegúrese de que el dominio resuelve a la dirección correcta. Realice la comprobación desde el ordenador local u otra máquina en Internet.

# Проверяем DNS-запись
dig +short files.example.com

# Проверяем HTTPS и цепочку перенаправления
curl -I https://files.example.com

# Проверяем SFTP-порт
nc -vz files.example.com 2022

# Проверяем локальный HTTP-порт на сервере
curl -I http://127.0.0.1:8080

La respuesta HTTPS esperada es 200, 302 u otra respuesta de la aplicación sin errores de TLS. El comando nc debe mostrar una conexión TCP exitosa. Si el puerto está disponible localmente, pero no desde el exterior, compruebe UFW y las reglas del firewall de red en el panel del VPS.

Primer acceso al panel

Abra https://files.example.com e inicie sesión con el nombre de usuario y la contraseña del archivo .env. Cambie inmediatamente la contraseña inicial en la interfaz y guárdela en un gestor de contraseñas. No utilice la cuenta de administrador para la transferencia diaria de archivos.

En el panel, compruebe las secciones de configuración de HTTP, SFTP, usuarios, grupos y registros. Si en el futuro cambia el puerto o el binding mediante la interfaz web, tenga en cuenta que las variables de entorno de Compose se aplican al crear el contenedor y pueden ser sobrescritas por la configuración de la aplicación.

Creación de un usuario para SFTP

1. Abra la sección de usuarios y cree una cuenta nueva.
2. Establezca un nombre único y una contraseña larga, o añada una SSH public key.
3. Indique el directorio de inicio o una carpeta virtual.
4. Limite los permisos: normalmente bastan list, download y upload.
5. Establezca una cuota de espacio en disco y el número de archivos.
6. Si es necesario, limite las direcciones IP permitidas.
7. Guarde el usuario y realice una conexión de prueba.

Para las integraciones de servicios, es preferible utilizar un usuario independiente con permisos mínimos y una clave SSH. No comparta una contraseña común entre varios empleados: en caso de despido o filtración, no será posible determinar con precisión el origen del acceso.

Conexión del almacenamiento S3

SFTPGo permite asignar a un usuario o a una carpeta virtual un backend de almacenamiento de objetos. Admite Amazon S3 y muchas API compatibles, incluidos los almacenamientos con endpoint propio. En el panel de creación del usuario, abra la configuración del sistema de archivos y seleccione el tipo de almacenamiento S3.

Complete los campos según el siguiente esquema:

Cree un usuario S3 independiente con acceso únicamente al bucket y al prefijo necesarios. El conjunto mínimo de permisos normalmente incluye la lectura, la carga y eliminación de objetos, y la consulta del contenido del bucket. Algunos proveedores también requieren acceso a multipart upload.

No publique directamente el bucket S3 en Internet si los archivos deben proporcionarse únicamente a través de SFTPGo. Desactive el acceso público, habilite el cifrado del almacenamiento y configure una política de lifecycle para las versiones antiguas o las cargas multipart incompletas.

Pruebas de SFTP

Cree un archivo de prueba y conéctese al servidor. En Linux o macOS puede utilizar el cliente integrado OpenSSH.

# Подключаемся к SFTPGo обычным паролем
sftp -P 2022 [email protected]

# После входа выполняются команды SFTP
pwd
ls
put test.txt
get test.txt
exit

Para conectarse mediante una clave, indique la clave privada del cliente:

# Подключение с SSH-ключом
sftp -i ~/.ssh/sftp_user_ed25519 -P 2022 [email protected]

Compruebe que el usuario no pueda salir del espacio virtual asignado, leer directorios ajenos ni ejecutar comandos de shell. SFTPGo no proporciona acceso a un shell normal, pero aun así debe comprobar los permisos finales con una cuenta de prueba independiente.

Supervisión de registros y healthcheck

# Просматриваем логи приложения в реальном времени
docker compose logs -f --tail=100 sftpgo

# Просматриваем ошибки reverse proxy
docker compose logs --tail=100 caddy

# Проверяем, не перезапускаются ли контейнеры
docker compose ps

# Смотрим использование диска и памяти
df -h
free -h
docker system df

Para la supervisión automatizada, añada comprobaciones de HTTPS, disponibilidad del puerto TCP 2022 y espacio libre en disco. El sistema externo de supervisión debe notificar si no se recibe una respuesta HTTP durante varios minutos o si el uso del disco supera el 80 por ciento.

Seguridad del panel

El panel de administración debe estar disponible únicamente mediante HTTPS. No publique el puerto 8080 en Internet: en Compose está vinculado a 127.0.0.1, por lo que solo está disponible en el propio servidor y desde la red de Docker.

Utilice MFA si la función está disponible en su versión y método de autenticación seleccionados. Restrinja por separado el acceso a la REST API, no almacene los tokens de API en Git y revóquelos una vez finalizada la integración. Los registros administrativos deben revisarse después de realizar cambios en los usuarios y permisos.

8. Copias de seguridad y mantenimiento

Qué es necesario guardar

El conjunto mínimo de la copia de seguridad consta de PostgreSQL, el archivo compose.yml, Caddyfile, el archivo de entorno o su copia cifrada, así como los Docker volumes de SFTPGo. Si los archivos se encuentran en el disco local, también es necesario copiar los datos de los usuarios. Con almacenamiento S3, los propios objetos ya se encuentran fuera del VPS, pero deben conservarse la configuración del bucket, los permisos, la política de lifecycle y el versionado.

Backup sencillo mediante restic

A continuación se utiliza restic y un repositorio S3-compatible externo. La copia de seguridad de la base de datos se crea primero mediante pg_dump y después el directorio del proyecto se archiva en restic. La contraseña de restic y las claves de S3 deben almacenarse en un archivo protegido independiente, inaccesible para otros usuarios.

# Устанавливаем restic
sudo apt install -y restic

# Создаём файл переменных резервного копирования
sudo install -m 600 /dev/null /root/.restic-env
sudoedit /root/.restic-env

export AWS_ACCESS_KEY_ID="backup-access-key"
export AWS_SECRET_ACCESS_KEY="backup-secret-key"
export RESTIC_REPOSITORY="s3:https://backup-s3.example.com/sftpgo-repo"
export RESTIC_PASSWORD="длинный-пароль-restic"

Cree el script. El comando docker compose exec realiza el dump dentro del contenedor de PostgreSQL y lo guarda en el directorio conectado del proyecto.

# Создаём каталог для временных дампов
sudo mkdir -p /var/backups/sftpgo
sudo chmod 700 /var/backups/sftpgo

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

cd /opt/sftpgo
source /root/.restic-env

STAMP="$(date +%F-%H%M%S)"
DUMP="/var/backups/sftpgo/postgres-${STAMP}.sql.gz"

docker compose exec -T postgres \
  pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" | gzip > "$DUMP"

restic backup \
  "$DUMP" \
  /opt/sftpgo/compose.yml \
  /opt/sftpgo/Caddyfile \
  /opt/sftpgo/.env

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

find /var/backups/sftpgo -type f -name '.sql.gz' -mtime +3 -delete
EOF

# Делаем скрипт исполняемым
sudo chmod 700 /usr/local/sbin/backup-sftpgo.sh

# Инициализируем restic repository один раз
sudo bash -c 'source /root/.restic-env && restic init'

# Выполняем тестовый backup
sudo /usr/local/sbin/backup-sftpgo.sh

# Открываем cron root
sudo crontab -e

30 02    /usr/local/sbin/backup-sftpgo.sh >> /var/log/backup-sftpgo.log 2>&1

Una vez al mes, realice una restauración de prueba en un directorio independiente o en un VPS de pruebas. Un backup cuya restauración nunca se ha comprobado no puede considerarse fiable.

Actualización de SFTPGo

Antes de actualizar, registre la etiqueta actual de la imagen y realice un backup completo. Para una instalación pequeña, utilice una ventana de mantenimiento: detenga los servicios, descargue la nueva imagen, inicie los contenedores y compruebe la funcionalidad.

# Переходим в каталог проекта
cd /opt/sftpgo

# Создаём резервную копию перед обновлением
sudo /usr/local/sbin/backup-sftpgo.sh

# Загружаем новую проверенную версию образов
docker compose pull

# Перезапускаем контейнеры без удаления volumes
docker compose up -d

# Проверяем состояние и последние ошибки
docker compose ps
docker compose logs --tail=100 sftpgo

No ejecute docker compose down -v: la opción -v elimina los volumes con nombre y puede destruir la base de datos y los datos locales. Actualice primero la copia de pruebas y después production. Para una instalación grande, utilice blue-green o un servidor standby independiente, pero las migraciones de la base de datos siguen requiriendo compatibilidad entre versiones.

Control de recursos

Supervise el uso del sistema de archivos, los inodos, la memoria y el tamaño de los logs de Docker. Limite la rotación de los registros de Docker; de lo contrario, el funcionamiento prolongado del servicio puede llenar el disco.

# Проверяем inode и свободное место
df -h
df -i

# Проверяем потребление контейнеров
docker stats --no-stream

# Ищем крупные каталоги
sudo du -xhd1 /var/lib/docker /opt /var/log 2>/dev/null | sort -h

9. Troubleshooting y FAQ

¿Por qué HTTPS muestra un error de certificado?

Compruebe que el nombre DNS apunta a la IP pública del servidor y que los puertos TCP 80 y 443 están permitidos en UFW y en el firewall externo. Consulte el registro con el comando docker compose logs caddy: allí aparecerá la causa del rechazo de ACME. Asegúrese de que otro servidor web no haya ocupado los puertos 80 o 443. Si se utiliza un proxy DNS, compruebe temporalmente la corrección de los registros A/AAAA y la disponibilidad del servidor origin.

El contenedor SFTPGo se reinicia. ¿Qué debo comprobar?

Comience con docker compose logs --tail=200 sftpgo y docker compose ps. Las causas frecuentes son un nombre incorrecto de la variable de PostgreSQL, una contraseña errónea en .env, un servicio de base de datos inaccesible o un volume dañado. Compruebe el estado de PostgreSQL mediante docker compose logs postgres. El comando docker compose config mostrará los valores finales y los errores de YAML, pero no muestre su resultado en logs públicos: puede contener secretos.

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

Para realizar pruebas, son suficientes 1 vCPU, 2 GB de RAM y 20–30 GB de SSD. Para el funcionamiento permanente de un equipo pequeño, es mejor utilizar 2 vCPU, 4 GB de RAM y 40–60 GB de NVMe. Si los archivos se almacenan en S3, el disco no tiene que ser igual al tamaño del archivo, pero se necesita espacio adicional para la base de datos, los logs, los archivos temporales y las copias de seguridad. Con almacenamiento local, añada el volumen de los datos de los usuarios y al menos un 25 por ciento de espacio libre.

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

En la mayoría de los casos, un VPS es suficiente: SFTPGo y PostgreSQL consumen una cantidad moderada de CPU, y los datos pueden trasladarse a S3. Se necesita un dedicated cuando hay un gran archivo local, una carga elevada y constante sobre los discos, un gran número de transferencias simultáneas o requisitos de aislamiento físico. Antes de migrar, mida los recursos mediante la monitorización. A menudo es más barato ampliar el disco o S3 que alquilar directamente un servidor dedicado.

El puerto 2022 está abierto, pero SFTP no se conecta

Compruebe que el contenedor está publicado con la regla 2022:2022 y que SFTPGo realmente escucha en este puerto: docker compose logs sftpgo y sudo ss -lntp | grep 2022. Después, compruebe UFW y el firewall externo. En el cliente debe seleccionarse específicamente el protocolo SFTP, no FTP ni FTPS. Compruebe también el inicio de sesión, el estado del usuario, la fecha de expiración de la cuenta y la lista de IP permitidas.

El usuario inicia sesión, pero no ve los archivos en S3

Primero compruebe el bucket, la región y el endpoint. Para un endpoint S3 compatible, normalmente es necesario indicar la URL completa con HTTPS. Compruebe los permisos de la clave: se necesitan como mínimo operaciones de visualización, lectura y carga, y para eliminar, un permiso delete independiente. Asegúrese de que el prefix no contiene espacios adicionales ni una barra inicial. Consulte el registro de SFTPGo durante la operación: los errores del AWS SDK suelen indicar una región o firma incorrecta, un ACL incorrecto o la falta de permisos.

Después de reiniciar desaparecieron los usuarios y la configuración

Compruebe que PostgreSQL y SFTPGo utilizan los volumes con nombre indicados en Compose. No inicie el proyecto desde otro directorio con otro archivo Compose ni ejecute docker compose down -v. Los comandos docker volume ls y docker volume inspect mostrarán los volúmenes existentes. Si la base de datos se eliminó, restáurela desde pg_dump y solo después inicie SFTPGo.

¿Cómo limitar el acceso al panel administrativo?

Deje el puerto HTTP de SFTPGo vinculado a 127.0.0.1, como en el ejemplo, y publique la interfaz únicamente mediante Caddy. Además, puede limitar el acceso al dominio mediante una VPN, un reverse proxy o un firewall de red. Utilice cuentas de administrador independientes, MFA y tokens de API de corta duración. No coloque el panel en un puerto público directo sin TLS.

¿Se pueden almacenar los archivos únicamente en el VPS?

Sí. Cree un usuario con un sistema de archivos local e indique el directorio principal dentro del volumen sftpgo_home o de un bind mount independiente. Esta opción es más sencilla y rápida en una red local, pero requiere controlar el disco y disponer de una copia independiente de los datos. No considere un Docker volume como una copia de seguridad: un fallo del disco o la eliminación del VPS lo destruirá junto con el contenedor. Para production, utilice un backup externo o replicación.

10. Conclusiones y próximos pasos

Como resultado, hemos obtenido SFTPGo en un VPS con PostgreSQL, HTTPS mediante Caddy, un puerto SFTP independiente, gestión de usuarios y la posibilidad de almacenar archivos en S3. El sistema separa los metadatos de la aplicación de los archivos y permite escalar el almacenamiento independientemente de los recursos informáticos.

El siguiente paso práctico es activar MFA, configurar la monitorización externa y probar periódicamente la restauración desde un backup. A medida que aumente la carga, mida la CPU, la memoria, el tráfico de red y las latencias de S3; después elija entre ampliar el VPS, utilizar un servidor de almacenamiento independiente o contratar un dedicated.

• Cree grupos de usuarios independientes con permisos y cuotas mínimos.
• Active el versionado y la política de lifecycle en S3 para protegerse contra eliminaciones accidentales.
• Documente el procedimiento de restauración en un servidor limpio y compruébelo después de cada actualización importante.