Налаштувати автоматичне резервне копіювання на вашому виділеному…

Чому автоматизовані резервні копії є критично важливими для вашого виділеного сервера

Ваш виділений сервер є основою ваших операцій, будь то високотрафікова платформа електронної комерції, критично важлива база даних, популярний ігровий сервер або складний CI/CD конвеєр. Властиві потужність і контроль bare-metal сервера супроводжуються відповідальністю за надійний захист даних. Ручні резервні копії схильні до людських помилок, непослідовності та можуть бути легко пропущені. Автоматизовані резервні копії усувають ці ризики, забезпечуючи послідовну, заплановану мережу безпеки для ваших даних.

Поширені сценарії, коли резервні копії рятують ситуацію:

Відмова обладнання: Навіть найнадійніше обладнання може вийти з ладу. Збій диска може миттєво знищити роки роботи.
Пошкодження програмного забезпечення: Невдалі оновлення ОС, помилки додатків або неправильні конфігурації можуть зробити ваш сервер непридатним для використання.
Людська помилка: Випадкове видалення критичних файлів або неправильне виконання команд є основною причиною втрати даних.
Порушення безпеки: Атаки програм-вимагачів або зловмисні вторгнення можуть зашифрувати або видалити ваші дані. Резервні копії забезпечують чистий аркуш для відновлення.
Відповідність вимогам та аудит: Багато галузей вимагають конкретних політик зберігання даних, що робить автоматизовані, перевіряються резервні копії необхідними.

Реальні випадки використання резервних копій виділеного сервера:

Веб-хостинг: Захист веб-сайтів клієнтів, баз даних та файлів додатків від випадкового видалення або зловмисних атак.
Ігрові сервери: Захист даних гравців, файлів світу та конфігурацій сервера для популярних багатокористувацьких ігор.
Бази даних: Забезпечення цілісності транзакцій та відновлення на певний момент часу для MySQL, PostgreSQL, MongoDB та інших систем баз даних.
Поштові сервери: Збереження критичних архівів електронної пошти, облікових записів користувачів та конфігурацій сервера.
Стрімінгові сервіси: Резервне копіювання медіа-бібліотек, профілів користувачів та конфігурацій доставки контенту.
CI/CD конвеєри: Зберігання артефактів збірки, репозиторіїв вихідного коду та критичних файлів конфігурації для середовищ розробки.
Віртуалізація: Резервне копіювання образів віртуальних машин та конфігурацій, якщо ви запускаєте власний гіпервізор на bare-metal сервері.

Передумови та планування вашої стратегії резервного копіювання

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

1. Вимоги до сервера

Дисковий простір: Переконайтеся, що ваш виділений сервер має достатньо вільного місця для тимчасових файлів резервних копій, особливо якщо ви створюєте резервні копії локально перед передачею за межі сайту. Для виділених серверів Valebyte ви часто можете вибрати конфігурації з великими можливостями зберігання або додати додаткові диски.
Мережеве підключення: Високошвидкісне мережеве підключення є критично важливим для ефективної передачі за межі сайту, особливо для великих наборів даних. Надійна мережева інфраструктура Valebyte гарантує швидку та надійну передачу ваших резервних копій.
CPU та RAM: Хоча це не є основними проблемами для простих резервних копій файлів, такі завдання, як дампи баз даних, стиснення та шифрування, можуть бути інтенсивними для CPU та RAM. Плануйте їх на години низького навантаження або переконайтеся, що ваш сервер має достатньо ресурсів.

2. Призначення резервної копії (де зберігати ваші резервні копії)

Правило резервного копіювання 3-2-1 (обговорюється пізніше) наголошує на кількох копіях та зберіганні за межами сайту. Розгляньте ці варіанти:

Локальний диск: Окремий розділ або диск на тому ж сервері. Добре підходить для швидкого відновлення після випадкового видалення, але не забезпечує захисту від відмови обладнання або катастрофи на всьому сервері.
Віддалений сервер (SSH/NFS/SMB): Інший виділений сервер, можливо, в іншому центрі обробки даних, доступний через SSH, NFS або SMB. Це чудове рішення для зберігання за межами сайту.
Об'єктне сховище (S3-сумісне): Хмарні сервіси об'єктного сховища пропонують високу довговічність, масштабованість і часто економічну ефективність. Багато інструментів підтримують S3 API.
Виділений пристрій/сервіс для резервного копіювання: Деякі провайдери пропонують спеціалізовані рішення для резервного копіювання.

