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

MAATRIX · Выделенные серверы · Статья 47 из 48

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

На третьей минуте обнаруживается, что пароль от архива лежит только на основном сервере. На десятой — что конфигурация приложения не попала в копию. На двадцатой выясняется, что база сохранена, но никто не записал её версию. Если это репетиция, утро можно считать удачным: вы нашли ошибки до того, как их нашли клиенты.

Автоматический бэкап выделенного сервера заканчивается не зелёной строкой в журнале. Его настоящая конечная точка — работающий сервис, восстановленный из выбранной копии. Отдельный backup-узел помогает пройти этот путь, если спроектировать его как независимое место хранения, а не как ещё одну папку с привычными правами администратора.

Сначала решите, какое прошлое вы хотите сохранить

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

Допустимую потерю данных во времени обычно описывают показателем RPO, а целевое время возврата сервиса — RTO. Эти две величины стоит записать обычными словами. Например: «после сбоя мы можем восстановить состояние не старше часа и должны вернуть основные операции за четыре часа». Это условный пример требований, а не обещание любого сервера или программы резервного копирования.

Дальше проверяют, достижимы ли они. Копия раз в сутки не соответствует часовому RPO. И наоборот, отправка журналов базы каждые несколько минут не обеспечивает короткий RTO, если полная выгрузка занимает полдня, а инструкция по восстановлению начинается словами «позвонить бывшему администратору».

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

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

Почему второй диск на том же сервере не решает задачу

У NECROPOLIS предусмотрены два NVMe по 1 ТБ, у CARTOUCHE — два SSD по 600 ГБ. Это даёт варианты организации хранения, но не означает наличие готового RAID и тем более независимого бэкапа.

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

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

Поэтому правило нескольких копий нельзя свести к покупке ещё одного диска. Важно, от каких отказов защищает каждая копия и какие события могут уничтожить их вместе. Практическую основу даёт правило 3–2–1 для резервного копирования, но конкретная схема должна учитывать ваши данные и способы их утраты.

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

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

Согласованная копия базы важнее быстрого копирования файлов

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

Копирование каталога работающего PostgreSQL обычным rsync не становится корректным резервным копированием оттого, что команда завершилась успешно. Нужны предусмотренный СУБД способ, согласованный снимок при выполнении необходимых условий либо остановка и корректное файловое копирование. Ограничения перечислены в документации PostgreSQL о файловых копиях.

Для небольшой базы часто удобен логический экспорт. Для больших объёмов и восстановления к определённому моменту рассматривают физическую базовую копию и архивирование WAL. Важно сохранить не только исходную копию, но и необходимую непрерывную цепочку журналов. Потерянный участок способен ограничить доступные точки восстановления. Документация PostgreSQL по непрерывному архивированию описывает условия такой схемы.

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

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

Реплика базы полезна для доступности, но не заменяет историю резервных копий. Если пользователь удалил нужные данные законной с точки зрения СУБД командой, реплика может добросовестно повторить удаление. Репликация умеет быстро переносить изменения; она не обязана догадываться, что именно это изменение вы хотели бы забыть.

Передавать новые копии можно без права уничтожать старые

Простая схема часто начинается так: основной сервер подключается к хранилищу по SSH, складывает архив и удаляет старые файлы. Удобно, прозрачно — и очень щедро по полномочиям. При компрометации рабочей машины злоумышленник получает не только текущие данные, но и инструмент очистки их истории.

Лучше разделять создание новых копий и обслуживание хранилища. Учётная запись отправителя получает только необходимые права. Удаление устаревших версий выполняется отдельным механизмом, чьи полномочия не хранятся на рабочем сервере. Административный доступ к backup-узлу также отделяют от повседневной учётной записи приложения.

Один из практических вариантов — restic с REST-хранилищем. В rest-server предусмотрен режим append-only: через этот интерфейс можно добавлять данные, но нельзя произвольно изменять и удалять существующие. Передачу и аутентификацию защищают подходящим транспортом, например HTTPS. Это описано в официальной документации rest-server.

