Налаштування BorgBackup на VPS

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

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

1. Налаштування змінних оточення для пароля Borg

Щоб не вводити пароль при кожному запуску скрипта, Borg може брати його зі змінної оточення BORG_PASSPHRASE. Це зручно для автоматизації, але вимагає обережності у зберіганні.

# На клієнтському сервері
# Створюємо файл для зберігання змінних оточення
sudo nano /etc/profile.d/borg_env.sh

Вставте наступний вміст, замінивши ВАШ_ПАРОЛЬ_К_РЕПОЗИТОРИЮ на ваш реальний пароль:

#!/bin/bash
export BORG_PASSPHRASE="ВАШ_ПАРОЛЬ_ДО_РЕПОЗИТОРІЮ"
export BORG_REPO="ssh://borguser@ваш_ip_або_домен_репозиторію:22/home/borguser/backups/my_server_repo"
export BORG_CACHE_DIR="/var/cache/borg" # Директорія для кешу Borg

Збережіть файл і зробіть його виконуваним:

sudo chmod 600 /etc/profile.d/borg_env.sh # Встановлення прав доступу
sudo chown root:root /etc/profile.d/borg_env.sh # Встановлення власника
# Щоб змінні були доступні в поточній сесії (для перевірки)
source /etc/profile.d/borg_env.sh

Важливо: Переконайтеся, що права доступу до цього файлу обмежені, щоб лише root міг його читати. Для cron-завдань змінні оточення будуть завантажені автоматично, якщо скрипт запускатиметься з відповідними правами.

2. Створення скрипта для резервного копіювання

Створимо основний скрипт, який виконуватиме резервне копіювання. Цей скрипт включатиме створення архіву, його перевірку та очищення старих резервних копій.

# На клієнтському сервері
sudo mkdir -p /opt/backup_scripts # Створення директорії для скриптів
sudo nano /opt/backup_scripts/create_backup.sh

Вміст скрипта:

#!/bin/bash

# Завантаження змінних оточення
source /etc/profile.d/borg_env.sh

# Директорії для резервного копіювання
BACKUP_DIRS="/etc /var/www /home /var/lib/mysql_dumps" # Приклад: /var/lib/mysql_dumps має бути попередньо створена з дампами БД

# Ім'я архіву (з міткою часу)
ARCHIVE_NAME="{hostname}-$(date +%Y-%m-%d_%H-%M-%S)"

echo "--- Починаємо резервне копіювання до ${BORG_REPO}::${ARCHIVE_NAME} ---"

# Створення резервної копії
borg create --stats --progress \
    --compression zstd,5 \
    --exclude '/home//.cache' \
    --exclude '/var/cache/' \
    --exclude '/var/tmp/' \
    --exclude '/var/log/' \
    --exclude '/var/lib/mysql/.sock' \
    --exclude '/var/lib/mysql/mysql.sock' \
    --exclude '.log' \
    "${BORG_REPO}::${ARCHIVE_NAME}" ${BACKUP_DIRS} \
    2>&1 | tee /var/log/borg_backup.log # Перенаправлення виводу до лог-файлу

EXIT_STATUS=$?

if [ ${EXIT_STATUS} -eq 0 ]; then
    echo "--- Резервне копіювання успішно завершено ---"
elif [ ${EXIT_STATUS} -eq 1 ]; then
    echo "--- Резервне копіювання завершено з попередженнями (див. лог) ---"
else
    echo "--- Резервне копіювання завершено з помилкою (код ${EXIT_STATUS}, див. лог) ---"
fi

echo "--- Запускаємо перевірку репозиторію ---"
borg check --last 1 "${BORG_REPO}" # Перевірка останнього архіву

echo "--- Запускаємо очищення старих резервних копій ---"
# Політика зберігання:
# 7 останніх щоденних резервних копій
# 4 останніх щотижневих резервних копій
# 6 останніх щомісячних резервних копій
borg prune --list --stats --show-rc \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 "${BORG_REPO}" \
    2>&1 | tee -a /var/log/borg_backup.log # Додавання виводу до того ж лог-файлу

