Правило «3-2-1» также называют золотым правилом резервного копирования. Оно было сформулировано около 20 лет назад, когда в ходу были жесткие диски на 20–40 ГБ, для резервной копии было достаточно объема CD-диска, а облачные сервисы хранения только начали появляться. С тех пор технологии хранения данных значительно развились, претерпело изменения и правило «3-2-1»: появились его разновидности, такие как «3-2-1-1», «4-3-2» и другие. Ниже рассмотрим несколько основных вариаций базового правила.
Правило «3-2-1-1»
Дополнительная единица справа подчеркивает важность хранения копии данных вне сети организации (air-gapped copy). Это может быть копия на ленте или переносном диске, хранящаяся за пределами офиса, копия на устройстве NAS, отключаемом от сети компании, или же копия в неизменяемом хранилище (immutable storage) – на оптическом диске или в облачном хранилище типа Amazon S3 Object Lock, работающем по модели WORM (write-once-read-many). Использование внесетевого или неизменяемого хранилища повышает надежность защиты от вирусов-шифровальщиков: копия в таком хранилище не будет подвержена атаке.
Правило «4-3-2»
В этой вариации правила рекомендуется иметь четыре копии данных, которые хранятся в трех различных местах. Первое хранилище может располагаться на площадке компании, второе – у поставщика услуг внеофисного хранения, третье – в облаке. Таким образом, появляются два хранилища резервных копий вне офиса, что повышает защищенность данных.
Правило «3-2-1-0»
Регулярное создание резервных копий и обеспечение их надежного хранения – это только часть задачи. Вторая часть заключается в обеспечении гарантированного восстановления данных из созданной ранее резервной копии. И тут у правила «3-2-1» в конце добавляется ноль, что означает отсутствие ошибок в резервной копии за счет ее проверки – операции по определению возможности восстановления данных.
Как применять правила в Кибер Бэкапе
Система резервного копирования Кибер Бэкап позволяет реализовать на практике все упомянутые выше вариации золотого правила. Рассмотрим пример, как выполнить правило «3-2-1-0».
Репликация резервных копий
Начнем с создания дополнительных резервных копий. Этот процесс называется репликацией, и в Кибер Бэкапе его можно осуществить двумя способами: редактированием плана резервного копирования или созданием отдельного плана репликации. На уровне плана резервного копирования репликация выполняется путем добавления хранилищ. Помимо основного хранилища можно добавить до 4 дополнительных, получив таким образом 5 резервных копий одного набора данных. Также в настройках можно указать срок хранения реплики, параметры производительности и окна резервного копирования. Впоследствии данные можно будет восстановить из любой резервной копии без доступа к другим хранилищам.
Репликация, входящая в план резервного копирования, выполняется агентом резервного копирования. Это увеличивает рабочую нагрузку на машину, на которой запущен агент, даже после завершения процесса резервного копирования. Для того чтобы снизить нагрузку на эту машину, репликацию можно вынести на отдельную машину (осуществлять обработку данных off-host), запланировать выполнение репликации в часы наименьшей загрузки или в нерабочее время.
В рамках отдельного плана репликации можно назначить эту операцию выбранному агенту, указать резервные копии для репликации, места хранения реплик и задать расписание.
Размещение резервных копий в облаке
Пользователям Кибер Бэкапа, которые рассматривают облако в качестве удаленного хранилища, доступно два варианта. Первый – воспользоваться компонентом Advanced Backup Gateway (ABGW), входящим в состав продукта Кибер Инфраструктура, чтобы выгрузить реплику в облако. Второй – использовать наше совместное с Yandex Cloud решение в качестве промежуточного хранилища при загрузке резервных копий в S3-хранилище сервиса Yandex Cloud.
Таким образом, используя механизм репликации, мы реализовали основную часть правила «3-2-1-0». Оптимальным выбором будет хранить резервные копии как локально, что позволит максимально быстро восстановить данные в случае сбоя, так и удаленно, что обеспечит защиту резервных копий при отказе локального хранилища или стихийных бедствиях.
Осталось выполнить последнюю часть правила, т. е. 0 ошибок в резервной копии при ее проверке.
Проверка резервной копии
В Кибер Бэкапе используется два метода проверки резервных копий: проверка контрольных сумм для каждого блока восстанавливаемых данных и запуск резервной копии как виртуальной машины.
Успешная проверка означает высокую вероятность восстановления данных, но эта операция проверяет не все факторы, влияющие на процесс восстановления. При резервном копировании операционной системы рекомендуется выполнить тестовое восстановление с загрузочного носителя на запасной жесткий диск или запустить виртуальную машину из резервной копии в виртуальной среде. Проверка резервных копий путем запуска виртуальной машины позволяет обеспечить возможность восстановления данных из резервных копий дисков, содержащих операционную систему.
Проверку резервных копий можно выполнять непосредственно после их создания или сформировать отдельный план проверки резервных копий. В первом случае операция осуществляется методом проверки контрольных сумм и выполняется агентом, установленным на исходной машине. В рамках отдельного плана проверки проверяются все резервные копии, находящиеся в хранилище, и эту операцию можно назначить любому агенту, имеющему доступ к хранилищу. При настройке плана доступны оба метода проверки: вычисление контрольной суммы для каждого блока данных и запуск виртуальной машины из резервной копии. Можно выбрать один из методов или сразу оба (в таком случае операции будут выполняться последовательно).
Выше мы рассмотрели несколько вариантов правила «3-2-1» и показали, как реализовать один из них в нашем продукте Кибер Бэкап. Регулярное копирование важных данных, хранение резервных копий в локальной инфраструктуре и вне офиса, а также их проверка позволяют в случае необходимости оперативно восстанавливать данные и обеспечить непрерывность рабочих процессов.
