Розгортання Wiki.js на VPS: встановлення з Docker Compose, PostgreSQL та Nginx Proxy
TL;DR
У цьому докладному посібнику ми крок за кроком налаштуємо сучасну та потужну вікі-систему Wiki.js на вашому власному VPS. Ви навчитеся використовувати Docker Compose для оркестрації сервісів, включаючи базу даних PostgreSQL та зворотний проксі Nginx Proxy Manager з автоматичною видачею SSL-сертифікатів Let's Encrypt, забезпечуючи безпечний та масштабований доступ до вашої документації або знань.
- Налаштування безпечного та оптимізованого VPS з Ubuntu 24.04 LTS.
- Встановлення Docker та Docker Compose для контейнеризації застосунків.
- Розгортання Wiki.js, PostgreSQL та Nginx Proxy Manager за допомогою єдиного файлу
docker-compose.yml. - Автоматичне налаштування HTTPS через Let's Encrypt для Wiki.js.
- Створення ефективної стратегії резервного копіювання для даних Wiki.js та PostgreSQL.
- Вирішення поширених проблем та оптимізація продуктивності.
Що ми налаштовуємо і навіщо
У цьому посібнику ми розгорнемо Wiki.js — сучасну, потужну та гнучку вікі-систему, призначену для командної роботи, документування проєктів, створення баз знань або особистих нотаток. Wiki.js пропонує інтуїтивно зрозумілий користувацький інтерфейс, підтримку різних редакторів (Markdown, AsciiDoc, WYSIWYG), інтеграцію із зовнішніми сервісами автентифікації (LDAP, OAuth, SAML) та широкі можливості для налаштування. Це ідеальне рішення для розробників, стартапів та всіх, хто потребує централізованого та легкодоступного сховища інформації.
У підсумку, ви отримаєте повністю функціональну вікі-систему, доступну за вашим доменним ім'ям через HTTPS, що працює в ізольованих контейнерах на вашому VPS. Це забезпечить високу стабільність, безпеку та простоту обслуговування. Усі компоненти — Wiki.js, база даних PostgreSQL та зворотний проксі Nginx Proxy Manager — керуватимуться за допомогою Docker Compose, що значно спрощує їх розгортання та масштабування.
Існують різні підходи до створення баз знань. Можна використовувати хмарні сервіси, такі як Notion, Confluence Cloud, GitBook або навіть Google Docs. Ці рішення пропонують зручність "під ключ" з мінімальними зусиллями з адміністрування. Однак вони часто пов'язані з підписною моделлю, обмеженнями за функціоналом або обсягом даних, а також питаннями конфіденційності, оскільки ваші дані зберігаються на чужих серверах. Для невеликих команд або особистих проєктів щомісячні платежі можуть виявитися невиправдано високими, а контроль над даними — недостатнім.
Самостійне розміщення (self-hosted) Wiki.js на VPS надає повний контроль над даними, безпекою та конфігурацією. Ви не залежите від тарифних планів сторонніх провайдерів, можете налаштовувати систему під свої унікальні потреби та бути впевненими у конфіденційності інформації. Крім того, це чудова можливість поглибити свої знання в галузі адміністрування серверів та контейнеризації, що є цінною навичкою для будь-якого технічного фахівця.
Який VPS-конфіг потрібен для цього завдання
Вибір відповідного VPS-конфігу критично важливий для стабільної та швидкої роботи Wiki.js. Хоча Wiki.js досить легковесний, база даних та зворотний проксі також споживають ресурси. Ми будемо орієнтуватися на актуальні вимоги для 2026 року, враховуючи зростання складності веб-застосунків та операційних систем.
Мінімальні вимоги
- CPU: 2 ядра. Сучасні процесори з тактовою частотою 2.5 ГГц і вище забезпечать хорошу чуйність. Одне ядро може бути достатньо для дуже маленьких інсталяцій (1-2 користувачі), але для стабільної роботи та обробки фонових завдань (пошук, індексація) краще мати два.
- RAM: 2 ГБ. Цього буде достатньо для Wiki.js, PostgreSQL та Nginx Proxy Manager. Wiki.js сам по собі може споживати 300-500 МБ, PostgreSQL — 200-400 МБ, плюс ОС та Docker-демон. Якщо планується активне використання або велика кількість статей, краще розглянути 4 ГБ.
- Диск: 40 ГБ SSD. SSD критично важливий для продуктивності бази даних та швидкості завантаження сторінок. 40 ГБ дадуть запас для операційної системи, Docker-образів, даних Wiki.js та потенційних резервних копій. Якщо ви плануєте зберігати багато зображень або файлів у вікі, розгляньте 80-100 ГБ.
- Мережа: 100 Мбіт/с симетричний канал. Для більшості випадків цього більш ніж достатньо. Важливіша стабільність каналу та низький пінг.
Конкретний VPS-план для завдання
Для розгортання Wiki.js з Docker Compose, PostgreSQL та Nginx Proxy Manager оптимальним буде наступний конфіг:
- CPU: 2-4 vCPU (віртуальних ядер)
- RAM: 4 ГБ
- Диск: 80 ГБ NVMe SSD (переважніше) або високопродуктивний SATA SSD
- Мережа: 200-500 Мбіт/с гарантований канал
Такої конфігурації буде достатньо для команди з 10-30 активних користувачів, з можливістю зберігання тисяч сторінок та сотень медіафайлів. Для стабільної роботи можна розглянути VPS із зазначеними характеристиками.
Коли потрібен dedicated, а не VPS
Dedicated-сервер стає необхідним у таких випадках:
- Дуже високе навантаження: Якщо ваша Wiki.js буде обслуговувати сотні або тисячі одночасних користувачів, обробляти величезні обсяги даних, або ви плануєте розміщувати на тому ж сервері інші ресурсоємні застосунки.
- Суворі вимоги до продуктивності: Для застосунків, критичних до затримок або таких, що вимагають максимальної продуктивності дискової підсистеми (наприклад, великі бази даних з високою частотою запису/читання).
- Спеціалізоване обладнання: Якщо вам потрібні специфічні апаратні компоненти, наприклад, GPU для машинного навчання, RAID-контролери для підвищеної відмовостійкості дисків, або дуже великі обсяги оперативної пам'яті (від 64 ГБ).
- Повний контроль над обладнанням: Dedicated-сервер дає повний фізичний контроль над обладнанням, що може бути важливим для деяких специфічних завдань або політик безпеки.
Для більшості інсталяцій Wiki.js VPS буде більш ніж достатнім та економічно вигідним. Якщо ви сумніваєтеся, почніть з VPS і масштабуйтеся до dedicated, коли виникне реальна потреба. Для дуже великих проєктів можна розглянути відповідний dedicated.
Локація: на що впливає
Вибір локації VPS впливає на кілька ключових факторів:
- Затримка (Latency/Ping): Чим ближче сервер до ваших основних користувачів, тим нижчим буде пінг і швидшим завантаження сторінок. Для команди, що працює в одному місті/регіоні, вибирайте сервер у цьому ж регіоні. Для розподілених команд вибирайте центральну локацію або використовуйте CDN (Content Delivery Network).
- Законодавство: Закони про зберігання даних та конфіденційність можуть сильно відрізнятися залежно від країни. Переконайтеся, що обрана локація відповідає вимогам вашого бізнесу або особистим уподобанням.
- Вартість: Ціни на VPS можуть варіюватися залежно від локації через різницю у вартості електроенергії, інфраструктури та податків.
Завжди вибирайте локацію, яка максимально близька до більшості ваших користувачів, щоб забезпечити найкращий користувацький досвід.
Підготовка сервера
Перш ніж приступити до встановлення Wiki.js, необхідно виконати базове налаштування та посилення безпеки вашого VPS. Ми будемо використовувати Ubuntu 24.04 LTS (Noble Numbat), актуальну на 2026 рік, як основу для нашого сервера.
1. Підключення до сервера та оновлення системи
Підключіться до вашого сервера по SSH, використовуючи дані, надані вашим VPS-провайдером. Зазвичай це IP-адреса, ім'я користувача (root) та пароль.
ssh root@ВАШ_IP_АДРЕС_VPS
Після успішного входу оновіть список пакетів та встановлені пакети до останніх версій.
sudo apt update && sudo apt upgrade -y
Це забезпечить, що всі системні компоненти актуальні та містять останні виправлення безпеки.
2. Створення нового користувача з правами sudo
Робота під користувачем root небезпечна. Створимо нового користувача та надамо йому права sudo.
sudo adduser wikiuser
Дотримуйтесь інструкцій на екрані, щоб задати пароль та інформацію про користувача. Потім додайте користувача до групи sudo.
sudo usermod -aG sudo wikiuser
Тепер ви можете переключитися на нового користувача та продовжити роботу.
su - wikiuser
Або відкрити нову SSH-сесію під цим користувачем.
ssh wikiuser@ВАШ_IP_АДРЕС_VPS
3. Налаштування автентифікації за SSH-ключами (рекомендується)
Для підвищення безпеки рекомендується використовувати SSH-ключі замість паролів. Згенеруйте пару ключей на вашій локальній машині, якщо у вас їх ще немає.
# На вашій локальній машині
ssh-keygen -t rsa -b 4096
Потім скопіюйте публічний ключ на сервер для користувача wikiuser.
# На вашій локальній машині
ssh-copy-id wikiuser@ВАШ_IP_АДРЕС_VPS
Після цього вимкніть автентифікацію за паролем для SSH. Відредагуйте файл /etc/ssh/sshd_config.
sudo nano /etc/ssh/sshd_config
Знайдіть та змініть наступні рядки (або додайте, якщо відсутні):
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin no
Перезапустіть SSH-сервіс.
sudo systemctl restart sshd
Тепер ви зможете підключатися лише за SSH-ключами, і користувач root не зможе залогінитися безпосередньо.
4. Налаштування брандмауера (UFW)
UFW (Uncomplicated Firewall) — це простий у використанні інтерфейс для налаштування правил iptables. Дозволимо лише необхідні порти.
sudo apt install ufw -y # Встановлення UFW, якщо ще не встановлений
sudo ufw default deny incoming # Заборонити всі вхідні з'єднання за замовчуванням
sudo ufw default allow outgoing # Дозволити всі вихідні з'єднання за замовчуванням
sudo ufw allow ssh # Дозволити SSH (порт 22)
sudo ufw allow http # Дозволити HTTP (порт 80)
sudo ufw allow https # Дозволити HTTPS (порт 443)
sudo ufw enable # Увімкнути брандмауер
sudo ufw status verbose # Перевірити статус брандмауера
Тепер ваш сервер захищений від небажаних вхідних підключень.
5. Встановлення Fail2Ban
Fail2Ban сканує логи на наявність підозрілої активності (наприклад, багаторазових невдалих спроб входу SSH) та автоматично блокує IP-адреси зловмисників. Це додатковий рівень захисту.
sudo apt install fail2ban -y
sudo systemctl enable fail2ban # Увімкнути автозапуск Fail2Ban при старті системи
sudo systemctl start fail2ban # Запустити Fail2Ban
Fail2Ban за замовчуванням налаштований на захист SSH. Ви можете перевірити його статус:
sudo fail2ban-client status
sudo fail2ban-client status sshd
На цьому базову підготовку сервера завершено. Тепер можна приступати до встановлення програмного забезпечення.
Встановлення ПЗ — покроково
Встановлення ПЗ — покроково
Ми будемо використовувати Docker та Docker Compose для розгортання Wiki.js, PostgreSQL та Nginx Proxy Manager. Це забезпечує ізоляцію програм, спрощує керування залежностями та полегшує масштабування.
1. Встановлення Docker Engine
Спочатку встановимо необхідні пакети для Docker.
sudo apt update # Оновити список пакетів
sudo apt install ca-certificates curl gnupg lsb-release -y # Встановити залежності
Додамо офіційний GPG-ключ 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 # Завантажити та додати GPG-ключ
sudo chmod a+r /etc/apt/keyrings/docker.gpg # Встановити правильні права доступу
Додамо репозиторій Docker до 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
Оновимо список пакетів знову та встановимо Docker Engine, Docker CLI та containerd.
sudo apt update # Оновити список пакетів після додавання репозиторію
sudo apt install docker-ce docker-ce-cli containerd.io -y # Встановити Docker Engine (версія буде актуальною на 2026 рік, наприклад, 25.0.x або 26.0.x)
Перевіримо статус Docker-сервісу.
sudo systemctl status docker # Переконатися, що Docker запущений та активний
Додамо вашого користувача до групи docker, щоб не використовувати sudo при кожній команді Docker.
sudo usermod -aG docker ${USER} # Додати поточного користувача до групи docker
newgrp docker # Застосувати зміни групи без перезаходу (або просто перезапустіть SSH-сесію)
Перевіримо встановлення Docker, запустивши тестовий контейнер.
docker run hello-world # Запустити тестовий контейнер для перевірки встановлення Docker
2. Встановлення Docker Compose
Docker Compose — це інструмент для визначення та запуску багатоконтейнерних Docker-додатків. Ми встановимо його як плагін Docker CLI.
sudo apt install docker-compose-plugin -y # Встановити Docker Compose як плагін для Docker CLI (версія буде актуальною на 2026 рік)
Перевіримо версію Docker Compose.
docker compose version # Перевірити, що Docker Compose встановлено коректно
3. Підготовка структури каталогів
Створимо директорію для нашого проєкту Wiki.js та піддиректорії для даних.
mkdir -p ~/wiki # Створити основну директорію для проєкту
cd ~/wiki # Перейти до створеної директорії
mkdir -p data/wiki # Директорія для даних Wiki.js (файли, uploads)
mkdir -p data/db # Директорія для даних PostgreSQL
4. Створення файлу docker-compose.yml
Цей файл визначатиме наші сервіси: Wiki.js, PostgreSQL та Nginx Proxy Manager.
nano docker-compose.yml # Відкрити редактор для створення файлу
Вставте наступний вміст (актуальні версії образів будуть підібрані для 2026 року):
version: '3.8'
services:
wiki:
image: ghcr.io/requarks/wiki:2.5.300 # Актуальна стабільна версія Wiki.js на 2026 рік
container_name: wiki-js
restart: unless-stopped
environment:
NODE_ENV: production
DB_TYPE: postgres
DB_HOST: db
DB_PORT: 5432
DB_USER: wikiuser
DB_PASS: ${DB_PASSWORD} # Пароль з .env
DB_NAME: wiki
DB_SSL: 'false' # Використовувати SSL лише якщо база даних знаходиться на окремому сервері або в іншій Docker-мережі
# Додаткові налаштування Wiki.js, наприклад, URL
WIKI_URL: https://wiki.example.com # Замініть на ваш домен
volumes:
- ./data/wiki:/var/wiki # Зберігаємо дані Wiki.js на хості
depends_on:
- db
networks:
- wiki-network
- npm-network # Сеть для Nginx Proxy Manager
db:
image: postgres:16-alpine # Актуальна стабільна версія PostgreSQL на 2026 рік
container_name: wiki-db
restart: unless-stopped
environment:
POSTGRES_DB: wiki
POSTGRES_USER: wikiuser
POSTGRES_PASSWORD: ${DB_PASSWORD} # Пароль з .env
volumes:
- ./data/db:/var/lib/postgresql/data # Зберігаємо дані БД на хості
networks:
- wiki-network
npm:
image: 'jc21/nginx-proxy-manager:latest' # Nginx Proxy Manager (версія буде актуальною на 2026 рік)
container_name: nginx-proxy-manager
restart: unless-stopped
ports:
- '80:80' # HTTP порт для Let's Encrypt та перенаправлення
- '443:443' # HTTPS порт
- '81:81' # Порт для адмін-панелі Nginx Proxy Manager
volumes:
- ./data/npm/data:/data # Дані Nginx Proxy Manager
- ./data/npm/letsencrypt:/etc/letsencrypt # Сертифікати Let's Encrypt
networks:
- npm-network
networks:
wiki-network:
driver: bridge
npm-network:
driver: bridge
Збережіть файл (Ctrl+O, Enter, Ctrl+X).
5. Створення файлу .env для секретів
Для зберігання паролів та інших чутливих даних використовуємо файл .env, який Docker Compose автоматично завантажує.
nano .env # Відкрити редактор для створення файлу
Вставте наступний вміст, замінивши YOUR_STRONG_DB_PASSWORD на надійний пароль.
DB_PASSWORD=YOUR_STRONG_DB_PASSWORD_12345
Збережіть файл (Ctrl+O, Enter, Ctrl+X). Переконайтеся, що файл .env не буде додано до системи контролю версій, якщо ви використовуєте Git.
6. Запуск сервісів Docker Compose
Тепер, коли всі файли готові, можна запустити наші сервіси.
docker compose up -d # Запустити всі сервіси у фоновому режимі
Ця команда завантажить необхідні Docker-образи (Wiki.js, PostgreSQL, Nginx Proxy Manager), створить контейнери та запустить їх. Процес може зайняти кілька хвилин залежно від швидкості вашого інтернет-з'єднання.
Перевіримо статус запущених контейнерів.
docker compose ps # Показати статус запущених контейнерів
Ви повинні побачити, що всі три контейнери (wiki-js, wiki-db, nginx-proxy-manager) знаходяться в статусі running.
На цьому етапі основні компоненти встановлені та запущені. Далі перейдемо до їх конфігурації.
Конфігурація
Після встановлення контейнерів необхідно налаштувати Nginx Proxy Manager для маршрутизації трафіку до Wiki.js та отримання SSL-сертифіката, а також виконати первинне налаштування самої Wiki.js.
1. Налаштування Nginx Proxy Manager
Nginx Proxy Manager (NPM) надає зручний веб-інтерфейс для керування зворотним проксі та SSL-сертифікатами Let's Encrypt. Доступ до адмін-панелі NPM здійснюється через порт 81 вашого VPS.
Відкрийте в браузері: http://ВАШ_IP_АДРЕС_VPS:81
Первинний вхід
При першому вході вам будуть запропоновані стандартні облікові дані:
- Email:
[email protected] - Пароль:
changeme
Після входу система попросить вас змінити ці дані. Обов'язково встановіть надійний пароль та свій реальний email.
Додавання проксі-хоста для Wiki.js
Перейдіть до розділу "Hosts" -> "Proxy Hosts" та натисніть "Add Proxy Host".
- Domain Names:
wiki.example.com(замініть на ваш реальний домен, який ви налаштували в DNS-записах, що вказує на IP вашого VPS). - Scheme:
http - Forward Hostname / IP:
wiki-js(це ім'я сервісу Wiki.js з файлуdocker-compose.yml) - Forward Port:
3000(стандартний порт Wiki.js) - Block Common Exploits: Увімкніть (рекомендується)
- Websockets Support: Увімкніть (обов'язково для Wiki.js)
Перейдіть на вкладку "SSL".
- SSL Certificate: Виберіть "Request a new SSL Certificate".
- Force SSL: Увімкніть.
- Email Address for Let's Encrypt: Введіть ваш email.
- I Agree to the Let's Encrypt Terms of Service: Позначте.
Натисніть "Save". NPM спробує отримати SSL-сертифікат для вашого домену. Переконайтеся, що DNS-запис (тип A) для wiki.example.com вказує на IP-адресу вашого VPS до початку цього кроку.
Після успішного отримання сертифіката ваш Wiki.js буде доступний за HTTPS.
2. Первинне налаштування Wiki.js
Тепер відкрийте в браузері ваш домен: https://wiki.example.com
Wiki.js запропонує вам пройти процес первинного налаштування.
- Database Type: PostgreSQL (має бути вибрано за замовчуванням)
- Database Host:
db - Database Port:
5432 - Database Name:
wiki - Database User:
wikiuser - Database Password: Введіть той самий пароль, що ви вказали у файлі
.env(DB_PASSWORD).
Натисніть "Connect". Wiki.js перевірить з'єднання з базою даних.
Далі вам буде запропоновано створити обліковий запис адміністратора Wiki.js:
- Email: Введіть ваш email.
- Password: Задайте надійний пароль для адміністратора Wiki.js.
- Name: Ваше ім'я.
Завершіть встановлення. Після цього ви будете перенаправлені на сторінку входу до Wiki.js.
3. Перевірка працездатності
Після всіх налаштувань переконаємося, що все працює коректно.
Перевірка контейнерів
docker compose ps # Переконатися, що всі контейнери запущені
Всі контейнери повинні бути в статусі running.
Перевірка логів Wiki.js
docker compose logs wiki # Переглянути логи контейнера Wiki.js
Переконайтеся, що немає критичних помилок і Wiki.js успішно підключився до бази даних.
Перевірка доступності через curl
Виконайте запит до вашого домену з сервера, щоб переконатися, що Nginx Proxy Manager перенаправляє трафік.
curl -I https://wiki.example.com # Замініть на ваш домен
Ви повинні побачити HTTP-заголовки, що вказують на успішну відповідь (наприклад, HTTP/2 200).
На цьому етапі ваша Wiki.js повністю налаштована та доступна через HTTPS. Ви можете почати створювати сторінки та запрошувати користувачів.
Резервне копіювання та обслуговування
Регулярне резервне копіювання та своєчасне обслуговування є ключовими аспектами для забезпечення надійності та доступності вашої Wiki.js. Втрата даних може бути катастрофічною, тому важливо мати перевірену стратегію резервного копіювання.
Що резервувати
Для Wiki.js необхідно резервувати два основні компоненти:
- База даних PostgreSQL: Містить усі статті, користувачів, налаштування та метадані Wiki.js. Це найкритичніший компонент.
- Файли Wiki.js: Включають завантажені зображення, файли, а також потенційно користувацькі теми або плагіни. У нашому випадку це директорія
./data/wikiна хості. - Конфігурація Nginx Proxy Manager: Хоча NPM можна налаштувати заново, резервне копіювання його даних (сертифікатів, налаштувань проксі) значно прискорить відновлення. Це директорія
./data/npmна хості.
Простий скрипт авторезервування
Створимо простий скрипт, який виконуватиме резервне копіювання бази даних та файлів, а потім архівуватиме їх. Для зберігання можна використовувати локальний диск, а потім переносити на віддалене сховище.
Створіть директорію для резервних копій на сервері, наприклад, /var/backups/wiki.
sudo mkdir -p /var/backups/wiki
sudo chown wikiuser:wikiuser /var/backups/wiki # Надати права вашому користувачеві
Створіть файл скрипта backup_wiki.sh у домашній директорії користувача wikiuser:
nano ~/backup_wiki.sh
Вставте наступний вміст:
#!/bin/bash
# --- Налаштування ---
BACKUP_DIR="/var/backups/wiki"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
COMPOSE_PROJECT_DIR="/home/wikiuser/wiki" # Шлях до вашої директорії docker-compose.yml
DB_CONTAINER_NAME="wiki-db"
DB_USER="wikiuser"
DB_NAME="wiki"
WIKI_DATA_DIR="${COMPOSE_PROJECT_DIR}/data/wiki"
NPM_DATA_DIR="${COMPOSE_PROJECT_DIR}/data/npm"
RETENTION_DAYS=7 # Скільки днів зберігати резервні копії
# --- Перевірка директорії резервних копій ---
if [ ! -d "$BACKUP_DIR" ]; then
echo "Директорія резервних копій $BACKUP_DIR не існує. Створення..."
sudo mkdir -p "$BACKUP_DIR"
sudo chown wikiuser:wikiuser "$BACKUP_DIR"
fi
echo "Починаємо процес резервного копіювання Wiki.js о $TIMESTAMP"
# --- 1. Резервне копіювання бази даних PostgreSQL ---
echo "Резервне копіювання бази даних PostgreSQL..."
docker exec $DB_CONTAINER_NAME pg_dump -U $DB_USER -d $DB_NAME > "$BACKUP_DIR/wiki_db_$TIMESTAMP.sql"
if [ $? -eq 0 ]; then
echo "Резервна копія БД успішно створена: $BACKUP_DIR/wiki_db_$TIMESTAMP.sql"
else
echo "ПОМИЛКА: Не вдалося створити резервну копію БД."
exit 1
fi
# --- 2. Резервне копіювання файлів Wiki.js та Nginx Proxy Manager ---
echo "Архівування даних Wiki.js та NPM..."
tar -czf "$BACKUP_DIR/wiki_data_$TIMESTAMP.tar.gz" -C "$WIKI_DATA_DIR" .
if [ $? -eq 0 ]; then
echo "Архів даних Wiki.js успішно створено: $BACKUP_DIR/wiki_data_$TIMESTAMP.tar.gz"
else
echo "ПОМИЛКА: Не вдалося створити архів даних Wiki.js."
exit 1
fi
tar -czf "$BACKUP_DIR/npm_data_$TIMESTAMP.tar.gz" -C "$NPM_DATA_DIR" .
if [ $? -eq 0 ]; then
echo "Архів даних NPM успішно створено: $BACKUP_DIR/npm_data_$TIMESTAMP.tar.gz"
else
echo "ПОМИЛКА: Не вдалося створити архів даних NPM."
exit 1
fi
# --- 3. Видалення старих резервних копій ---
echo "Видалення старих резервних копій (старших за $RETENTION_DAYS днів)..."
find "$BACKUP_DIR" -type f -name "wiki_db_*.sql" -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -type f -name "wiki_data_*.tar.gz" -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -type f -name "npm_data_*.tar.gz" -mtime +$RETENTION_DAYS -delete
echo "Очищення старих резервних копій завершено."
echo "Процес резервного копіювання завершено."
Зробіть скрипт виконуваним:
chmod +x ~/backup_wiki.sh
Ви можете протестувати скрипт вручну:
~/backup_wiki.sh
Автоматизація резервного копіювання за допомогою Cron
Для автоматичного запуску скрипта резервного копіювання налаштуємо Cron. Наприклад, для щоденного резервного копіювання о 03:00 ночі:
crontab -e
Додайте наступний рядок у кінець файлу:
0 3 * * * /home/wikiuser/backup_wiki.sh >> /var/log/wiki_backup.log 2>&1
Цей рядок запускає скрипт щодня о 03:00 і перенаправляє вивід у лог-файл /var/log/wiki_backup.log.
Куди зберігати резервні копії (зовнішнє сховище)
Зберігання резервних копій на тому ж сервері, що й робочі дані, не забезпечує повного захисту. У разі виходу з ладу VPS, ви втратите і дані, і резервні копії. Рекомендується використовувати зовнішнє сховище:
- S3-сумісне сховище: Хмарні сервіси, такі як AWS S3, Backblaze B2, DigitalOcean Spaces, надають надійне та недороге зберігання. Ви можете використовувати утиліти на кшталт
s3cmd,rcloneабоaws cliдля автоматичної синхронізації локальних резервних копій з S3. - Окремий VPS: Ви можете налаштувати другий, менш потужний VPS, і використовувати
rsyncабоscpдля копіювання резервних копій на нього. Це забезпечує географічне розділення. - Мережеве сховище (NAS): Якщо у вас є власне мережеве сховище, можна налаштувати монтування по NFS/SMB і копіювати резервні копії туди.
Розширте скрипт backup_wiki.sh для автоматичного завантаження резервних копій на вибране зовнішнє сховище після їх створення.
Оновлення: rolling vs maintenance window
Підтримка ПЗ в актуальному стані критично важлива для безпеки та отримання нових функцій.
- Оновлення Docker-образів (Wiki.js, PostgreSQL, Nginx Proxy Manager):
- Maintenance window: Це рекомендований підхід. Виділяйте певний час (наприклад, раз на місяць), щоб зупинити сервіси, оновити образи та протестувати.
cd ~/wiki # Перейдіть у директорію з docker-compose.yml docker compose pull # Завантажити останні версії образів docker compose down # Зупинити та видалити поточні контейнери docker compose up -d # Запустити нові контейнери з оновленими образами - Тестування: Завжди перевіряйте працездатність Wiki.js після оновлення. Нові версії можуть містити зміни, що вимагають ручної адаптації, хоча для мінорних версій це рідкість.
- Maintenance window: Це рекомендований підхід. Виділяйте певний час (наприклад, раз на місяць), щоб зупинити сервіси, оновити образи та протестувати.
- Оновлення ОС (Ubuntu):
- Раз на кілька місяців виконуйте повне оновлення системи:
sudo apt update && sudo apt upgrade -y. Це також краще робити у "вікно обслуговування", оскільки може знадобитися перезавантаження сервера.
- Раз на кілька місяців виконуйте повне оновлення системи:
Уникайте "rolling updates" для продакшн-систем без належної автоматизації та тестування, оскільки це може призвести до несподіваних простоїв.