PRUNE_EXIT_STATUS=$?

if [ ${PRUNE_EXIT_STATUS} -eq 0 ]; then
    echo "--- Очищення успішно завершено ---"
else
    echo "--- Очищення завершено з помилкою (код ${PRUNE_EXIT_STATUS}, див. лог) ---"
fi

echo "--- Виводимо список архівів ---"
borg list "${BORG_REPO}"

echo "--- Скрипт резервного копіювання завершено ---"

Зробіть скрипт виконуваним:

sudo chmod +x /opt/backup_scripts/create_backup.sh # Робимо скрипт виконуваним

Пояснення до скрипта:

• source /etc/profile.d/borg_env.sh: Завантажує змінні BORG_PASSPHRASE та BORG_REPO.
• BACKUP_DIRS: Визначає, які директорії будуть резервуватися. Важливо, щоб дампи баз даних (наприклад, /var/lib/mysql_dumps) були попередньо створені.
• --compression zstd,5: Використовує алгоритм стиснення Zstandard з рівнем 5 (хороший баланс між швидкістю та ступенем стиснення).
• --exclude: Виключає тимчасові файли, кеші та логи, які не потрібні в резервних копіях.
• borg check: Перевіряє цілісність репозиторію. Це критично важливий крок для впевненості у можливості відновлення.
• borg prune: Видаляє старі архіви згідно із заданою політикою (7 щоденних, 4 щотижневих, 6 щомісячних). Це допомагає економити місце та підтримувати порядок.

3. Дампи баз даних (MySQL/PostgreSQL)

Перед запуском BorgBackup, якщо ви використовуєте бази даних, необхідно створити їх дампи. Наприклад, для MySQL:

# На клієнтському сервері
sudo mkdir -p /var/lib/mysql_dumps # Створення директорії для дампів
sudo chown mysql:mysql /var/lib/mysql_dumps # Встановлення власника (або вашого користувача, якщо дамп буде робитися від нього)
# Створення дампу всіх баз даних
sudo mysqldump --all-databases --single-transaction --flush-logs --master-data \
    -u root -p'ВАШ_ПАРОЛЬ_MYSQL' > /var/lib/mysql_dumps/all_databases_$(date +%Y%m%d%H%M%S).sql # Дамп усіх БД
# Або для конкретної бази
# sudo mysqldump -u root -p'ВАШ_ПАРОЛЬ_MYSQL' YOUR_DATABASE > /var/lib/mysql_dumps/your_database_$(date +%Y%m%d%H%M%S).sql

Цей крок має бути доданий до вашого скрипта create_backup.sh перед командою borg create, щоб Borg резервував вже готові дампи. Або створіть окремий скрипт для дампу, який запускатиметься перед основним резервним копіюванням.

4. Перевірка працездатності

Запустіть скрипт вручну, щоб переконатися, що все працює:

sudo /opt/backup_scripts/create_backup.sh # Запуск скрипта

Перевірте вивід у консолі та лог-файл /var/log/borg_backup.log на наявність помилок. Після успішного виконання ви можете перевірити список архівів на репозиторії:

borg list "${BORG_REPO}" # Перевірка списку архівів

Ви повинні побачити ім'я архіву, яке ви згенерували.

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

Після того як BorgBackup налаштований та протестований, необхідно автоматизувати процес та визначити стратегію обслуговування.

1. Що резервувати

Вибір даних для резервування залежить від вашого сервісу, але зазвичай включає:

• Конфігураційні файли: /etc/ (особливо /etc/nginx/, /etc/apache2/, /etc/php/, /etc/mysql/, /etc/ssh/, /etc/fail2ban/ тощо).
• Дані веб-серверів: /var/www/ або /opt/www/ (файли сайтів, статика, медіа).
• Домашні директорії користувачів: /home/ (якщо користувачі зберігають там важливі дані).
• Бази даних: Дампи баз даних (MySQL, PostgreSQL, MongoDB тощо), які мають бути створені перед запуском Borg. Наприклад, у /var/lib/mysql_dumps/.
• Застосунки: Якщо ви встановлювали щось поза пакетним менеджером (наприклад, у /opt/), включіть це.

