Встановлення SFTPGo на VPS: захищений SFTP-сервер, вебпанель і S3-сховище

1. TL;DR

SFTPGo підходить, коли потрібні власний файловий портал і SFTP-сервер без прив’язки до SaaS-провайдера. Сервіс надає веб-інтерфейс для адміністраторів і користувачів, підтримує SFTP, HTTP/S, WebDAV, FTP/S, квоти та підключення S3-сумісних сховищ.

Для невеликої команди достатньо VPS із 2 vCPU, 4 ГБ RAM і SSD-диском від 40 ГБ. Якщо самі файли зберігатимуться в S3, локальний диск потрібен переважно для контейнерів, бази даних, журналів і тимчасових операцій. Якщо використовується локальна файлова система, обсяг диска має відповідати обсягу даних із запасом щонайменше 25–30 відсотків.

• Адміністративний інтерфейс не публікується на випадковому порту: назовні він доступний лише через Caddy і HTTPS.
• SFTP працює на окремому TCP-порту, наприклад 2022.
• Дані SFTPGo і PostgreSQL зберігаються в постійних Docker volumes.
• Паролі та ключі доступу до бази не записуються в конфігурацію веб-сервера.
• Резервна копія включає базу, конфігурацію, Docker Compose і дані користувачів.

2. Зміст

Стаття розрахована на власника VPS, який хоче самостійно розгорнути SFTPGo і контролювати доступ до файлів. Команди наведено для Ubuntu Server 24.04 LTS із користувачем, який має права sudo.

1. Спочатку визначимо архітектуру: SFTPGo, PostgreSQL, Caddy і зовнішній S3.
2. Потім підготуємо сервер: оновимо ОС, створимо окремого користувача, налаштуємо SSH, UFW і Fail2ban.
3. Після цього запустимо контейнери та перевіримо журнали, порти й HTTP-відповіді.
4. У веб-панелі створимо адміністратора, звичайного користувача та підключимо S3-бакет.
5. Наприкінці налаштуємо резервне копіювання та процедуру оновлення.

3. Що ми налаштовуємо і навіщо

Що таке SFTPGo

SFTPGo — серверна система для безпечного обміну файлами. Основний протокол у цьому посібнику — SFTP поверх SSH. На відміну від звичайного системного користувача Linux, користувач SFTPGo керується з програми: йому можна призначити квоту, домашню директорію, віртуальні папки, дозволи на завантаження та скачування, термін дії облікового запису й обмеження за IP.

У SFTPGo є окрема адміністративна веб-панель. Через неї створюються користувачі, групи, політики зберігання, SSH-ключі й токени. Користувацький веб-інтерфейс дає змогу обмінюватися файлами через браузер, тому для звичайного завантаження документів не обов’язково встановлювати SFTP-клієнт.

Цільова схема

Що буде в результаті

Після виконання інструкції SFTPGo буде доступний за адресою на кшталт https://files.example.com. Користувач зможе увійти до веб-панелі або підключитися з WinSCP, Cyberduck, FileZilla, командного рядка Linux та інших клієнтів.

Адміністративна база зберігатиметься в PostgreSQL, а файли можна розмістити в S3. Це розділяє програму й дані: заміну VPS або контейнера не потрібно поєднувати з міграцією великого файлового масиву. Однак база та налаштування все одно потребують резервного копіювання.

Self-hosted чи хмарний сервіс

Хмарними сервісами обміну файлами простіше почати користуватися: не потрібно оновлювати ОС, стежити за TLS і налаштовувати резервні копії. За це доводиться платити регулярною абонентською платою, приймати обмеження тарифів і передавати дані зовнішньому оператору.

Self-hosted-варіант на VPS виправданий, якщо потрібен контроль над місцезнаходженням даних, власна політика доступу, інтеграція із S3, LDAP або внутрішніми системами. Власник сервера відповідає за оновлення та резервні копії, зате може самостійно обирати протоколи, ліміти й схему зберігання.

Коли SFTPGo не найкращий вибір

Якщо потрібно лише одноразово передати кілька файлів, повноцінний сервіс буде надмірним. Для синхронізації робочих каталогів між ноутбуками можуть краще підійти Nextcloud, Syncthing або спеціалізовані backup-інструменти. SFTPGo особливо корисний там, де потрібні саме керовані облікові записи, SFTP-сумісність, обмеження прав і доступ до об’єктного сховища.

