Почему вторая работающая копия базы не всегда спасает от случайного удаления и чем резервное копирование дополняет репликацию. Без сложных настроек.
Две копии — не всегда две защиты
Представим условный сервис записи на занятия. Его данные хранятся на основном сервере, а изменения передаются на второй. Если основной сервер перестал работать, запасная система может помочь продолжить обслуживание. Но если сотрудник ошибочно удалил нужные записи, удаление тоже может попасть на второй сервер.
Число копий само по себе не отвечает на вопрос, от чего защищена система. Нужно различать сохранение актуального состояния и возможность вернуться к прежнему. Здесь встречаются два понятия: репликация и резервное копирование. Их часто используют вместе, потому что они решают разные части задачи надёжности.
Реплика поддерживает другое рабочее состояние данных
Репликация передаёт изменения между экземплярами данных. Один из её сценариев — поддерживать запасной сервер, который можно использовать при сбое основного. Некоторые решения также позволяют распределять чтение, но возможности зависят от конкретной системы и её настроек.
В документации PostgreSQL описаны резервные серверы и различия синхронной и асинхронной передачи. При асинхронной работе запасной экземпляр может отставать. Поэтому наличие реплики не даёт универсальной гарантии, что при переключении сохранится каждое последнее изменение. Условия нужно проверять для выбранной архитектуры, а не выводить из слова «репликация».
Источник: PostgreSQL: резервные серверы и репликация.
Резервная копия помогает восстановить прежние данные
Резервное копирование сохраняет данные для восстановления. Важен не только сам файл копии, но и то, к какому состоянию он позволяет вернуться, где хранится и можно ли его прочитать. PostgreSQL описывает несколько подходов к резервному копированию; выбор зависит от требований и устройства системы.
Вернёмся к условной записи на занятия. Если удаление обнаружили после того, как оно распространилось на реплику, может потребоваться сохранённое состояние до ошибки. При этом восстановление не означает бездумную замену всей рабочей базы: после выбранного момента могли появиться корректные новые записи. Команда должна продумать, какие данные возвращать и как проверить результат.
Источник: PostgreSQL: резервное копирование и восстановление.
Почему один механизм не заменяет другой
Microsoft в руководстве по надёжности прямо разделяет задачи репликации и резервного копирования. Репликация полезна для доступности, но может переносить нежелательные изменения. Резервные копии дают дополнительные варианты восстановления, однако возвращение системы из копии занимает время и требует подготовленного процесса.
Представьте два условных события. При отказе оборудования актуальная реплика помогает сократить перерыв. При обнаруженной позднее ошибке в данных важна сохранённая история, до которой ошибка ещё не дошла. В обоих случаях итог зависит от настроек, доступности копий и действий команды. Нельзя обещать, что один продукт автоматически закрывает все сценарии.
Источник: Microsoft: репликация и резервные копии.
Какие вопросы задать до выбора решения
Начните не с названия технологии, а с требований. Как долго сервис может быть недоступен? Какой промежуток последних изменений допустимо потерять? Через какое время обычно замечают ошибку? Кто будет принимать решение о восстановлении? Ответы помогают понять, нужна ли актуальная запасная система, сколько истории хранить и как проверять готовность.
Часто используют два показателя: допустимое время восстановления и допустимую глубину потери последних данных. Это цели планирования, а не свойства, которые появляются после покупки сервера. Например, если копии делают раз в сутки, нужно отдельно разобраться, откуда взять изменения после последней копии. Одной красивой цифры в описании услуги недостаточно.
Проверять нужно восстановление, а не наличие файла
Для условной небольшой команды полезно провести согласованную учебную проверку в отдельной безопасной среде: найти нужную копию, восстановить её и проверить несколько важных связей и итогов. Сам факт завершения копирования не показывает, что все необходимые данные доступны и команда умеет вернуть работоспособность.
Зафиксируйте, кто отвечает за копии, какие сценарии проверены и что осталось неизвестным. Сведения о доступе и восстановлении должны быть доступны ответственным людям, а не храниться только в памяти одного специалиста. Для архитектора данных это часть проектирования системы: продумать не только обычную работу, но и понятный путь действий, когда оборудование или данные подвели.
Читайте также
Следующий шаг
Если хотите изучить направление системно, посмотрите программу «Архитектор данных» в NovaData. Сопоставьте темы курса со своими задачами и уровнем подготовки.