Чого не резервувати: Тимчасові файли (/tmp, /var/tmp), кеші (/var/cache), логи (/var/log), системні файли ОС (крім /etc), які легко відновити перевстановленням пакетів.

2. Автоматизація резервного копіювання за допомогою cron

Для регулярного виконання скрипта резервного копіювання використовуйте cron.

# На клієнтському сервері
sudo crontab -e # Відкриття файлу crontab для root (або sudo crontab -e -u sysadmin для користувача sysadmin)

Додайте наступний рядок для щоденного резервного копіювання о 03:00 ночі:

0 3    /opt/backup_scripts/create_backup.sh > /dev/null 2>&1 # Щоденне резервне копіювання о 03:00

# У crontab -e
BORG_PASSPHRASE="ВАШ_ПАРОЛЬ_ДО_РЕПОЗИТОРІЮ"
BORG_REPO="ssh://borguser@ваш_ip_або_домен_репозиторію:22/home/borguser/backups/my_server_repo"
BORG_CACHE_DIR="/var/cache/borg"

0 3    /opt/backup_scripts/create_backup.sh > /dev/null 2>&1

3. Куди зберігати резервні копії (зовнішній S3 / окремий VPS)

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

Для максимальної надійності можна розглянути:

• Зовнішній S3-сумісний об'єктний сторадж: BorgBackup не підтримує S3 безпосередньо, але ви можете використовувати rclone для синхронізації репозиторію Borg з S3-сумісним сховищем після створення резервних копій. Це додає ще один рівень надмірності та географічного розподілу.
• Другий віддалений VPS: Створити другий Borg-репозиторій на іншому VPS (можливо, в іншому дата-центрі або регіоні) та відправляти резервні копії туди також.

Пам'ятайте про правило 3-2-1: 3 копії даних, на 2 різних носіях, 1 з яких знаходиться поза офісом/сайтом.

4. Відновлення даних

Відновлення даних — це найважливіший аспект будь-якої системи резервного копіювання. BorgBackup робить це відносно просто.

Список архівів:

borg list "${BORG_REPO}" # Показати всі архіви в репозиторії

Перегляд вмісту архіву:

borg list "${BORG_REPO}::ARCHIVE_NAME" # Показати вміст конкретного архіву (замініть ARCHIVE_NAME)

Відновлення всього архіву:

borg extract "${BORG_REPO}::ARCHIVE_NAME" --paths /path/to/restore/to # Відновити весь архів у вказану директорію

Відновлення конкретних файлів/директорій:

borg extract "${BORG_REPO}::ARCHIVE_NAME" path/to/file_or_dir --paths /path/to/restore/to # Відновити конкретний файл або директорію

Завжди відновлюйте дані в нову або тимчасову директорію, щоб уникнути перезапису існуючих файлів та переконатися у коректності відновлення.

5. Оновлення: rolling vs maintenance window

Оновлення BorgBackup та операційної системи має виконуватися регулярно.

• Rolling updates: Для некритичних компонентів та мінорних патчів ОС можна застосовувати оновлення регулярно, без зупинки сервісів.
• Maintenance window: Для мажорних оновлень BorgBackup або ОС, а також для оновлення ядра, рекомендується планувати "вікно обслуговування". Це час, коли ви можете зупинити сервіси, зробити знімок VPS (якщо ваш провайдер надає таку можливість), виконати оновлення та ретельно протестувати систему.

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

sudo apt update && sudo apt upgrade -y # Регулярне оновлення системи

Після оновлення ОС та BorgBackup завжди перевіряйте працездатність скрипта резервного копіювання та можливість відновлення даних.

