Резервное копирование: что это, виды и схемы backup

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

Именно для этого и нужно резервное копирование.

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

В этой статье разберём, что такое резервное копирование, какие виды бэкапов используются на практике, чем отличаются full, incremental и differential backup, как работают схемы ротации и почему одного «делать копию раз в неделю» для бизнеса обычно недостаточно.

Что такое резервное копирование

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

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

Объектом резервного копирования могут быть:

На практике хорошая стратегия backup всегда опирается на два показателя:

• RPO — сколько данных допустимо потерять;
• RTO — сколько времени допустимо тратить на восстановление.

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

Зачем нужно резервное копирование

Главная задача backup — не просто «сделать копию», а обеспечить восстановление в реальном рабочем сценарии.

Причины, по которым компаниям нужны резервные копии, обычно вполне приземлённые:

На практике backup нужен не только для катастрофических сценариев. Гораздо чаще резервные копии используются для точечного восстановления: вернуть одну таблицу, откатить ВМ, восстановить каталог после удаления, поднять систему после неудачного изменения конфигурации.

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

Виды резервного копирования по полноте данных

Самая базовая классификация — по тому, какой объём данных попадает в копию.

Полное резервное копирование (Full Backup)

Полный backup копирует весь выбранный набор данных целиком.

Это самый понятный вариант. При восстановлении не нужно собирать длинную цепочку точек: достаточно одной полной копии. Поэтому full backup проще всего и проверять, и использовать в аварийной ситуации.

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

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

Инкрементное резервное копирование (Incremental Backup)

Инкрементный backup сохраняет только те изменения, которые произошли после последней резервной копии — полной или инкрементной.

Это даёт два преимущества:

• копии создаются быстрее;
• требуется меньше места на хранении.

Но при восстановлении цепочка становится длиннее. Сначала нужна полная копия, затем все последующие инкременты. Чем длиннее цепочка, тем выше требования к её целостности и тем важнее регулярная проверка восстановления.

Такой вариант часто выбирают для ежедневного резервного копирования, когда данных много, а окно backup ограничено.

Дифференциальное резервное копирование (Differential Backup)

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

По логике это промежуточный вариант между full и incremental:

• создаётся быстрее, чем полный backup;
• восстанавливается проще, чем длинная инкрементная цепочка.

Для восстановления обычно достаточно двух точек: последнего full backup и последнего differential backup.

Минус в том, что по мере удаления от полной копии объём differential backup растёт. В начале цикла он небольшой, ближе к концу — уже заметный.

Сравнение основных типов backup

Другие виды резервного копирования

По степени автоматизации

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

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

• по расписанию;
• по событиям;
• по политикам хранения;
• с уведомлениями о сбоях.

По состоянию системы: горячее и холодное копирование

Холодный backup создаётся, когда система или приложение остановлены. Такой способ обычно проще с точки зрения консистентности: данные не меняются в момент копирования.

Горячий backup выполняется без остановки сервиса. Это удобнее для продакшена, но требует, чтобы приложение, гипервизор или СРК корректно работали с активными данными.

Для бизнеса горячее резервное копирование чаще всего предпочтительнее: оно не требует останавливать сервисы ради backup-окна.

Схемы ротации резервных копий

Сделать копию один раз недостаточно. Важно ещё правильно организовать хранение версий.

Ротация — это правила, по которым старые копии заменяются новыми и сохраняются на нужный срок. Она нужна, чтобы:

• не переполнить хранилище;
• сохранять историю изменений;
• иметь точки восстановления за день, неделю, месяц и дольше.

Схема «дед-отец-сын» (GFS)

Одна из самых известных схем ротации.

Суть простая:

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

Простая циклическая ротация

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

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

Выбор схемы ротации

Чем выше требования к восстановлению и аудиту, тем важнее хранить несколько горизонтов:

• короткий — для оперативных инцидентов;
• средний — для ошибок, обнаруженных спустя дни;
• длинный — для разбирательств, регуляторных задач и восстановления старых версий.

Правило резервного копирования 3-2-1

Одна из самых важных практик в backup — правило 3-2-1.

Оно означает:

• 3 копии данных: рабочая и минимум две резервные;
• 2 разных типа носителей или среды хранения;
• 1 копия вне основной площадки.

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

На практике правило 3-2-1 часто выглядит так:

• рабочие данные в основной инфраструктуре;
• локальный backup для быстрого восстановления;
• удалённая копия в другом контуре или облаке.

Именно такой подход обычно даёт баланс между скоростью восстановления и устойчивостью к аварии на площадке.

Где и как хранить резервные копии

Универсального ответа нет: место хранения зависит от объёма, скорости восстановления, бюджета и требований к изоляции.

Обычно используют три сценария.

Независимо от места хранения, резервные копии стоит:

• шифровать;
• изолировать от боевого контура;
• проверять на целостность;
• регулярно тестировать на восстановление.

Системы и инструменты резервного копирования

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

Для отдельных файлов и простых сценариев могут подойти встроенные средства ОС и базовые утилиты.

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

При выборе инструмента важно смотреть не только на сам backup, но и на восстановление:
насколько быстро поднимается ВМ, можно ли вернуть отдельный файл, как работает восстановление в другой контур, есть ли изоляция копий от продакшена.

Как организовать резервное копирование

Рабочая схема обычно строится поэтапно.

Сначала определяют, какие данные и сервисы действительно критичны. Затем для них задают целевые RPO и RTO. После этого выбирают типы backup, частоту копирования, ротацию и место хранения.

Практически процесс выглядит так:

1. определить критичные системы и объём данных;
2. задать требования к восстановлению;
3. выбрать схему: full, incremental, differential или их комбинацию;
4. настроить расписание и ротацию;
5. вынести хотя бы часть копий за пределы основной площадки;
6. регулярно проверять восстановление;
7. задокументировать политику backup и действия при аварии.

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

Частые ошибки при резервном копировании

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

На практике проблемы обычно другие:

Пока не выполнен тест restore, backup нельзя считать действительно рабочим.

Заключение

Резервное копирование — это не отдельная задача «для галочки», а основа устойчивой IT-инфраструктуры. Хороший backup учитывает не только создание копий, но и глубину хранения, сценарии аварии, место размещения данных и реальную скорость восстановления.

Для большинства компаний рабочий подход выглядит так: комбинировать full backup с incremental или differential копиями, использовать понятную схему ротации и придерживаться правила 3-2-1.

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