3. Інструменти та технології резервного копіювання

rsync: Універсальна утиліта для ефективної, інкрементальної передачі файлів. Ідеально підходить для дзеркального відображення каталогів.
tar: Стандартна утиліта Unix для архівування кількох файлів в один архів. Часто використовується разом з gzip або bzip2 для стиснення.
mysqldump/pg_dump: Необхідні для послідовного резервного копіювання баз даних без блокування таблиць.
duplicity: Розширений інструмент для зашифрованих, інкрементальних та ефективних за пропускною здатністю резервних копій на різні бекенди (SSH, S3, FTP тощо).
borgbackup: Архівувальник з дедуплікацією, стисненням та автентифікованим шифруванням. Дуже ефективний для великих наборів даних з багатьма невеликими змінами.

4. Міркування безпеки

SSH ключі: Використовуйте SSH ключі для безпарольного та безпечного доступу до віддалених місць призначення резервних копій.
Шифрування: Шифруйте свої резервні копії, особливо якщо зберігаєте їх за межами сайту або в хмарі. Такі інструменти, як Duplicity, пропонують вбудоване GPG шифрування.
Дозволи: Переконайтеся, що скрипти та каталоги резервного копіювання мають відповідні дозволи для запобігання несанкціонованому доступу.

5. Політика зберігання

Як довго вам потрібно зберігати свої резервні копії? Поширені стратегії включають:

Щоденно: Зберігати 7-14 днів.
Щотижня: Зберігати 4-8 тижнів.
Щомісяця: Зберігати 6-12 місяців.
Grandfather-Father-Son (GFS): Поширена стратегія, що передбачає зберігання щоденних (сина), щотижневих (батька) та щомісячних (діда) резервних копій протягом тривалих періодів.

6. План тестування та моніторингу

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

Метод 1: Прості автоматизовані резервні копії за допомогою rsync та cron

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

Крок 1: Підготуйте місце призначення резервної копії

Спочатку вирішіть, куди будуть надходити ваші резервні копії. Для цього прикладу припустимо, що це віддалений сервер (backup.example.com), де ви будете зберігати свої дані. Вам знадобиться SSH-доступ до цього сервера.

На віддаленому сервері резервного копіювання (`backup.example.com`):

Створіть виділеного користувача та каталог для резервних копій:


sudo useradd -m -s /bin/bash backupuser
sudo mkdir -p /backups/myserver
sudo chown -R backupuser:backupuser /backups/myserver

На вашому виділеному сервері (`yourserver.valebyte.com`):

Згенеруйте пару SSH-ключів (якщо у вас її немає) і скопіюйте відкритий ключ на віддалений сервер резервного копіювання. Це дозволить безпарольну автентифікацію для rsync.


ssh-keygen -t rsa -b 4096
ssh-copy-id [email protected]

Перевірте SSH-з'єднання:


ssh [email protected]

Ви повинні підключитися без пароля.

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

Давайте створимо скрипт, який створює резервну копію веб-каталогу (/var/www/html) та бази даних MySQL на віддалений сервер. Ми використовуватимемо tar для архівування та rsync для ефективної передачі.

Створіть файл з назвою /usr/local/bin/backup_script.sh:


#!/bin/bash

# --- Configuration --- #
BACKUP_DIR="/tmp/backup_staging"
REMOTE_USER="backupuser"
REMOTE_HOST="backup.example.com"
REMOTE_PATH="/backups/myserver"
DATE=$(date +%Y%m%d%H%M%S)
LOG_FILE="/var/log/backup_script.log"

# Directories to backup
WEB_ROOT="/var/www/html"

# MySQL Database Configuration
DB_USER="your_db_user"
DB_PASS="your_db_password"
DB_NAME="your_database_name"

# --- Pre-backup Checks --- #
mkdir -p $BACKUP_DIR || { echo "Failed to create staging directory." >> $LOG_FILE; exit 1; }

echo "$(date): Starting backup process..." >> $LOG_FILE

