Встановлення Vikunja на VPS: self-hosted менеджер завдань із Docker, SSL і резервними копіями

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

Vikunja — відкритий менеджер завдань і проєктів із вебінтерфейсом, списками завдань, kanban-дошками, мітками, термінами, повторюваними завданнями, вкладеннями, спільним доступом і API. Він підходить для особистого планування, невеликої розробки, внутрішніх процесів компанії та роботи команди без передавання робочих даних сторонньому SaaS-сервісу.

У цій інструкції Vikunja працюватиме на Ubuntu Server 24.04 LTS. Архітектура складається з чотирьох контейнерів: API Vikunja, вебфронтенд, PostgreSQL 17 і Caddy 2.10. Caddy приймає з'єднання з інтернету, автоматично отримує TLS-сертифікат Let’s Encrypt і проксіює запити до Vikunja.

Після завершення налаштування сервіс відкриватиметься за адресою на кшталт https://tasks.example.com. Користувачі зможуть самостійно реєструватися, якщо цю функцію ввімкнено, або адміністратор зможе створити перший обліковий запис і вимкнути публічну реєстрацію.

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

• Vikunja у Docker Compose без встановлення залежностей застосунку в систему.
• PostgreSQL з окремим користувачем і постійним Docker volume.
• Домен із HTTPS та автоматичним продовженням сертифіката.
• Закриті внутрішні порти: PostgreSQL і API недоступні з інтернету.
• Файл із секретами, виключений із Git і резервних копій без шифрування.
• Щоденний зашифрований або віддалений бекап бази даних і конфігурації.

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

Self-hosted варіант потребує дисципліни: потрібно стежити за оновленнями, перевіряти резервні копії та захищати SSH-доступ. Натомість ви отримуєте незалежність від тарифів, лімітів користувачів і раптової зміни умов хмарного продукту.

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

Vikunja сама по собі споживає небагато ресурсів. Основну пам'ять займає PostgreSQL, а дисковий простір витрачається на базу даних, прикріплені файли, Docker-образи, журнали та резервні копії. Для старту не потрібен потужний сервер, але надто малий VPS створить проблеми під час оновлення образів і створення дампів бази.

Практичний стартовий варіант — 2 vCPU, 2 ГБ RAM, 40 ГБ NVMe та публічна IPv4-адреса. Такої конфігурації вистачає для Vikunja, PostgreSQL, Caddy, щоденного бекапу та кількох десятків активних користувачів. Наприклад, можна взяти VPS із зазначеними характеристиками або аналогічний сервер в іншого провайдера.

Коли знадобиться більше пам'яті

Збільшуйте RAM до 4–8 ГБ, якщо на тому самому хості працюють Git-сервер, Mattermost, моніторинг, CI-раннери або інші контейнери. PostgreSQL може використовувати файловий кеш Linux, тому додаткова пам'ять зазвичай дає помітніший ефект, ніж додаткова кількість vCPU.

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

Для звичайної Vikunja dedicated-сервер не потрібен. Він стає виправданим, якщо ви зберігаєте сотні гігабайтів вкладень, обслуговуєте сотні активних користувачів, запускаєте кілька важких сервісів на одному хості або вам потрібні гарантовані IOPS і виділені CPU. У більшості випадків простіше почати з VPS і збільшити тариф без міграції застосунку.

Як вибрати локацію

Вибирайте дата-центр ближче до основної команди: це зменшить затримку під час відкриття інтерфейсу та завантаження вкладень. Якщо важливі вимоги до обробки персональних даних, враховуйте країну розміщення, договір із провайдером і місце зберігання резервних копій. Бекап краще тримати в іншому дата-центрі або в іншого провайдера: один збій не повинен знищити і робочі дані, і їхню копію.

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

Нижче передбачається чистий сервер з Ubuntu Server 24.04 LTS і доступом під користувачем root. Перед встановленням створіть DNS-запис типу A, що вказує на IPv4-адресу сервера. У прикладах використовується домен tasks.example.com; замініть його на свій.

Оновіть систему

Спочатку встановіть актуальні оновлення безпеки та базові утиліти.

