Резервное копирование серверов: почему одного бэкапа недостаточно и чем отличаются snapshots, RAID и репликация

Практически каждый владелец сайта уверен, что у него есть резервные копии. До тех пор, пока не происходит первая серьёзная авария.

Удалили важные данные, неудачно обновили CMS, сломалась база данных, вышел из строя диск или перестал отвечать сервер — в этот момент оказывается, что «резервное копирование» может означать совершенно разные вещи. И далеко не каждое решение поможет восстановить проект.

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

Самая распространённая ошибка — считать, что любой способ хранения копий одинаково защищает проект.

На практике разные технологии предназначены для разных сценариев.

Например:

Ни одно решение не закрывает все эти риски одновременно.

Поэтому важно понимать, какие механизмы используются и когда они действительно помогают.

Если проект размещён на VPS, многие провайдеры предлагают создавать snapshots (снепшоты) виртуальной машины.

Проще говоря, это полная фотография сервера в определённый момент времени.

В отличие от обычного резервного копирования сайта, snapshot включает практически всё:

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

Это особенно удобно, если на VPS размещено сразу несколько проектов.

Вместо восстановления каждого сайта отдельно можно вернуть всю систему сразу.

Чаще всего их используют перед потенциально опасными изменениями:

Если после изменений что-то пошло не так, восстановление занимает значительно меньше времени.

Однако важно понимать, что snapshot — не полноценная замена классическим резервным копиям.

Если снимок хранится на той же инфраструктуре, где находится основной VPS, серьёзная авария у провайдера может затронуть и его.

Многие считают RAID резервным копированием.

На самом деле это не совсем так.

RAID предназначен прежде всего для повышения отказоустойчивости оборудования.

Самый распространённый вариант — зеркалирование дисков (RAID 1).

В этом случае сервер одновременно записывает данные сразу на два накопителя.

Если один диск выходит из строя, второй продолжает работать.

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

Звучит идеально.

Но есть несколько важных ограничений.

Если удалить важную папку, она исчезнет сразу с обоих дисков.

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

Если база данных окажется повреждённой, RAID сохранит уже повреждённую информацию.

Другими словами, RAID защищает оборудование, а не историю изменений.

Несмотря на высокую надёжность, у технологии есть свои особенности.

При использовании аппаратного RAID отказ RAID-контроллера способен вывести из строя весь массив.

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

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

Поэтому RAID нельзя считать заменой резервным копиям.

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

В этом случае создаётся полноценная копия сервера на отдельной машине.

Фактически существует два экземпляра инфраструктуры:

Все изменения регулярно синхронизируются между ними.

Если основной сервер выходит из строя, трафик можно переключить на резервный.

Для пользователя это выглядит как кратковременный сбой или вовсе остаётся незаметным.

Именно поэтому репликацию часто используют:

Иногда реплицируют не весь сервер целиком, а только наиболее критичные компоненты.

Например:

Такой подход позволяет сократить стоимость инфраструктуры.