4. Яка конфігурація VPS потрібна для цього завдання

Мінімальна конфігурація

Для одного адміністратора та кількох користувачів SFTPGo не потребує великої кількості CPU. Основне навантаження залежить від кількості одночасних з’єднань, TLS-термінації, швидкості сховища та розміру файлів. Для тестового встановлення достатньо 1 vCPU і 2 ГБ RAM, але для постійної експлуатації краще починати з 2 vCPU і 4 ГБ RAM.

Якщо файли зберігаються в S3, не потрібно купувати диск розміром із весь архів. Але запас дискового простору все одно потрібен для PostgreSQL, журналів Docker, тимчасових файлів, резервних копій та оновлень. Практичний базовий варіант — 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe SSD і публічний IPv4. Для такої конфігурації можна взяти відповідний VPS із Linux і повним root-доступом.

Вимоги до мережі

Потрібна вхідна IPv4-адреса, а бажано також IPv6. DNS-ім’я files.example.com має вказувати на адресу сервера. Для автоматичного отримання TLS-сертифіката Caddy потрібні відкриті TCP-порти 80 і 443. Для SFTP використовуватиметься окремий порт, наприклад 2022.

Перевірте обмеження провайдера на вихідні з’єднання до S3. Деякі мережі блокують окремі діапазони або обмежують кількість з’єднань. Під час роботи з великими файлами важлива не лише швидкість порту, а й стабільність маршруту до регіону S3.

Коли потрібен dedicated

Виділений сервер виправданий, якщо обсяг локального сховища перевищує кілька терабайтів, потрібні кілька швидких NVMe-дисків, десятки або сотні одночасних завантажень чи жорстка ізоляція від сусідніх віртуальних машин. Для SFTPGo, який використовує зовнішній S3, перехід на dedicated зазвичай не є першим кроком масштабування.

Спочатку слід виміряти CPU, RAM, I/O і мережеву пропускну здатність. Якщо вузьким місцем стає лише сховище, вигідніше винести дані в S3 або підключити окремий storage-сервер. Dedicated має сенс, коли потрібна передбачувана продуктивність усіх ресурсів одночасно.

Вибір локації

Розміщуйте VPS ближче до основних користувачів і регіону S3. Це зменшує затримку під час роботи з веб-панеллю та передавання через SFTP. Якщо дані регулюються вимогами законодавства або політикою компанії, регіон сервера й об’єктного сховища має відповідати цим вимогам.

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

Оновлення системи та ім’я хоста

Далі передбачається чиста Ubuntu Server 24.04 LTS. Підключіться під тимчасовим користувачем із sudo або під root, установіть ім’я хоста й оновіть пакети.

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

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

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

Після перезавантаження знову підключіться через SSH. Створіть окремого користувача для адміністрування. Використовуйте власне ім’я замість deploy.

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

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

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

SSH-ключі

На локальному комп’ютері згенеруйте ключ Ed25519, якщо його ще немає. Не передавайте приватний ключ на сервер і не зберігайте його в Docker-проєкті.

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

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

Перевірте вхід у новій сесії, не закриваючи поточну root-сесію. Лише після успішної перевірки можна вимикати вхід за паролем.

# Открываем конфигурацию 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

Перед увімкненням UFW дозвольте SSH-порт. У прикладі SSH працює на стандартному порту 22. Якщо ви змінили його, підставте власне значення.

# Устанавливаем 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 і базові утиліти

Fail2ban аналізує журнали невдалих входів і тимчасово блокує IP-адреси. Він не замінює SSH-ключі, MFA та firewall, але зменшує кількість автоматичного перебору.

# Устанавливаем защиту 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

Якщо SSH працює на іншому порту, змініть параметр port у jail і правило UFW. Не використовуйте зміну порту як єдиний метод захисту: ключі, заборона root і обмеження спроб важливіші.

6. Установлення ПЗ — покроково

Крок 1. Установлення Docker з офіційного репозиторію

Для відтворюваного розгортання використовуємо Docker Engine і Compose Plugin з офіційного apt-репозиторію Docker. На момент підготовки інструкції для продакшена використовуйте актуальний стабільний Docker Engine 27.x або новіший сумісний випуск, доступний у репозиторії.

# Удаляем конфликтующие старые пакеты
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

Крок 2. Доступ користувача deploy до Docker

Додавання користувача до групи docker дає змогу запускати Docker без sudo, але фактично надає права рівня root. Робіть це лише для довіреного адміністратора.

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

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

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