apt update && apt upgrade -y
apt install -y curl ca-certificates gnupg ufw fail2ban unattended-upgrades nano

Перезавантажте сервер, якщо оновилося ядро або системні бібліотеки.

reboot

Створіть окремого користувача

Не виконуйте щоденне адміністрування від root. Створіть користувача deploy, додайте його до групи sudo та налаштуйте вхід за SSH-ключем.

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

До файлу authorized_keys вставте ваш публічний SSH-ключ, наприклад вміст ~/.ssh/id_ed25519.pub на локальному комп'ютері. Перевірте підключення в другому вікні термінала, не закриваючи поточну root-сесію.

ssh deploy@SERVER_IP

Вимкніть парольний вхід через SSH

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

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

Перевірте синтаксис і перезапустіть SSH-службу.

sudo sshd -t && sudo systemctl restart ssh

Налаштуйте firewall

Відкритими мають залишитися лише SSH, HTTP і HTTPS. Не відкривайте назовні порти PostgreSQL 5432, Vikunja API 3456 і фронтенду 80 всередині Docker.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Увімкніть Fail2ban і автоматичні security-оновлення

Fail2ban тимчасово блокує IP-адреси після підозрілих спроб входу через SSH. Автоматичні оновлення закривають відомі вразливості Ubuntu без ручного втручання.

sudo systemctl enable --now fail2ban
sudo dpkg-reconfigure -plow unattended-upgrades
sudo fail2ban-client status sshd

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

Встановлення ПЗ — покроково

Для розгортання використовується Docker Engine 28.x або новіший стабільний реліз і Docker Compose plugin. Образи Vikunja краще закріплювати на конкретному тегу, а не використовувати latest: так оновлення не відбудеться випадково під час чергового запуску.

Встановіть Docker з офіційного репозиторію

Видаліть потенційно конфліктні пакети, якщо вони були встановлені зі стандартного репозиторію Ubuntu.

sudo apt remove -y docker.io docker-compose docker-compose-v2 podman-docker containerd runc || true

Додайте ключ і репозиторій 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
sudo chmod a+r /etc/apt/keyrings/docker.gpg

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
sudo apt update

Встановіть Docker Engine, CLI, Buildx і Compose plugin.

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker --version
sudo docker compose version

Додайте користувача deploy до групи Docker. Після команди вийдіть із SSH-сеансу та увійдіть знову, щоб група застосувалася.

sudo usermod -aG docker deploy
exit

Підключіться повторно та переконайтеся, що Docker доступний без sudo.

ssh deploy@SERVER_IP
docker ps

Створіть робочу структуру

Усі файли сервісу зберігатимуться в /opt/vikunja. Каталог доступний користувачеві deploy, але не відкритий іншим локальним користувачам.

sudo mkdir -p /opt/vikunja/{caddy,data,backups,scripts}
sudo chown -R deploy:deploy /opt/vikunja
chmod 750 /opt/vikunja
cd /opt/vikunja

Перевірте доступність домену

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

getent ahostsv4 tasks.example.com

Якщо відображається не IP вашого VPS, виправте DNS і дочекайтеся поширення запису. Для випуску сертифіката Let’s Encrypt також мають бути доступні вхідні порти 80 і 443.

Конфігурація Vikunja, Docker і SSL

Нижче використовується версія Vikunja 0.24.6 як приклад закріпленого стабільного тегу. Перед production-розгортанням перевірте актуальний стабільний реліз в офіційних release notes Vikunja та за потреби замініть значення змінної. Не використовуйте неперевірений тег лише тому, що він новіший: спочатку зробіть бекап і протестуйте оновлення.

Створіть файл зі змінними середовища

Згенеруйте два випадкові секрети: пароль PostgreSQL і JWT-secret Vikunja. Пароль не повинен містити пробіли та символи, які можуть бути неправильно інтерпретовані shell.

cd /opt/vikunja
openssl rand -base64 32
openssl rand -hex 32

Створіть файл .env і підставте свої значення. Значення VIKUNJA_SERVICE_PUBLICURL обов’язково має закінчуватися на слеш.

nano /opt/vikunja/.env
chmod 600 /opt/vikunja/.env

