Резервное копирование БД на сервере: частые ошибки и решения

MAATRIX

Резервное копирование БД на сервере опасно тем, что его ошибки не видны до момента восстановления — а тогда уже поздно. Ниже — разбор частых проблем: бэкап тихо падает, а никто не знает; копии оказываются битыми или неполными; диск переполняется самими копиями; потерян ключ шифрования; восстановление проваливается в самый нужный момент. Для каждой сначала решение, потом причина — чтобы ваши бэкапы реально спасали данные, а не создавали ложное чувство защищённости.

Бэкап молча падает, а никто не знает

Самая коварная ошибка: скрипт бэкапа однажды сломался, а вы узнали об этом только при попытке восстановиться. Причины бывают разные — сменился пароль базы, кончилось место, отвалилось удалённое хранилище, обновилась утилита. Объединяет их одно: без оповещений провал остаётся невидимым. Решение — сделать так, чтобы скрипт всегда сигнализировал о результате.

Заставьте скрипт останавливаться на любой ошибке и сообщать о ней:

#!/bin/bash
set -euo pipefail
trap 'echo "BACKUP FAILED at $(date)"; /usr/local/bin/notify.sh "Бэкап упал"; exit 1' ERR
pg_dump -Fc appdb > /var/backups/appdb.dump

Конструкция set -euo pipefail прерывает скрипт при первой ошибке, а trap ... ERR отправляет оповещение. Настройте уведомление в мессенджер или на почту — и об успехе, и о провале. Отсутствие сообщения об успехе тоже должно настораживать: молчание может означать, что скрипт вообще не запустился. Мониторинг «свежести» последней копии (не старше суток) — надёжный способ поймать тихий провал.

Копия оказалась битой или неполной

Файл бэкапа есть, но восстановление сыплет ошибками или архив не распаковывается. Частая причина — бэкап оборвался из-за нехватки места или сетевого сбоя, а скрипт этого не заметил. При использовании конвейера с gzip особенно легко пропустить ошибку: код возврата берётся от последней команды в конвейере, а не от той, что реально упала.

Проверяйте код возврата именно утилиты бэкапа и целостность архива:

pg_dump -Fc appdb > appdb.dump && pg_restore --list appdb.dump > /dev/null && echo "OK"

Команда pg_restore --list читает дамп и выводит его оглавление — если файл битый, она упадёт, и вы сразу это увидите. Для сжатых файлов используйте проверку архива через gzip -t. Вторая причина неполноты — забытые объекты: для MySQL это процедуры и триггеры без флагов --routines --triggers, для любой СУБД — пользователи и права, которые дамп одной базы обычно не содержит. Планируя бэкап, всегда спрашивайте: что ещё, кроме таблиц, нужно для полного восстановления рабочей системы?

Диск переполнился из-за бэкапов

Копии копятся день за днём и в итоге забивают диск, роняя заодно и саму базу, которой некуда писать. Классическая причина — нет ротации, старые копии никто не удаляет. Настройте автоматическое удаление копий старше заданного срока:

find /var/backups/db -name "*.dump" -mtime +14 -delete

Эта строка держит копии за две недели. Вторая частая ошибка — хранить бэкапы в том же разделе, что и данные базы: тогда разросшиеся копии напрямую отнимают место у СУБД. Выносите копии на отдельный диск или, лучше, на другой сервер. И обязательно включите мониторинг свободного места с оповещением заранее — переполнение диска из-за бэкапов это обидная и полностью предотвратимая авария, которая к тому же тянет за собой падение продакшена.

Потерян ключ шифрования

Вы разумно зашифровали бэкапы, но при попытке восстановиться выяснилось, что ключ или пароль шифрования утерян. Зашифрованная копия без ключа — это просто мусор, восстановить из неё ничего нельзя. Это одна из самых обидных ситуаций: данные целы, но недоступны. Проблема почти всегда в организации хранения ключа.

Правило простое: ключ шифрования хранится отдельно от копий, но так, чтобы он гарантированно не потерялся. Плохо хранить ключ на том же сервере рядом с базой (утечёт вместе с ней) и плохо хранить только в одной голове или на одном ноутбуке (потеряется). Разумный путь — надёжный менеджер секретов или защищённое хранилище, доступное ответственным людям, плюс резервная запись в безопасном месте. И проверяйте расшифровку на учениях по восстановлению: если вы регулярно тестово восстанавливаете зашифрованный бэкап, потеря ключа обнаружится не в катастрофу, а на плановой проверке.

Восстановление проваливается в час аварии

Главная ошибка резервного копирования — вообще не проверять восстановление. Бэкап делается ради восстановления, а не ради самого файла, но именно восстановление тестируют реже всего. В результате в час аварии всплывает всё сразу: неполный дамп, несовместимость версий, кракозябры кодировки, нехватка места под разворачивание, забытые пользователи.

Единственное лекарство — регулярные учения. Раз в месяц разворачивайте свежую копию на тестовой базе или отдельном сервере и сверяйте: число строк в ключевых таблицах, наличие процедур и пользователей, читаемость текста, время разворачивания. Восстанавливайте всегда в чистую пустую базу, а не поверх существующей, и смотрите первую ошибку — обычно она корневая. Учения выявляют изъяны заранее, когда есть время спокойно их устранить, а не под давлением реальной потери данных. Полезно оформить восстановление как короткий чек-лист и хранить его рядом с доступами: где лежат копии, каким ключом расшифровать, какой командой развернуть, куда переключить приложение. В момент аварии, под стрессом, готовая инструкция экономит драгоценные минуты и снижает риск ошибки. Отдельно стоит договориться, кто именно отвечает за восстановление и имеет к нему доступ: бэкап, ключи к которому есть только у одного уехавшего в отпуск человека, — такая же уязвимость, как и его отсутствие. Резервное копирование это не разовая настройка, а живой процесс, который проверяют и поддерживают.

Надёжное восстановление требует места под разворачивание и, желательно, отдельного сервера под учения и удалённые копии. В MAATRIX можно арендовать VPS под базы и резервное хранилище в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не требуется.

Частые вопросы