Крок 3. Створення структури проєкту

Створимо окремий каталог. Файл .env міститиме секрети й залишатиметься лише на сервері.

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

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

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

Крок 4. Секрети оточення

Згенеруйте довгі випадкові паролі. Пароль PostgreSQL не має збігатися з паролем адміністратора SFTPGo. Змінна SFTPGO_DEFAULT_ADMIN_PASSWORD використовується лише під час первинної ініціалізації, тому збережіть її в менеджері паролів.

# Генерируем случайные значения
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

Крок 5. Docker Compose

Нижче використовується PostgreSQL 16 й офіційний образ SFTPGo. Тег v2.6.x слід замінити на конкретний останній стабільний patch-реліз 2.6, перевірений перед установленням. Не використовуйте постійно плаваючий тег latest у критичній системі без тестування.

# Создаём 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

У Compose використовуються два постійні томи SFTPGo. Перший зберігає конфігурацію та внутрішні дані застосунку, другий призначений для локального домашнього каталогу користувачів. Навіть якщо основним backend буде S3, ці томи не можна видаляти без резервної копії.

Крок 6. Запуск бази та SFTPGo

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

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

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

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

Під час першого запуску SFTPGo створює таблиці PostgreSQL і користувача адміністратора. Якщо контейнер перезапускається, спочатку перевірте журнал бази: найчастіша причина — неправильні змінні підключення, пошкоджений volume або запуск застосунку до готовності PostgreSQL.

Крок 7. Установлення Caddy

Caddy працюватиме в окремому контейнері та проксуватиме веб-інтерфейс SFTPGo. SFTP-з’єднання через Caddy не проходять: порт 2022 безпосередньо публікується контейнером 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

Замініть files.example.com на власне DNS-ім’я до запуску Caddy. Якщо DNS ще не оновився, контейнер працюватиме, але не зможе отримати автоматичний сертифікат.

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

Перевірка DNS, HTTPS і SFTP

Спочатку переконайтеся, що домен резолвиться на правильну адресу. Перевірку виконуйте з локального комп’ютера або іншої машини в інтернеті.

# Проверяем 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

Очікувана відповідь HTTPS — 200, 302 або інша відповідь застосунку без помилки TLS. Команда nc має показати успішне TCP-з’єднання. Якщо порт доступний локально, але не ззовні, перевірте UFW і правила мережевого екрана в панелі VPS.

Перший вхід до панелі

Відкрийте https://files.example.com і увійдіть із логіном і паролем із файлу .env. Одразу змініть початковий пароль в інтерфейсі та збережіть його в менеджері паролів. Не використовуйте обліковий запис адміністратора для щоденної передачі файлів.

У панелі перевірте розділи налаштувань HTTP, SFTP, користувачів, груп і журналів. Якщо в майбутньому зміните порт або binding через вебінтерфейс, враховуйте, що змінні середовища Compose застосовуються під час створення контейнера й можуть бути перевизначені налаштуваннями застосунку.

Створення користувача для SFTP

1. Відкрийте розділ користувачів і створіть новий обліковий запис.
2. Задайте унікальне ім’я та довгий пароль або додайте SSH public key.
3. Укажіть домашній каталог або віртуальну папку.
4. Обмежте права: зазвичай достатньо list, download і upload.
5. Задайте квоту дискового простору та кількість файлів.
6. За потреби обмежте дозволені IP-адреси.
7. Збережіть користувача та виконайте тестове підключення.

Для сервісних інтеграцій краще використовувати окремого користувача з мінімальними правами та SSH-ключем. Не передавайте спільний пароль кільком співробітникам: у разі звільнення або витоку неможливо буде точно визначити джерело доступу.

Підключення S3-сховища

SFTPGo дозволяє призначати користувачу або віртуальній папці backend об’єктного сховища. Підтримуються Amazon S3 і багато сумісних API, зокрема сховища з власним endpoint. У панелі створення користувача відкрийте налаштування файлової системи та виберіть тип сховища S3.

Заповніть поля за такою схемою:

Створіть окремого S3-користувача з доступом лише до потрібного бакета та префікса. Мінімальний набір дозволів зазвичай включає читання, завантаження, видалення об’єктів і перегляд вмісту бакета. Для деяких провайдерів додатково потрібен доступ до multipart upload.