Однако append-only не делает сервер неуязвимым. Администратор самого хранилища, доступ к его дискам, неверно настроенный альтернативный интерфейс или ошибка процедуры очистки способны обойти ожидаемую защиту. Злоумышленник также может попытаться заполнить доступную ёмкость. Поэтому нужны изоляция полномочий, квоты, наблюдение за местом и отдельная проверка пути удаления.

Неизменяемое хранение с установленным сроком удержания может усиливать схему, если используемая система действительно обеспечивает эти свойства. Нужно понять, кто способен отменить удержание, что произойдёт при удалении учётной записи и как устроено восстановление. Одного слова immutable в рекламном описании мало для готового регламента.

Ключи и пароли требуют своего плана спасения. Если единственный пароль от зашифрованного репозитория погиб вместе с основным сервером, сохранность архива становится философским утешением. Резервный доступ хранят отдельно, выдают ограниченному кругу людей и проверяют в ходе репетиции.

Хорошая проверка прав проста по замыслу: учётная запись рабочего узла не должна иметь возможности очистить старые копии через другой доступный ей путь. Причины такого разделения подробно разобраны в статье о хранилище бэкапов с избыточными правами записи.

Как рассчитать место, канал и окно резервного копирования

Размер исходных данных — только начало расчёта. К нему добавляются темп изменений, срок хранения версий, полные копии, журналы базы, служебные данные и запас для обслуживания. Дедупликация и сжатие могут помочь, но степень экономии определяется содержимым. Уже сжатое видео и многократно меняющаяся база ведут себя совсем по-разному.

Предположим, рабочие данные занимают 400 ГБ. Из этого не следует, что хранилища на 500 ГБ хватит на месяц истории. Если ежедневно меняется значительная часть содержимого, прежние блоки должны где-то оставаться. И наоборот, умножать 400 ГБ на количество дней тоже не всегда правильно: выбранный инструмент может повторно использовать неизменившиеся данные.

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

Во всех рассматриваемых тарифах указан порт 1 Гбит/с с обозначением UNLIMITED. Чисто арифметический потолок для одного гигабита в секунду — 125 МБ/с до накладных расходов. Передача 1 ТБ в десятичном исчислении при таком идеальном темпе заняла бы около 2 часов 13 минут. Реальный путь обычно медленнее из-за протоколов, маршрута, шифрования, дисков и параллельной нагрузки.

При планировании учитывают обе стороны: не только ночную отправку, но и аварийную загрузку обратно. Если восстановление должно уложиться в час, одна только передача большого архива может нарушить это требование. Нужны другой объём восстановления, более быстрый подтверждённый путь, заранее подготовленная копия среды либо пересмотр RTO.

Не стоит забивать резервным копированием весь канал работающего сервиса. Ограничение скорости, распределение задач по времени и измерение влияния на задержки помогают сохранить рабочий день пользователей. Расписание выбирают по реальному профилю нагрузки: «ночь» у сервера в США и у клиентов в России может означать разное время.

Проверка репозитория и проверка приложения — две разные работы

Инструмент резервного копирования способен проверить структуру и целостность хранилища, но это ещё не подтверждение работоспособности восстановленного приложения. Например, обычный restic check и проверка с чтением всех данных имеют разный объём работы: для полного чтения используется отдельный параметр. Такой проход требует времени и сетевого трафика. Разница объяснена в документации restic о проверке репозитория.

После технической проверки нужна репетиция восстановления на изолированной машине. Выбирают конкретную дату, возвращают файлы, поднимают базу, подключают приложение и выполняют несколько проверок на уровне бизнеса. Открывается ли документ? Видна ли тестовая запись? Совпадают ли ожидаемые данные? Не исчезла ли настройка, без которой сервис работает только наполовину?

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

Время измеряют целиком: получение доступа, подготовка машины, передача данных, восстановление, проверки и переключение. Именно эту продолжительность сравнивают с RTO. Быстрая распаковка архива мало утешает, если поиск нужного сертификата занял ещё три часа.

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

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

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

Все материалы о выделенных серверах