Усунення несправностей + FAQ

Що робити, якщо BorgBackup видає помилку "Remote: Host key verification failed"?

Ця помилка означає, що SSH-клієнт не може підтвердити справжність віддаленого сервера. Найчастіше це відбувається при першому підключенні до нового сервера, якщо ви не підтвердили відбиток ключа, або якщо IP-адреса сервера змінилася, а старий ключ залишився в ~/.ssh/known_hosts. Для вирішення проблеми, видаліть відповідний рядок з файлу ~/.ssh/known_hosts на клієнтському сервері (або з /root/.ssh/known_hosts, якщо скрипт запускається від root) і спробуйте підключитися знову, підтвердивши новий відбиток.

Як вирішити проблему з нестачею місця на диску репозиторію?

Якщо на сервері-репозиторії закінчується місце, насамперед перевірте, як працює команда borg prune. Можливо, політика зберігання занадто ліберальна, і ви зберігаєте занадто багато старих архівів. Зменшіть кількість щоденних, щотижневих або щомісячних резервних копій, що зберігаються. Також перевірте, чи немає на диску інших великих файлів, що не стосуються Borg. Якщо проблема зберігається, можливо, настав час збільшити обсяг диска на VPS-репозиторії або розглянути перехід на dedicated сервер з більшим сховищем.

Який VPS-конфіг мінімально підійде для BorgBackup-репозиторію?

Для невеликого проєкту з обсягом даних до 100-200 GB та одним-двома клієнтами, мінімально підійде VPS з 1 vCPU, 2 GB RAM та 200 GB SSD/NVMe диска. Важливо, щоб диск був достатньо швидким для операцій Borg (SSD/NVMe краще). Якщо кількість даних або клієнтів зростає, то слід масштабувати ресурси, особливо RAM та дисковий простір.

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

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

Що робити, якщо забув пароль до репозиторію Borg?

Якщо ви забули пароль до репозиторію Borg, на жаль, відновити дані з нього буде неможливо. Шифрування Borg дуже надійне, і без пароля доступ до даних неможливий. Це підкреслює критичну важливість безпечного зберігання пароля. Завжди використовуйте менеджер паролів або інше надійне сховище для таких критично важливих даних.

Як перевірити цілісність резервних копій?

Регулярна перевірка цілісності резервних копій — це обов'язкова частина обслуговування. Для цього використовується команда borg check. Ви можете додати її до свого скрипта резервного копіювання, як ми це зробили, або запускати окремо. Команда borg check --repository-only перевіряє лише репозиторій, а borg check --archives-only перевіряє архіви. Повна перевірка borg check може зайняти багато часу для великих репозиторіїв, але вона гарантує, що дані не пошкоджені.

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

Так, BorgBackup чудово підходить для резервного копіювання кількох серверів в один центральний репозиторій. Для кожного сервера-клієнта достатньо створити свій набір SSH-ключів та налаштувати їх у authorized_keys користувача borguser на сервері-репозиторії, використовуючи опцію command="borg serve --restrict-to-path /home/borguser/backups/SERVER_NAME" для ізоляції кожного клієнта у своїй піддиректорії репозиторію. Це підвищує безпеку та дозволяє легко керувати резервними копіями різних джерел.

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

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

Наступні кроки для подальшого покращення вашої системи резервного копіювання можуть включати:

• Налаштування моніторингу: Інтегруйте логи BorgBackup із системою моніторингу (наприклад, Prometheus, Grafana, ELK-стек) для відстеження успішності резервних копій та попереджень про помилки.
• Додаткова надмірність: Розгляньте можливість створення копій вашого Borg-репозиторію на іншому віддаленому сховищі (наприклад, S3-сумісному або другому VPS) для реалізації правила 3-2-1.
• Регулярне тестування відновлення: Періодично тестуйте процес відновлення даних, щоб переконатися, що резервні копії актуальні та працездатні. Це дасть вам впевненість у критичній ситуації.