Не публікуйте S3-бакет безпосередньо в інтернеті, якщо файли мають видаватися лише через SFTPGo. Вимкніть публічний доступ, увімкніть шифрування на стороні сховища та налаштуйте lifecycle-політику для старих версій або незавершених multipart-завантажень.

Тестування SFTP

Створіть тестовий файл і підключіться до сервера. У Linux або macOS можна використовувати вбудований клієнт OpenSSH.

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

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

Для підключення за ключем укажіть приватний ключ клієнта:

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

Перевірте, що користувач не може вийти за межі призначеного віртуального простору, читати чужі каталоги або виконувати команди оболонки. SFTPGo не надає звичайний shell-доступ, але підсумкові права все одно слід перевіряти окремим тестовим обліковим записом.

Моніторинг логів і 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

Для автоматичного моніторингу додайте перевірку HTTPS, доступності TCP-порту 2022 і вільного місця на диску. Зовнішня система моніторингу має повідомляти, якщо HTTP-відповідь не надходить кілька хвилин або заповнення диска перевищує 80 відсотків.

Безпека панелі

Панель адміністратора має бути доступна лише через HTTPS. Не публікуйте порт 8080 в інтернеті: у Compose він прив’язаний до 127.0.0.1, тому доступний лише на самому сервері та з мережі Docker.

Використовуйте MFA, якщо функція доступна у вашій версії та вибраному способі автентифікації. Окремо обмежте доступ до REST API, не зберігайте API-токени в Git і відкликайте їх після завершення інтеграції. Адміністративні журнали слід переглядати після змін користувачів і прав.

8. Резервні копії та обслуговування

Що необхідно зберігати

Мінімальний комплект резервної копії складається з PostgreSQL, файлу compose.yml, Caddyfile, файлу середовища або його зашифрованої копії, а також Docker volumes SFTPGo. Якщо файли знаходяться на локальному диску, потрібно копіювати й користувацькі дані. У разі S3-сховища самі об’єкти вже знаходяться за межами VPS, але слід зберігати конфігурацію bucket, права, lifecycle-політику та версіювання.

Простий backup через restic

Нижче використовується restic і зовнішній S3-compatible репозиторій. Резервна копія бази спочатку створюється через pg_dump, потім каталог проєкту архівується в restic. Пароль restic і ключі S3 мають зберігатися в окремому захищеному файлі, недоступному іншим користувачам.

# Устанавливаем 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"

Створіть скрипт. Команда docker compose exec виконує дамп усередині контейнера PostgreSQL і зберігає його в підключений каталог проєкту.

# Создаём каталог для временных дампов
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

Раз на місяць виконуйте пробне відновлення в окремий каталог або на тестовий VPS. Backup, який ніколи не перевіряли відновленням, не можна вважати надійним.

Оновлення SFTPGo

Перед оновленням зафіксуйте поточний тег образу та виконайте повний backup. Для невеликої інсталяції використовуйте вікно обслуговування: зупиніть сервіси, завантажте новий образ, запустіть контейнери та перевірте функціональність.

# Переходим в каталог проекта
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

Не виконуйте docker compose down -v: ключ -v видаляє іменовані volumes і може знищити базу та локальні дані. Спочатку оновлюйте тестову копію, потім production. Для великої інсталяції використовуйте blue-green або окремий standby-сервер, але міграції бази все одно потребують сумісності версій.

Контроль ресурсів

Стежте за заповненням файлової системи, inode, пам’яттю та розміром Docker-логів. Обмежте ротацію журналів Docker, інакше тривала робота сервісу може заповнити диск.

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

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

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

9. Усунення несправностей і FAQ

Чому HTTPS показує помилку сертифіката?

Перевірте, що DNS-ім'я вказує на публічний IP сервера, а TCP-порти 80 і 443 дозволені в UFW і зовнішньому firewall. Перегляньте журнал командою docker compose logs caddy: там буде причина відмови ACME. Переконайтеся, що інший вебсервер не зайняв порти 80 або 443. Якщо використовується проксі DNS, тимчасово перевірте коректність A/AAAA-записів і доступність origin-сервера.

Контейнер SFTPGo перезапускається. Що перевірити?

Почніть із docker compose logs --tail=200 sftpgo і docker compose ps. Часті причини — неправильна назва змінної PostgreSQL, неправильний пароль у .env, недоступний сервіс бази або пошкоджений volume. Перевірте стан PostgreSQL через docker compose logs postgres. Команда docker compose config покаже підсумкові значення та помилки YAML, але не виводьте її результат у публічні логи: там можуть бути секрети.