# --- 1. Backup Web Files --- #
echo "$(date): Backing up web files from $WEB_ROOT..." >> $LOG_FILE
tar -czf "$BACKUP_DIR/web_html_${DATE}.tar.gz" -C "$(dirname $WEB_ROOT)" "$(basename $WEB_ROOT)" \\
    || { echo "$(date): Failed to backup web files." >> $LOG_FILE; rm -rf $BACKUP_DIR; exit 1; }

# --- 2. Backup MySQL Database --- #
echo "$(date): Backing up MySQL database '$DB_NAME'..." >> $LOG_FILE
mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" | gzip > "$BACKUP_DIR/mysql_${DB_NAME}_${DATE}.sql.gz" \\
    || { echo "$(date): Failed to backup MySQL database." >> $LOG_FILE; rm -rf $BACKUP_DIR; exit 1; }

# --- 3. Rsync to Remote Server --- #
echo "$(date): Transferring backups to remote server..." >> $LOG_FILE
rsync -avz --delete-excluded \\
    --exclude 'cache/' \\
    --exclude 'tmp/' \\
    --exclude '.git/' \\
    --log-file="$LOG_FILE" \\
    "$BACKUP_DIR/" "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_PATH}/" \\
    || { echo "$(date): Rsync failed." >> $LOG_FILE; rm -rf $BACKUP_DIR; exit 1; }

# --- 4. Clean up Staging Directory --- #
echo "$(date): Cleaning up staging directory..." >> $LOG_FILE
rm -rf $BACKUP_DIR || { echo "$(date): Failed to clean up staging directory." >> $LOG_FILE; exit 1; }

echo "$(date): Backup process completed successfully." >> $LOG_FILE
exit 0

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

BACKUP_DIR: Тимчасова область для файлів резервних копій перед передачею.
REMOTE_USER, REMOTE_HOST, REMOTE_PATH: Деталі для вашого віддаленого сервера резервного копіювання.
DATE: Використовується для позначення часу файлів резервних копій.
LOG_FILE: Усі вихідні дані та помилки скрипта реєструються тут.
tar -czf ...: Архівує та стискає кореневий веб-каталог. -C "$(dirname $WEB_ROOT)" "$(basename $WEB_ROOT)" гарантує, що архів містить сам каталог, а не лише його вміст, і створюється відносно його батьківського каталогу.
mysqldump ... | gzip > ...: Зберігає вказану базу даних MySQL та передає її безпосередньо до gzip для стиснення. Прапор --single-transaction є критично важливим для таблиць InnoDB для забезпечення послідовного знімка без блокування таблиць. Для MyISAM вам може знадобитися використовувати --lock-tables, що ненадовго заблокує таблиці.
rsync -avz --delete-excluded ...:

-a: Режим архівування (зберігає дозволи, власність, мітки часу, рекурсивно).
-v: Детальний вивід.
-z: Стискає дані файлів під час передачі.
--delete-excluded: Видаляє файли на стороні отримувача, які виключені з передачі. Використовуйте з обережністю.
--exclude: Вказує шаблони файлів/каталогів, які потрібно виключити з передачі.
--log-file: Направляє вивід rsync у вказаний файл журналу.

Обробка помилок: Блоки || { ...; exit 1; } гарантують, що скрипт завершить роботу, якщо критичний крок не вдасться.

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


sudo chmod +x /usr/local/bin/backup_script.sh

Крок 3: Заплануйте за допомогою cron

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

Відредагуйте таблицю cron для користувача root (або виділеного користувача резервного копіювання):


sudo crontab -e

Додайте наступний рядок, щоб запускати скрипт щодня о 2:00 ранку:


0 2 * * * /usr/local/bin/backup_script.sh > /dev/null 2>&1

Пояснення запису cron:

0: Хвилина (0-59)
2: Година (0-23)
*: День місяця (1-31)
*: Місяць (1-12)
*: День тижня (0-7, 0 або 7 – неділя)
/usr/local/bin/backup_script.sh: Шлях до вашого скрипта резервного копіювання.
> /dev/null 2>&1: Перенаправляє стандартний вивід та стандартну помилку до /dev/null, щоб запобігти надмірним сповіщенням електронною поштою від cron. Сам скрипт реєструє дані у /var/log/backup_script.log.