VIKUNJA_VERSION=0.24.6
POSTGRES_DB=vikunja
POSTGRES_USER=vikunja
POSTGRES_PASSWORD=CHANGE_TO_LONG_RANDOM_DATABASE_PASSWORD
VIKUNJA_SERVICE_JWTSECRET=CHANGE_TO_LONG_RANDOM_JWT_SECRET
VIKUNJA_SERVICE_PUBLICURL=https://tasks.example.com/
VIKUNJA_SERVICE_ENABLEREGISTRATION=true
VIKUNJA_SERVICE_TIMEZONE=Europe/Moscow
VIKUNJA_SERVICE_MAXIMUMATTACHMENTSIZE=20971520
DOMAIN=tasks.example.com

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

Створіть Docker Compose файл

Файл Compose створює ізольовану мережу. З інтернету опубліковані лише порти Caddy, а PostgreSQL, API та фронтенд доступні лише контейнерам усередині мережі.

nano /opt/vikunja/compose.yaml

services:
  db:
    image: postgres:17-alpine
    container_name: vikunja-db
    restart: unless-stopped
    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: 10
    networks:
      - vikunja

  api:
    image: vikunja/api:${VIKUNJA_VERSION}
    container_name: vikunja-api
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      VIKUNJA_DATABASE_TYPE: postgres
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_USER: ${POSTGRES_USER}
      VIKUNJA_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
      VIKUNJA_DATABASE_DATABASE: ${POSTGRES_DB}
      VIKUNJA_DATABASE_SSLMODE: disable
      VIKUNJA_SERVICE_JWTSECRET: ${VIKUNJA_SERVICE_JWTSECRET}
      VIKUNJA_SERVICE_PUBLICURL: ${VIKUNJA_SERVICE_PUBLICURL}
      VIKUNJA_SERVICE_ENABLEREGISTRATION: ${VIKUNJA_SERVICE_ENABLEREGISTRATION}
      VIKUNJA_SERVICE_TIMEZONE: ${VIKUNJA_SERVICE_TIMEZONE}
      VIKUNJA_SERVICE_MAXIMUMATTACHMENTSIZE: ${VIKUNJA_SERVICE_MAXIMUMATTACHMENTSIZE}
    volumes:
      - vikunja_files:/app/vikunja/files
    networks:
      - vikunja

  frontend:
    image: vikunja/frontend:${VIKUNJA_VERSION}
    container_name: vikunja-frontend
    restart: unless-stopped
    depends_on:
      - api
    networks:
      - vikunja

  caddy:
    image: caddy:2.10-alpine
    container_name: vikunja-caddy
    restart: unless-stopped
    depends_on:
      - frontend
      - api
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    environment:
      DOMAIN: ${DOMAIN}
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - vikunja

networks:
  vikunja:
    name: vikunja-network

volumes:
  postgres_data:
  vikunja_files:
  caddy_data:
  caddy_config:

Налаштуйте Caddy

Caddy автоматично запитає сертифікат Let’s Encrypt, продовжуватиме його та перенаправить HTTP-трафік на HTTPS. Фронтенд отримує звичайні запити, а API-запити з префіксом /api/ спрямовуються до контейнера Vikunja API.

nano /opt/vikunja/caddy/Caddyfile

