Бэкап с шифрованием на сервере: частые ошибки и решения

MAATRIX

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

Потерян пароль от репозитория

Самая непоправимая ошибка: вам нужно восстановить данные, а пароль от зашифрованного репозитория утерян. В отличие от многих проблем, эту нельзя решить технически — шифрование restic и borg надёжное, и без пароля репозиторий не открывается никаким инструментом. Данные фактически потеряны, хотя физически файлы бэкапа целы.

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

restic key list
restic key add

Restic позволяет иметь несколько ключей к одному репозиторию — командой key add можно добавить запасной пароль, пока у вас есть доступ. Сделайте это заранее и храните ключи в разных местах. Если доступ ещё есть, а пароль вы боитесь забыть, добавьте второй ключ прямо сейчас — потом будет поздно.

Бэкап не восстанавливается, хотя копии делались

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

Проверьте целостность репозитория и содержимое снимков.

restic check
restic snapshots
restic ls latest

Команда check проверяет целостность репозитория, snapshots показывает список копий, а ls latest — что реально лежит в последнем снимке. Если копий меньше, чем ожидалось, или в них нет нужных каталогов, значит, бэкап работал не так, как вы думали. Отдельная частая беда — бэкап файлов активной базы данных без дампа: файлы копируются в несогласованном состоянии и не восстанавливаются в рабочую базу. Всегда делайте дамп через mysqldump или pg_dump и бэкапьте его. И главное правило: регулярно проводите тестовое восстановление в отдельный каталог, только оно доказывает, что бэкап рабочий.

Репозиторий заблокирован

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

Проверьте блокировки и снимите их, если вы уверены, что никакая операция сейчас не идёт.

restic list locks
restic unlock

Команда unlock снимает устаревшие блокировки. Важно убедиться, что действительно нет активного процесса бэкапа, иначе вы можете снять блокировку у работающей операции. Если бэкапы запускаются по расписанию, проверьте, что предыдущий не завис — иногда причина блокировки в том, что новый запуск стартовал, пока старый ещё шёл. В таком случае увеличьте интервал между бэкапами или добавьте в скрипт защиту от параллельного запуска, чтобы копии не наступали друг на друга.

Закончилось место в хранилище

Бэкап падает с ошибкой нехватки места, и новые копии не создаются. Причина обычно в отсутствии ротации: без политики хранения репозиторий растёт бесконечно, накапливая все копии за всю историю. Даже с дедупликацией место рано или поздно заканчивается. Проверьте размер репозитория и наличие ротации.

df -h /mnt/backup
restic stats

Решение — настроить ротацию через forget с политикой хранения и prune для физического освобождения места. Например, держать несколько ежедневных, еженедельных и ежемесячных копий, удаляя лишние.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Флаг prune обязателен: без него forget лишь помечает копии как ненужные, но место не освобождает. Запускайте ротацию как часть скрипта бэкапа, чтобы место контролировалось автоматически. Если репозиторий уже переполнен настолько, что даже prune не проходит, освободите место вручную или временно расширьте хранилище, проведите ротацию и впредь держите её в скрипте. Планируйте объём хранилища с запасом на историю копий, а не только на один снимок.

Бэкап лежит рядом с данными и гибнет вместе с ними

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

Проверьте, где физически лежит ваш репозиторий.

echo $RESTIC_REPOSITORY
df -h

Если путь ведёт на тот же диск или сервер, что и данные, — это критическая уязвимость. Перенесите репозиторий на отдельное хранилище: другой сервер по SSH, объектное хранилище S3 или совместимое, желательно в другой локации. Restic отправляет туда уже зашифрованные данные, поэтому хранилищу не нужно доверять содержимое. Правило трёх копий гласит: держите данные минимум в трёх экземплярах, на двух разных носителях, и одну копию — вне основной площадки. Для сервера это означает как минимум одну копию на независимом удалённом хранилище. Именно географическое и физическое разнесение отличает настоящий бэкап от иллюзии. Взять отдельный VPS под хранилище копий в другой локации удобно у MAATRIX с оплатой из России картой, СБП или криптой.

Восстановление идёт слишком долго или прерывается

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

Restic позволяет восстанавливать выборочно, что часто быстрее и практичнее.

restic restore latest --target /tmp/restore --include /etc/nginx

Параметр include извлекает только нужную часть, экономя время. Для полного восстановления по нестабильному каналу запускайте процесс в устойчивой к обрывам сессии, например через tmux, чтобы разрыв SSH не прервал восстановление. И заранее оценивайте время восстановления как часть плана: если критичные данные восстанавливаются сутки, это может не устроить бизнес, и тогда стоит держать более быстрое хранилище ближе к серверу. Скорость восстановления — такая же характеристика бэкапа, как и его наличие, и её тоже нужно проверять заранее.

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