Зеркалирование файлов и репликация базы: одно похоже на другое, но разница принципиальная

У нас сейчас несколько клиентов с одинаковой задачей: есть основной сервер с файлами и базой, и есть второй - резервный, запасной, «если что». Хочется, чтобы на нём было актуальное состояние. Запросы идут с разной степенью конкретности - от «сделайте чтобы всё само копировалось» до «нам нужна репликация, я слышал такое слово». Садимся, разбираемся, настраиваем.

Заодно выясняется, что слова «зеркало», «синхронизация», «репликация» и «бэкап» в голове клиента нередко означают одно и то же. Это не их вина - они звучат похоже и все отвечают на вопрос «а если что-то случится». Но за каждым стоит своя механика, и от этой механики зависит, что именно вас спасёт.

Зеркалирование файлов по расписанию

Самый распространённый запрос - синхронизировать папку с рабочими документами на второй сервер. Подход понятный: каждые несколько часов (или ночью) запускается задача, которая смотрит что изменилось, и переносит новое и изменённое на резервный сервер.

Инструментов под Windows хватает. Мы чаще используем Robocopy, он входит в Resource Kit и делает именно это: читает источник, сравнивает с целью, копирует разницу. Запускается через Планировщик задач, пишет лог. Ключи нужно подобрать аккуратно - особенно /MIR, зеркальный режим.

И вот тут первая ловушка, на которую мы уже несколько раз наступали вместе с клиентами.

/MIR - это полное зеркало. Оно не просто копирует новое. Оно приводит цель в точное соответствие с источником - включая удаление того, чего в источнике больше нет. Удалили папку на основном сервере? Следующий прогон Robocopy с /MIR удалит её и на резервном. Аккуратно, без предупреждений, по делу. Это не ошибка программы - это именно то, что написано в документации.

Клиент, который думал что зеркало - это страховка от случайного удаления, после этого открытия испытывает определённое разочарование.

Без /MIR - то есть в режиме простого копирования новых и изменённых файлов - удалённое не трогается. Но тогда на резервном сервере накапливается мусор: всё что когда-либо существовало на основном, никуда не девается. Через год там будет свалка.

Выход простой, но требует осознанного выбора:

• Если нужно актуальное состояние (развернуть резервный вместо основного в случае аварии) - /MIR, и смиряемся с тем, что удаления синхронизируются тоже.
• Если нужна история - это уже не зеркало, а бэкап с ротацией. Другая задача, другой инструмент.
• Если нужно и то, и другое - зеркало плюс отдельный бэкап с историей. Совмещать одним инструментом не получится.

Репликация базы данных

Отдельная история с базами. Тут всё немного иначе, потому что файловая синхронизация с базой не работает нормально: файл базы заблокирован, запущен, постоянно меняется. Копировать его Robocopy - значит получить либо ошибку, либо несогласованный снапшот.

Microsoft SQL Server 2000 умеет репликацию нативно, и это то, что раньше было уделом больших систем, а сейчас вполне доступно. Настраивается через мастер в Enterprise Manager, разобраться можно за день. Есть несколько режимов, нам в большинстве случаев подходит snapshot replication или transactional replication - зависит от того, как часто данные меняются и насколько резервный сервер должен быть актуальным.

Transactional replication - изменения с основного сервера уходят на резервный практически в реальном времени, через Log Reader Agent. Красиво, но требует внимания: если между серверами что-то встало, накапливается очередь, и при восстановлении связи она раскатывается.

Snapshot replication проще: раз в сколько-то времени полный снапшот копируется на подписчика. Задержка больше, зато меньше проблем с синхронизацией при обрывах.

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

Поэтому репликация не отменяет регулярный дамп базы с хранением истории. Это разные вещи.

Что у нас получается на практике

Когда клиент говорит «хочу чтобы был резервный сервер», мы сначала выясняем что именно:

Первое - переключиться быстро при аварии. Тут нужно зеркало файлов плюс репликация базы. Резервный сервер содержит актуальное состояние, в случае падения основного - переключаем пользователей туда. Удобно, но помним: если авария связана с порчей данных, а не с железом, - на резервном те же испорченные данные.

Второе - восстановить что-то случайно удалённое или сломанное. Это бэкап с историей. Зеркало и реплика тут не помогут - они уже отразили ошибку. Нужен слепок состояния до того, как всё пошло не так.

Третье - и то, и то. Тогда и зеркало/реплика, и бэкап с ротацией. Чуть дороже, зато спишь спокойнее.

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

Зеркало - это не бэкап. Реплика - это не бэкап. Они делают своё дело хорошо, но это другое дело.