Настройте автоматические бэкапы на вашем выделенном сервере

Почему автоматизированные резервные копии критически важны для вашего выделенного сервера

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

Типичные сценарии, когда резервное копирование спасает положение:

Отказ оборудования: Даже самое надежное оборудование может выйти из строя. Сбой диска может мгновенно уничтожить годы работы.
Повреждение программного обеспечения: Неудачные обновления ОС, ошибки приложений или неправильные настройки могут сделать ваш сервер непригодным для использования.
Человеческая ошибка: Случайное удаление критически важных файлов или неправильное выполнение команды является основной причиной потери данных.
Нарушения безопасности: Атаки программ-вымогателей или вредоносные вторжения могут зашифровать или удалить ваши данные. Резервные копии обеспечивают чистый лист для восстановления.
Соответствие требованиям и аудит: Многие отрасли требуют соблюдения определенных политик хранения данных, что делает автоматизированное, проверяемое резервное копирование крайне важным.

Реальные сценарии использования резервного копирования выделенного сервера:

Веб-хостинг: Защита клиентских веб-сайтов, баз данных и файлов приложений от случайного удаления или вредоносных атак.
Игровые серверы: Защита данных игроков, файлов миров и конфигураций серверов для популярных многопользовательских игр.
Базы данных: Обеспечение целостности транзакций и восстановления на определенный момент времени для MySQL, PostgreSQL, MongoDB и других систем баз данных.
Почтовые серверы: Сохранение критически важных архивов электронной почты, учетных записей пользователей и конфигураций сервера.
Стриминговые сервисы: Резервное копирование медиатек, профилей пользователей и конфигураций доставки контента.
Конвейеры CI/CD: Хранение артефактов сборки, репозиториев исходного кода и критически важных файлов конфигурации для сред разработки.
Виртуализация: Резервное копирование образов ВМ и конфигураций, если вы используете собственный гипервизор на сервере без посредников (bare-metal).

Предварительные условия и планирование стратегии резервного копирования

Прежде чем приступать к технической настройке, крайне важен хорошо продуманный план. Учитывайте следующие факторы:

1. Требования к серверу

Дисковое пространство: Убедитесь, что на вашем выделенном сервере достаточно свободного места для временных файлов резервных копий, особенно если вы выполняете локальное резервное копирование перед передачей за пределы площадки. Для выделенных серверов Valebyte вы часто можете выбрать конфигурации с достаточным объемом хранилища или добавить дополнительные диски.
Сетевое подключение: Высокоскоростное сетевое подключение критически важно для эффективной передачи данных за пределы площадки, особенно для больших наборов данных. Надежная сетевая инфраструктура Valebyte гарантирует быструю и надежную передачу ваших резервных копий.
ЦП и ОЗУ: Хотя это не является основной проблемой для простого резервного копирования файлов, такие задачи, как дампы баз данных, сжатие и шифрование, могут быть интенсивными для ЦП и ОЗУ. Планируйте их выполнение в непиковые часы или убедитесь, что ваш сервер имеет достаточные ресурсы.

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 месяцев.
Дед-Отец-Сын (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. Планируйте в непиковые часы

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

7. Политики версионирования и хранения

Определите четкую политику хранения (как долго хранить резервные копии) и стратегию версионирования (сколько исторических версий хранить). Это предотвращает заполнение вашего хранилища резервных копий и позволяет восстанавливаться из разных моментов времени.

8. Последовательное резервное копирование базы данных

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

Устранение распространенных проблем с резервным копированием

Даже при тщательном планировании могут возникнуть проблемы. Вот некоторые распространенные проблемы и их решения:

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

Симптом: Резервные копии завершаются с ошибками "No space left on device" (Нет места на устройстве).
Решение:

Проверьте свободное место на источнике (промежуточном хранилище) и в месте назначения. 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 , чтобы проверить состояние вашей цепочки резервных копий.
Если цепочка резервных копий повреждена, вам может потребоваться начать новое полное резервное копирование после удаления старой цепочки.