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

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

Классическая схема 3-2-1 — с чего всё начинается

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

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

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

Усовершенствованная схема 3-2-1-1-0 — когда классики уже недостаточно

С ростом числа атак программ-вымогателей появилась потребность в новом правиле — 3‑2‑1‑1‑0. К базовым требованиям добавились два критически важных элемента. Дополнительная единица указывает, что одна из копий должна быть изолирована от сети: это может быть immutable storage (неизменяемое хранилище), которое физически не позволяет изменить данные после записи, air-gapped копия (изолированная копия), полностью отключённая от сети, или офлайн‑носитель вроде ленты. Ноль в конце правила указывает на необходимость проверки бэкапов — ноль ошибок при восстановлении, ведь резервная копия имеет смысл только тогда, когда на неё можно положиться в критический момент.

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

Реализовать неизменяемость можно разными способами: с помощью специализированных хранилищ со встроенной защитой от изменений, облачных сервисов с поддержкой Object Lock (блокировки объектов), защищённых снапшотов на системах хранения или классического физического разделения — например, ленточных библиотек, которые после записи отключаются от системы.

Схема 4-3-2 — для критичных данных, когда на кону многое

Для критичных данных существует схема 4-3-2. Она предполагает четыре копии данных на трёх типах носителей, размещённых в двух географически удаленных локациях, причём две копии должны находиться вне основного офиса. Это уровень максимально строгой защиты, применяемый, когда потеря информации может привести к катастрофическим последствиям для бизнеса или нарушению серьёзных регуляторных требований.

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

Такой подход оправдан в отраслях с жёсткими требованиями к защите и хранению информации: в здравоохранении (хранение медицинских записей пациентов в защищённом виде), финансовом секторе (долгосрочное хранение данных о транзакциях), юридических фирмах (документы клиентов, требующие хранения на протяжении многих лет) и т. д.

Golden Copy — эталонная копия на все времена

Концепция Golden Copy (эталонной копии) — это идея, предполагающая наличие одной заведомо чистой копии данных, к которой можно обратиться, если все остальные экземпляры будут скомпрометированы. Такая копия создаётся на WORM-носителях, которые физически не позволяют изменить записанные данные, и служит последней линией защиты от программ-вымогателей и других угроз.

Аббревиатура WORM расшифровывается как Write Once, Read Many — записал один раз, читай сколько угодно, но изменить уже нельзя. Технология существует со времён, когда перфокарты сменили магнитные ленты, и остаётся актуальной по сей день. Современные WORM-системы реализуются на уровне файловой системы, через специализированные аппаратные решения или облачные сервисы с неизменяемым хранилищем.

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

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

Непрерывное резервное копирование — когда каждая секунда на счету

Continuous Data Protection (непрерывная защита данных), или CDP, — это иной подход к резервному копированию: каждое изменение данных немедленно копируется в резервную систему, обеспечивая минимально возможный RPO (Recovery Point Objective, целевая точка восстановления) — максимальный объём данных, который может быть потерян при сбое. В отличие от традиционных методов с расписанием бэкапов раз в день или раз в час, непрерывная защита данных работает постоянно, отслеживая все операции записи и реплицируя изменения практически в реальном времени.

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

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

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

Комбинированные подходы

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

Ленточные накопители всё ещё широко используются, несмотря на разговоры об их скором уходе, которые ведутся уже около двадцати лет. Современный стандарт LTO‑9 обеспечивает нативную ёмкость 18 ТБ на кассету, скорость записи до 400 МБ/с без сжатия, аппаратное шифрование AES‑256 и встроенную WORM‑функцию. При сжатии 2,5:1 ёмкость увеличивается до 45 ТБ, а скорость записи — до 1 ГБ/с, что делает ленты конкурентоспособным решением для архивного хранения.

Главное преимущество ленточных носителей — низкая стоимость хранения больших объёмов данных на длительный срок. Лента обходится дешевле дисков и облачных решений в пересчёте на гигабайт при многолетнем хранении. Кроме того, она физически отключена от сети после записи, что обеспечивает автоматическую защиту от программ‑вымогателей. При правильных условиях хранения срок службы картриджа может превышать 30 лет, что особенно важно для архивов с долгосрочными требованиями к сохранности данных.

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

Гибридные стратегии вроде Disk-to-Disk-to-Cloud (диск‑диск‑облако) или D2D2C комбинируют локальное хранение на дисках с последующей репликацией в облако, обеспечивая преимущества обоих подходов — быстрое локальное восстановление и защищённость удалённой копии.

Disk-to-Disk-to-Tape (диск‑диск‑лента) или D2D2T сочетает использование дисков и лент: первые применяются для оперативного восстановления, вторые — для долгосрочного архивирования. Конкретный выбор зависит от требований к времени и точке восстановления, бюджету и объёму данных.

Дедупликация данных позволяет существенно сократить объём хранимых резервных копий, выявляя и устраняя дубликаты на уровне блоков или файлов. Вместо того чтобы хранить десятки одинаковых почтовых вложений, система сохраняет только одну копию и создаёт ссылки на неё для остальных экземпляров. Коэффициенты дедупликации могут достигать 20:1 и даже 50:1 для типичных корпоративных данных, что напрямую влияет на стоимость хранения и скорость выполнения резервного копирования.