Яка VPS-конфігурація мінімально підійде?

Для тестування підійдуть 1 vCPU, 2 ГБ RAM і 20–30 ГБ SSD. Для постійної роботи невеликої команди краще використовувати 2 vCPU, 4 ГБ RAM і 40–60 ГБ NVMe. Якщо файли зберігаються в S3, диск не зобов'язаний дорівнювати розміру архіву, але потрібен запас для бази, логів, тимчасових файлів і резервних копій. За локального зберігання додайте обсяг користувацьких даних і щонайменше 25 відсотків вільного простору.

Що вибрати — VPS чи dedicated для цього завдання?

У більшості випадків достатньо VPS: SFTPGo і PostgreSQL помірно споживають CPU, а дані можна винести в S3. Dedicated потрібен за великого локального файлового архіву, високого постійного навантаження на диски, великої кількості паралельних передавань або вимог до фізичної ізоляції. Перед переходом виміряйте ресурси через моніторинг. Часто дешевше масштабувати диск або S3, ніж одразу орендувати виділений сервер.

Порт 2022 відкритий, але SFTP не підключається

Перевірте, що контейнер опублікований із правилом 2022:2022, а SFTPGo дійсно слухає цей порт: docker compose logs sftpgo і sudo ss -lntp | grep 2022. Потім перевірте UFW і зовнішній firewall. У клієнті має бути вибраний саме протокол SFTP, а не FTP або FTPS. Також перевірте логін, статус користувача, термін дії акаунта та дозволений список IP.

Користувач входить, але не бачить файли в S3

Спочатку перевірте bucket, регіон і endpoint. Для сумісного S3 endpoint зазвичай потрібно вказувати повний URL з HTTPS. Перевірте права ключа: потрібні щонайменше операції перегляду, читання та завантаження, а для видалення — окремий дозвіл delete. Переконайтеся, що prefix не містить зайвих пробілів або початкового слеша. Перегляньте журнал SFTPGo у момент операції: помилки AWS SDK зазвичай вказують на неправильний регіон, підпис, ACL або відсутність права.

Після перезапуску зникли користувачі та налаштування

Перевірте, що PostgreSQL і SFTPGo використовують іменовані volumes, зазначені в Compose. Не запускайте проєкт з іншого каталогу з іншим файлом Compose і не виконуйте docker compose down -v. Команди docker volume ls і docker volume inspect покажуть наявні томи. Якщо базу було видалено, відновіть її з pg_dump і лише після цього запускайте SFTPGo.

Як обмежити доступ до адміністративної панелі?

Залиште HTTP-порт SFTPGo прив'язаним до 127.0.0.1, як у прикладі, і публікуйте інтерфейс лише через Caddy. Додатково можна обмежити доступ до домену на рівні VPN, reverse proxy або мережевого firewall. Використовуйте окремі облікові записи адміністраторів, MFA і короткоживучі API-токени. Не розміщуйте панель на прямому публічному порту без TLS.

Чи можна зберігати файли лише на VPS?

Так. Створіть користувача з локальною файловою системою та вкажіть домашній каталог усередині тому sftpgo_home або окремого bind mount. Такий варіант простіший і швидший у локальній мережі, але потребує контролю диска й окремої копії даних. Не вважайте Docker volume резервною копією: відмова диска або видалення VPS знищить його разом із контейнером. Для production використовуйте зовнішній backup або реплікацію.

10. Висновки та наступні кроки

У результаті ми отримали SFTPGo на VPS з PostgreSQL, HTTPS через Caddy, окремим SFTP-портом, керуванням користувачами та можливістю зберігати файли в S3. Система відокремлює метадані застосунку від файлів і дає змогу масштабувати сховище незалежно від обчислювальних ресурсів.

Наступний практичний крок — увімкнути MFA, налаштувати зовнішній моніторинг і регулярно тестувати відновлення з backup. У разі зростання навантаження вимірюйте CPU, пам'ять, мережевий трафік і затримки S3, а потім обирайте між збільшенням VPS, окремим storage-сервером і виділеним dedicated.

• Створіть окремі групи користувачів із мінімальними правами та квотами.
• Увімкніть версіонування та lifecycle-політику в S3 для захисту від випадкового видалення.
• Документуйте процедуру відновлення на чистому сервері та перевіряйте її після кожного великого оновлення.