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

Данные теряют по-разному

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

Отказ железа: умер диск, сгорел контроллер, отключилось питание в стойке.

Ошибка человека: DROP TABLE не в той консоли, rm -rf не в той папке, миграция, которая снесла половину строк.

Ошибка программы: баг в приложении месяц тихо портил данные, а заметили это вчера.

Злой умысел: шифровальщик прошёл по сети и зашифровал всё, до чего дотянулся, включая сетевые папки с копиями.

Потеря площадки: пожар, затопление, изъятие оборудования, отключение аккаунта у облачного провайдера.

Дальше по этому списку и проверяем механизмы, которые часто принимают за бэкап.

RAID: защита от одного диска

RAID держит данные на нескольких дисках так, чтобы смерть одного (иногда двух) не остановила работу. Это защита доступности, и работает она ровно против первого сценария.

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

Про RAID подробнее в отдельном уроке трека, там же про то, почему ребилд большого массива это отдельный риск.

Репликация: защита от узла

Реплика это вторая база (или второй сервер), куда изменения приезжают непрерывно. Умер основной узел — переключились на реплику, потеряв секунды.

Проблема та же: репликация повторяет все изменения, включая ошибочные. DELETE FROM orders без WHERE доедет до реплики за миллисекунды. Асинхронная реплика даёт крошечное окно, но рассчитывать на то, что вы успеете её отцепить, несерьёзно.

Есть и промежуточный вариант: отложенная реплика. В Postgres за это отвечает recovery_min_apply_delay, в MySQL MASTER_DELAY. Реплика держится, скажем, на час позади, и этот час у вас есть, чтобы заметить ошибочный запрос и снять данные до того, как он повторится.

Репликация закрывает отказ узла и частично отказ площадки. От человека и от шифровальщика она не спасает.

Снапшот: точка отката, но рядом с данными

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

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

Общее у них другое: и те и другие удаляются теми же правами, что и данные. Удаление теневых копий и снапшотов — задокументированный приём шифровальщиков, у него даже есть свой номер в матрице MITRE ATT&CK (T1490, Inhibit System Recovery).

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

Что тогда бэкап

Бэкап это отдельная копия данных, которая:

• лежит не там, где оригинал, и в идеале управляется другой системой;
• не изменяется задним числом, а хранится версиями за прошлые дни;
• проверена восстановлением, а не просто существует.

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

Механизмы из этого урока не конкуренты бэкапу, а слои. Реплика держит сервис живым при отказе узла, снапшот отматывает неудачную миграцию за минуту, а бэкап остаётся последней линией, когда не сработало ничего.

Типичная связка на боевом сервисе

Реплика Postgres в другой зоне доступности: отказ узла стоит десятков секунд на переключение вместо часов простоя.

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

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

Раз в квартал развёртывание из бэкапа на тестовом сервере: доказательство, что всё это работает.

Что важно запомнить

RAID защищает от смерти диска и ни от чего больше: удаление и шифрование приезжают на все диски массива одинаково.

Репликация повторяет ошибки вместе с данными, поэтому от DROP TABLE она не страхует.

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

Бэкап это отдельная копия в другом месте, с историей версий и проверенным восстановлением.

Дальше разберём два числа, из которых вырастает вся схема бэкапов: RPO и RTO.