{$DOMAIN} {
    encode zstd gzip

    @api path /api/
    reverse_proxy @api api:3456

    reverse_proxy frontend:80

    header {
        -Server
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    log {
        output stdout
        format console
    }
}

cd /opt/vikunja
docker compose config --quiet

cd /opt/vikunja
docker compose pull
docker compose up -d
docker compose ps

docker compose logs --tail=100 api
docker compose logs --tail=100 caddy

curl -I https://tasks.example.com
curl -fsS https://tasks.example.com/api/v1/info

sed -i 's/VIKUNJA_SERVICE_ENABLEREGISTRATION=true/VIKUNJA_SERVICE_ENABLEREGISTRATION=false/' /opt/vikunja/.env
cd /opt/vikunja
docker compose up -d --force-recreate api

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

Docker volume не є резервною копією. Він зберігається на тому самому диску, що й запущений сервіс, тому не захищає від видалення VPS, помилки адміністратора, збою файлової системи або компрометації сервера. Надійна резервна копія має бути окремою, регулярно створюватися та періодично перевірятися відновленням.

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

• Дамп PostgreSQL: завдання, користувачі, проєкти, права доступу та налаштування.
• Docker volume vikunja_files: файли, прикріплені до завдань.
• Каталог /opt/vikunja: Compose, Caddyfile, файл .env і скрипти.
• Дані Caddy: сертифікати та стан ACME. Вони не критичні для даних Vikunja, але пришвидшують відновлення.

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

Встановіть restic

sudo apt update
sudo apt install -y restic

Для S3-сумісного сховища створіть файл зі змінними. Не додавайте його до Git і встановіть права 600.

nano /opt/vikunja/.restic-env
chmod 600 /opt/vikunja/.restic-env

export RESTIC_REPOSITORY="s3:https://s3.example.net/vikunja-backups"
export RESTIC_PASSWORD="CHANGE_TO_A_LONG_UNIQUE_BACKUP_PASSWORD"
export AWS_ACCESS_KEY_ID="S3_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="S3_SECRET_KEY"

Ініціалізуйте порожній репозиторій один раз.

source /opt/vikunja/.restic-env
restic init

Створіть скрипт резервного копіювання

Скрипт спочатку створює узгоджений дамп PostgreSQL через pg_dump, потім надсилає дамп, конфігурацію та том файлів у restic. Команда Docker тимчасово запускає контейнер Alpine, який читає volume із вкладеннями лише для архівування.

nano /opt/vikunja/scripts/backup.sh
chmod 700 /opt/vikunja/scripts/backup.sh

#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/vikunja"
BACKUP_DIR="${APP_DIR}/backups"
DATE="$(date +%F_%H-%M-%S)"

source "${APP_DIR}/.restic-env"
mkdir -p "${BACKUP_DIR}"

cd "${APP_DIR}"

docker compose exec -T db pg_dump \
  -U "${POSTGRES_USER}" \
  -d "${POSTGRES_DB}" \
  -Fc > "${BACKUP_DIR}/vikunja_${DATE}.dump"

docker run --rm \
  -v vikunja_vikunja_files:/source:ro \
  -v "${BACKUP_DIR}:/backup" \
  alpine:3.21 \
  tar -czf "/backup/vikunja_files_${DATE}.tar.gz" -C /source .

restic backup \
  "${BACKUP_DIR}/vikunja_${DATE}.dump" \
  "${BACKUP_DIR}/vikunja_files_${DATE}.tar.gz" \
  "${APP_DIR}/compose.yaml" \
  "${APP_DIR}/.env" \
  "${APP_DIR}/caddy/Caddyfile"

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

rm -f "${BACKUP_DIR}/vikunja_${DATE}.dump"
rm -f "${BACKUP_DIR}/vikunja_files_${DATE}.tar.gz"

Перший запуск виконайте вручну. Так ви одразу побачите помилку доступу до S3, неправильний пароль або проблему з назвою Docker volume.

/opt/vikunja/scripts/backup.sh
source /opt/vikunja/.restic-env
restic snapshots

Налаштуйте щоденний запуск через cron

Запускайте резервне копіювання вночі, коли навантаження мінімальне. Вивід надсилається до логу, який варто періодично переглядати.

crontab -e

30 3    /opt/vikunja/scripts/backup.sh >> /opt/vikunja/backups/backup.log 2>&1

Перевірка відновлення

Щонайменше раз на квартал відновлюйте одну резервну копію на тестовий VPS або в окремий каталог. Наявність snapshots не гарантує, що пароль репозиторію збережено, архів не пошкоджений, а процедура відновлення зрозуміла в аварійній ситуації.

source /opt/vikunja/.restic-env
restic restore latest --target /tmp/vikunja-restore-test
find /tmp/vikunja-restore-test -type f | head

План оновлення

Для невеликої інсталяції оновлюйте Vikunja у maintenance window раз на 1–2 місяці. Спочатку створіть резервну копію, прочитайте changelog цільової версії, змініть VIKUNJA_VERSION у .env, завантажте образи та перезапустіть контейнери. Не змінюйте major-версію PostgreSQL простим редагуванням тега: для неї потрібна окрема процедура міграції даних.

cd /opt/vikunja
/opt/vikunja/scripts/backup.sh
nano .env
docker compose pull
docker compose up -d
docker compose logs --tail=100 api
curl -fsS https://tasks.example.com/api/v1/info

Rolling update має сенс за наявності кількох екземплярів API та окремої бази даних. Для одного VPS достатньо короткої контрольованої перерви: зазвичай інтерфейс недоступний менш ніж хвилину, а ризик некоректного оновлення нижчий.

Troubleshooting і FAQ

Чому Caddy не отримує SSL-сертифікат?

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

Чому інтерфейс відкривається, але API повертає 502 Bad Gateway?

Код 502 означає, що Caddy не може підключитися до контейнера API. Перевірте статуси через docker compose ps і журнал docker compose logs api. Зазвичай API не запускається через неправильний пароль PostgreSQL, відсутній JWT-secret або незавершену ініціалізацію бази. Також переконайтеся, що в Caddyfile вказано адресу api:3456, а не localhost: контейнери використовують внутрішню Docker-мережу.

Чому Vikunja видає помилку підключення до PostgreSQL?

Спочатку виконайте docker compose logs db і переконайтеся, що контейнер бази має статус healthy. Якщо пароль POSTGRES_PASSWORD було змінено після першого запуску PostgreSQL, база продовжить використовувати старий пароль із наявного volume. Поверніть попередній пароль або створіть нового користувача вручну всередині PostgreSQL. Не видаляйте volume бази як спосіб «виправити» помилку: це видалить усі завдання та користувачів.

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

Для однієї людини або кількох користувачів мінімально підійдуть 1 vCPU, 1 ГБ RAM і 25 ГБ SSD. Проте практичніша конфігурація — 2 vCPU, 2 ГБ RAM і 40 ГБ NVMe: на ній комфортніше виконувати оновлення Docker, створювати архіви та зберігати кілька днів локальних тимчасових резервних копій. Якщо плануються великі вкладення, спочатку збільште диск, а потім пам'ять.

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

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

Чому після оновлення фронтенд показує стару версію або порожню сторінку?

Спочатку очистьте кеш браузера або відкрийте сервіс у приватному вікні: фронтенд є статичним застосунком і може кешуватися. Потім перевірте, що API та frontend використовують сумісні теги Vikunja у .env. Не оновлюйте лише один із двох образів. Перегляньте логи фронтенду та Caddy, потім виконайте docker compose pull && docker compose up -d.

Як збільшити допустимий розмір вкладень?

Змініть параметр VIKUNJA_SERVICE_MAXIMUMATTACHMENTSIZE у файлі .env. Значення вказується в байтах: наприклад, 104857600 відповідає 100 МБ. Після зміни перезапустіть API-контейнер командою docker compose up -d --force-recreate api. Перевірте вільне місце через df -h; великі вкладення швидко збільшують розмір Docker volume і час резервного копіювання.

Чи можна перенести Vikunja на інший сервер?

Так. На новому сервері встановіть Docker, створіть каталог /opt/vikunja, відновіть compose.yaml, .env і Caddyfile. Потім відновіть дамп PostgreSQL у нову базу та розпакуйте архів файлів у volume vikunja_vikunja_files. Після перемикання DNS перевірте вхід, проєкти та вкладення. На час міграції краще зупинити старий сервіс, щоб не втратити завдання, створені після фінальної резервної копії.

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

Тепер Vikunja працює на VPS в ізольованих Docker-контейнерах, доступний через HTTPS і захищений базовими правилами firewall. Дані завдань зберігаються у PostgreSQL, а файли вкладень і конфігурація включені до плану резервного копіювання.

1. Створіть тестові проєкти, налаштуйте права команд і вимкніть публічну реєстрацію, якщо вона не потрібна.
2. Перевірте відновлення резервної копії на окремій машині до того, як сервіс стане критичним для роботи.
3. Зі зростанням команди винесіть резервні копії в окреме сховище, налаштуйте моніторинг вільного місця та планові оновлення.