Инкрементное и дифференциальное копирование — как не копировать всё каждый раз

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

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

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

Существует также концепция synthetic full backup (синтетического полного бэкапа), при которой система создаёт полную резервную копию не путём чтения данных с производственных серверов, а синтезируя её из уже имеющихся бэкапов в хранилище. Для этого используется предыдущий полный бэкап, к которому применяются все последующие инкрементные изменения, формируя новую полную копию. Такой подход снижает нагрузку на производственную инфраструктуру и экономит пропускную способность сети, но требует дополнительных вычислительных ресурсов со стороны хранилища.

Технология Changed Block Tracking (отслеживание изменённых блоков, CBT), применяемая в системах виртуализации, позволяет эффективно выявлять изменённые блоки на уровне гипервизора без необходимости сканировать всю файловую систему виртуальной машины. При создании инкрементного бэкапа система запрашивает у гипервизора список изменённых блоков с момента последней копии и копирует только их, что заметно ускоряет процесс и снижает нагрузку.

Схема «Пирамида» — как стареют данные

Grandfather-Father-Son (дед-отец-сын), или GFS, иногда называемая схемой «Пирамида», — это методология ротации резервных копий, при которой разные уровни бэкапов сохраняются в течение разного времени, образуя иерархию по возрасту и важности. Классическая GFS включает ежедневные копии — «сынов», еженедельные — «отцов» и ежемесячные — «дедов». По мере старения данные перемещаются на более высокий уровень иерархии или удаляются, освобождая место для новых копий.

Ежедневные копии, или «сыны», обычно представляют собой инкрементные либо дифференциальные бэкапы, создаваемые каждый рабочий день. Они хранятся 5–7 дней и обеспечивают возможность быстрого восстановления недавних изменений. Такие копии размещаются локально для максимальной скорости доступа и служат первой линией восстановления при незначительных инцидентах, например случайном удалении файла.

Еженедельные копии, или «отцы», создаются один раз в неделю, чаще всего в виде полных бэкапов, и хранятся 4–5 недель. Они позволяют восстановить систему на несколько недель назад, если проблема была обнаружена не сразу. Эти резервные копии могут сохраняться как локально, так и в быстром облачном хранилище, что обеспечивает баланс между доступностью и безопасностью.

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

Некоторые организации добавляют ещё один уровень — ежегодные копии, или «прадеды», которые хранятся 7-10 лет и более. Это необходимо для соблюдения регуляторных требований в финансовой сфере, здравоохранении или юридической практике. Такие копии, как правило, размещаются на долгосрочных носителях, например на лентах, или в самых дешёвых классах облачного хранения.

Экзотические схемы — когда хочется чего-то особенного

Помимо общепринятых подходов существуют и более экзотические схемы ротации бэкапов, которые применяются в специфических ситуациях или просто нравятся людям с аналитическим складом ума. Одна из таких схем — «Ханойская башня» (Tower of Hanoi), основанная на математической головоломке с тем же названием и использующая рекурсивный метод для оптимизации цикла резервного копирования.

В схеме «Ханойской башни» каждый набор носителей соответствует диску в одноимённой головоломке, а каждое перемещение диска — созданию бэкапа на этот носитель. Первый носитель используется через день, второй — каждые четыре дня, третий — каждые восемь дней и так далее, по степеням двойки. Набор из n носителей позволяет охватить 2ⁿ − 1 день до повторной записи последнего набора. Например, пять носителей обеспечивают покрытие в 31 день, а десять — уже 1023 дня, то есть почти три года истории хранения при всего десяти носителях.

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

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

Как выбрать схему для своих нужд

Для малого бизнеса с ограниченными ресурсами и некритичными данными достаточно схемы 3‑2‑1‑1‑0, при условии понимания рисков, связанных с программами‑вымогателями. GFS обеспечит достаточную глубину истории для восстановления данных за прошлые периоды, а облачные сервисы позволят хранить удалённые копии без обслуживания собственной ИТ-инфраструктуры.

Среднему бизнесу с более критичными данными и большими объёмами информации стоит рассмотреть стратегию 3‑2‑1‑1‑0 с обязательными неизменяемыми копиями, гибридные решения по типу диск‑диск‑облако для оптимального баланса между скоростью восстановления и безопасностью, схему GFS с добавлением квартальных и годовых уровней для соблюдения политики хранения, а также дедупликацию для экономии пространства и снижения затрат на резервирование.

Крупные предприятия требуют комплексных решений. Для особо критичных данных — например, финансовых транзакций или персональной информации клиентов — подходит схема 4‑3‑2. В системах, где недопустима даже минимальная потеря данных, необходима непрерывная защита. Комбинированные подходы с использованием лент для долгосрочного архивирования, облака для гибкости и дисков для производительности позволяют достичь баланса между безопасностью и эффективностью. Эталонная копия на WORM‑носителях обеспечивает соответствие нормативным требованиям и защищает от продвинутых угроз. Дополнительные оптимизации, включая синтетические полные бэкапы, снижают нагрузку на инфраструктуру.

Некоторые отрасли — здравоохранение, финансы, юридические услуги — обязаны следовать требованиям регуляторов. Это подразумевает длительные сроки хранения, использование WORM‑носителей для отдельных типов данных, создание изолированных копий для предотвращения компрометации и регулярное тестирование восстановления с документированием результатов.

Заключение

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