Крок 4: Протестуйте свою резервну копію

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


sudo /usr/local/bin/backup_script.sh

Перевірте файл журналу на наявність успіхів або помилок:


cat /var/log/backup_script.log

Переконайтеся, що файли з'явилися на вашому віддаленому сервері резервного копіювання:


ssh [email protected] 'ls -l /backups/myserver'

Важливо, імітуйте відновлення: Скопіюйте файл резервної копії назад на ваш основний сервер (або тестовий сервер) і спробуйте витягти/імпортувати його, щоб переконатися в його цілісності.

rocket_launch Швидкий вибір

Шукаєте сервер, який просто працює?

Valebyte VPS — NVMe, підтримка 24/7, розгортання за 60 секунд.

Переглянути тарифи VPS arrow_forward

Метод 2: Розширені резервні копії за допомогою Duplicity (зашифровані та інкрементальні)

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

Чому Duplicity?

Шифрування: Використовує GnuPG для шифрування архівів, забезпечуючи безпеку даних, навіть якщо місце призначення резервної копії скомпрометовано.
Інкрементальні резервні копії: Передає лише зміни з моменту останньої повної резервної копії, заощаджуючи пропускну здатність та сховище.
Різні бекенди: Підтримує FTP, SFTP, S3, WebDAV, локальні файли та багато іншого.
Ефективність пропускної здатності: Стискає дані та надсилає лише змінені блоки.
Підписані резервні копії: Може підписувати маніфести резервних копій для перевірки цілісності.

Крок 1: Встановіть Duplicity

Duplicity зазвичай доступний у менеджері пакетів вашого дистрибутива.


# For Debian/Ubuntu
sudo apt update
sudo apt install duplicity python3-boto3 python3-paramiko

# For CentOS/RHEL
sudo yum install epel-release
sudo yum install duplicity python3-boto3 python3-paramiko

python3-boto3 призначений для підтримки S3, python3-paramiko – для підтримки SFTP.

