Hosting & Servers

Резервное копирование

Создание и хранение копий данных, из которых можно восстановиться после удаления, поломки, шифровальщика или отказа оборудования.

Что такое резервное копирование

Резервное копирование (англ. backup, в разговоре «бэкап» или «бекап») — регулярное создание копий данных и хранение их отдельно от оригинала, чтобы восстановиться после потери. Резервная копия — это сам такой снимок данных на определённый момент времени.

Ключевое слово здесь — отдельно. Копия, лежащая рядом с оригиналом на том же сервере, спасает ровно от одного сценария: «случайно удалил файл». От отказа диска, шифровальщика, пожара в зале или удаления аккаунта у провайдера она не спасает, потому что уходит вместе с оригиналом.

Что бэкапом не является

Три вещи, которые регулярно принимают за резервное копирование:

  • RAID защищает от отказа диска — и только. Команда rm -rf, шифровальщик или повреждение файловой системы честно и мгновенно повторятся на всех дисках массива.
  • Репликация защищает от отказа сервера. DROP TABLE доедет до реплики за миллисекунды — она для того и сделана.
  • Snapshot — точка отката за секунды, но живёт на том же хранилище и зависит от исходного тома. Удалили том, развалился массив, потеряли доступ к аккаунту — снапшоты ушли следом.

Все три полезны и решают свои задачи. Ни одна из них не является резервной копией.

Правило 3-2-1

Классический ориентир, к которому сводится любая вменяемая схема: 3 копии данных (оригинал плюс две), на 2 разных типах носителей или в двух разных системах, 1 — за пределами площадки. Расширенный вариант 3-2-1-1-0 добавляет ещё две цифры: 1 копия неизменяемая или офлайновая и 0 ошибок при проверке восстановления.

Пункт про офлайн появился из-за шифровальщиков: они целенаправленно ищут и удаляют бэкапы перед шифрованием, а копия, которую нельзя переписать даже из-под root, ломает им сценарий. Технически это делается через WORM-репозиторий или Object Lock в объектном хранилище.

Полный, инкрементальный, дифференциальный

Тип Что копирует Объём и окно Что нужно для восстановления
Полный (full) все данные целиком максимум только сам полный бэкап
Инкрементальный изменения с прошлого бэкапа любого типа минимум полный + вся цепочка инкрементов
Дифференциальный изменения с последнего полного средний полный + последний дифференциальный

Компромисс всегда один и тот же: чем меньше вы копируете, тем дольше и рискованнее восстанавливаетесь. Инкременты экономят место и время бэкапа, но обрыв в середине цепочки обесценивает всё, что после него. Типичная рабочая схема — полный раз в неделю, инкременты ежедневно, и хранение по схеме «дед-отец-сын»: несколько дней, несколько недель, несколько месяцев.

RPO и RTO

Два числа задают всю схему. RPO — сколько данных допустимо потерять; отсюда частота копий: бэкап раз в сутки означает готовность потерять день работы. RTO — сколько времени допустимо восстанавливаться; отсюда способ хранения: копия в холодном хранилище дешёвая, но её ещё надо оттуда достать. Дальше оба ведут к Disaster Recovery, частью которого бэкап и является.

Чем делать

Файлы и серверы: restic, BorgBackup, rsync для простых задач, Veeam и его аналоги для виртуальных машин на уровне образа.

export RESTIC_REPOSITORY="s3:https://s3.example.com/backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic backup /var/www /etc --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%      # проверить целостность части данных
restic restore latest --target /restore

Базы данных нельзя копировать как обычные файлы «на живую» — получите набор битых страниц. Нужен либо логический дамп, либо снятие копии средствами самой СУБД:

# PostgreSQL: дамп сразу в репозиторий, без временного файла на диске
pg_dump -Fc mydb | restic backup --stdin --stdin-filename mydb.dump

Непроверенный бэкап — не бэкап

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

Минимум: мониторинг результата заданий (не «письмо об успехе», а алерт на его отсутствие), автоматическая проверка целостности и регулярное тестовое восстановление на отдельной машине. Отдельно проверьте, что ключи шифрования и пароль от репозитория хранятся не только внутри того сервера, который вы собираетесь восстанавливать.

Связанные термины

  • snapshot — быстрый откат, но не резервная копия
  • Disaster Recovery — восстановление сервиса целиком, где бэкап лишь звено
  • Veeam — бэкап виртуальных машин на уровне образа
  • Дамп базы данных — как правильно копировать СУБД
  • Репликация — отказоустойчивость, которую путают с бэкапом
  • object storage — где обычно живёт копия вне площадки

Готовы запустить GPU-задачу?

Запустить GPU-сервер