Резервное копирование
Создание и хранение копий данных, из которых можно восстановиться после удаления, поломки, шифровальщика или отказа оборудования.
Что такое резервное копирование
Резервное копирование (англ. 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-сервер