Крок 2: Згенеруйте GPG-ключ (необов'язково, але рекомендовано)

Для зашифрованих резервних копій згенеруйте пару GPG-ключів. Вам знадобиться парольна фраза для резервного копіювання та відновлення.


gpg --full-generate-key

Дотримуйтесь підказок. Обов'язково виберіть надійну парольну фразу та запам'ятайте її!

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

Давайте створимо скрипт для резервного копіювання /var/www/html до S3-сумісного бакету. Вам знадобляться ключ доступу S3 та секретний ключ.

Створіть файл з назвою /usr/local/bin/duplicity_backup.sh:


#!/bin/bash

# --- Configuration --- #
SOURCE_DIR="/var/www/html"
TARGET_URL="s3://s3.your-s3-provider.com/your-bucket-name/yourserver-backups"
# Alternatively for SFTP:
# TARGET_URL="sftp://[email protected]//backups/myserver"

GPG_KEY_ID="YOUR_GPG_KEY_ID" # Found with 'gpg --list-keys'
PASSPHRASE="YOUR_GPG_PASSPHRASE"
AWS_ACCESS_KEY_ID="YOUR_AWS_ACCESS_KEY"
AWS_SECRET_ACCESS_KEY="YOUR_AWS_SECRET_KEY"

LOG_FILE="/var/log/duplicity_backup.log"

# --- Environment Variables (crucial for cron) --- #
export PASSPHRASE
export AWS_ACCESS_KEY_ID
export AWS_SECRET_ACCESS_KEY

# --- Perform Full Backup (e.g., monthly) or Incremental (daily) --- #
# Determine if it's the first day of the month for a full backup
if [ "$(date +%d)" = "01" ]; then
    echo "$(date): Performing full Duplicity backup..." >> $LOG_FILE
    duplicity full \\
        --log-file "$LOG_FILE" \\
        --encrypt-key "$GPG_KEY_ID" \\
        --full-if-older-than 1M \\
        --exclude "${SOURCE_DIR}/cache" \\
        --exclude "${SOURCE_DIR}/tmp" \\
        "$SOURCE_DIR" "$TARGET_URL" \\
        || { echo "$(date): Full backup failed." >> $LOG_FILE; exit 1; }
else
    echo "$(date): Performing incremental Duplicity backup..." >> $LOG_FILE
    duplicity incr \\
        --log-file "$LOG_FILE" \\
        --encrypt-key "$GPG_KEY_ID" \\
        --exclude "${SOURCE_DIR}/cache" \\
        --exclude "${SOURCE_DIR}/tmp" \\
        "$SOURCE_DIR" "$TARGET_URL" \\
        || { echo "$(date): Incremental backup failed." >> $LOG_FILE; exit 1; }
fi

# --- Clean up old backups (e.g., keep 3 months) --- #
echo "$(date): Cleaning up old backups..." >> $LOG_FILE
duplicity remove-older-than 3M --force "$TARGET_URL" \\
    || { echo "$(date): Cleanup failed." >> $LOG_FILE; exit 1; }

echo "$(date): Duplicity backup and cleanup completed successfully." >> $LOG_FILE
exit 0

Важлива примітка щодо безпеки: Зберігання конфіденційних облікових даних (таких як парольні фрази GPG або секретні ключі S3) безпосередньо у скрипті, як правило, не рекомендується для середовищ з високими вимогами до безпеки. Для виробництва розгляньте можливість використання агента GPG, змінних середовища, керованих безпечним менеджером секретів, або читання парольних фраз з обмеженого файлу. Для цілей цього посібника ми розміщуємо їх безпосередньо для ясності, але пам'ятайте про наслідки.

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


sudo chmod +x /usr/local/bin/duplicity_backup.sh

Крок 4: Заплануйте за допомогою cron

Відредагуйте таблицю cron:


sudo crontab -e

Додайте наступний рядок, щоб запускати скрипт Duplicity щодня о 3:00 ранку:


0 3 * * * /usr/local/bin/duplicity_backup.sh > /dev/null 2>&1

Крок 5: Відновлення даних за допомогою Duplicity

Щоб відновити дані, вам знадобиться доступ до вашого приватного ключа GPG та парольної фрази. Припустимо, ви хочете відновити дані до тимчасового каталогу:


# Export passphrase (replace with your actual passphrase)
export PASSPHRASE="YOUR_GPG_PASSPHRASE"
export AWS_ACCESS_KEY_ID="YOUR_AWS_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_AWS_SECRET_KEY"

# List available backups
duplicity collection-status --log-file /tmp/duplicity_restore.log "$TARGET_URL"

# Restore to a specific point in time (e.g., 1 day ago) or the latest backup
# To restore latest:
duplicity restore "$TARGET_URL" /tmp/restored_data

# To restore from 1 day ago:
duplicity -t 1D restore "$TARGET_URL" /tmp/restored_data

# To restore a specific file/directory:
duplicity restore --file-to-restore path/to/specific/file.txt "$TARGET_URL" /tmp/restored_file

Завжди спочатку тестуйте процес відновлення в не виробничому середовищі!

Найкращі практики для резервного копіювання виділеного сервера

Крім технічної реалізації, надійна стратегія резервного копіювання дотримується кількох ключових принципів:

1. Правило резервного копіювання 3-2-1

Цей галузевий стандарт забезпечує максимальну стійкість даних:

3 копії ваших даних: Оригінальні дані + щонайменше дві резервні копії.
2 різні типи носіїв: Зберігайте резервні копії на різних типах сховищ (наприклад, локальний диск та хмарне сховище, або два різні віддалені сервери).
1 копія за межами сайту: Щонайменше одна копія повинна зберігатися географічно окремо від вашого основного центру обробки даних. Це захищає від катастроф, специфічних для сайту (пожежа, повінь, відключення електроенергії). Виділені сервери Valebyte забезпечують міцну основу для ваших основних даних, і ви повинні використовувати сховище за межами сайту для ваших резервних копій.

2. Резервні копії за межами сайту є обов'язковими

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

3. Шифруйте свої резервні копії

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

4. Впроваджуйте моніторинг та сповіщення

Не припускайте, що ваші резервні копії працюють. Налаштуйте моніторинг, щоб переконатися, що завдання резервного копіювання успішно завершуються. Такі інструменти, як Nagios, Zabbix, або прості сповіщення електронною поштою від ваших завдань cron можуть повідомляти вас про збої, дозволяючи оперативно вирішувати проблеми.

5. Регулярно тестуйте процес відновлення

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

6. Плануйте на години низького навантаження

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

7. Політики версіонування та зберігання

Визначте чітку політику зберігання (як довго зберігати резервні копії) та стратегію версіонування (скільки історичних версій зберігати). Це запобігає заповненню вашого сховища резервних копій та дозволяє відновлювати дані з різних моментів часу.

8. Послідовне резервне копіювання бази даних

Для баз даних завжди використовуйте спеціальні інструменти, такі як mysqldump або pg_dump з відповідними прапорами (наприклад, --single-transaction для InnoDB), щоб забезпечити послідовний, не пошкоджений знімок ваших даних.

Усунення поширених проблем з резервним копіюванням

Навіть при ретельному плануванні можуть виникнути проблеми. Ось деякі поширені проблеми та їх вирішення:

1. Вичерпання дискового простору

Симптом: Резервні копії не вдаються з помилками "Немає місця на пристрої".
Рішення:

Перевірте вільне місце на джерелі (проміжне сховище) та місці призначення. df -h.
Скоригуйте свою політику зберігання, щоб зберігати менше старих резервних копій.
Збільште обсяг сховища на місці призначення резервної копії.
Перегляньте обсяг резервного копіювання; чи створюєте ви резервні копії непотрібних файлів?

2. Помилки дозволів

Симптом: Скрипт не може читати файли, записувати в каталоги або виконувати команди.
Рішення:

Переконайтеся, що користувач, який запускає завдання cron (зазвичай root або виділений користувач резервного копіювання), має дозволи на читання для всіх файлів/каталогів, які потрібно резервувати, та дозволи на запис для проміжного сховища та каталогів журналів.
Для віддалених резервних копій перевірте дозволи SSH-ключа (chmod 600 ~/.ssh/id_rsa) та правильну власність.

3. Проблеми з мережевим підключенням

Симптом: Віддалені передачі не вдаються, SSH-з'єднання перериваються за часом.
Рішення:

Перевірте підключення вручну: ping remote.host.com, ssh [email protected].
Перевірте правила брандмауера на обох серверах, джерелі та місці призначення.
Переконайтеся, що ваш віддалений сервер резервного копіювання працює та доступний.

4. Завдання Cron не запускається

Симптом: Резервні копії не створюються, відсутні записи в журналах.
Рішення:

Перевірте журнали cron: grep CRON /var/log/syslog (або /var/log/cron у системах на базі RHEL).
Переконайтеся, що шлях до скрипта в crontab є абсолютним та правильним.
Перевірте, чи має скрипт дозволи на виконання (chmod +x).
Перевірте змінні середовища в завданні cron. Cron запускається з мінімальним середовищем, тому явно визначте шляхи або експортуйте змінні, такі як PATH, AWS_ACCESS_KEY_ID тощо, у вашому скрипті.

5. Блокування бази даних/непослідовні резервні копії

Симптом: Резервні копії бази даних пошкоджені або неповні.
Рішення:

Використовуйте mysqldump --single-transaction для таблиць InnoDB.
Розгляньте можливість короткочасного зупинення служби бази даних, якщо послідовні резервні копії є критично важливими, а час простою є прийнятним (рідко для автоматизованих сценаріїв).
Для дуже великих баз даних розгляньте логічну реплікацію або спеціалізовані інструменти резервного копіювання для вашої конкретної системи баз даних.

6. Неповні резервні копії Duplicity

Симптом: Duplicity не вдається або повідомляє про помилки, резервні копії виглядають неповними.
Рішення:

Перевірте файл журналу Duplicity на наявність детальних помилок.
Переконайтеся, що ідентифікатор GPG-ключа та парольна фраза правильні та доступні.
Переконайтеся, що облікові дані AWS/S3 та URL-адреса кінцевої точки правильні.
Запустіть duplicity collection-status , щоб перевірити стан вашого ланцюжка резервних копій.
Якщо ланцюжок резервних копій пошкоджений, вам може знадобитися розпочати нове повне резервне копіювання після видалення старого ланцюжка.