Резервное копирование: стратегия 3-2-1 для бизнеса

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

Помимо бэкапа есть снапшот и репликация:

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

• Репликация — постоянное или регулярное копирование данных из одной системы в другую. Она помогает обеспечить доступность ресурсов и быстрое переключение на резервную систему при отказе основной. Однако проблемы с исходниками могут отразиться и на репликах. 

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

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

Какую угрозу закрывает каждая цифра

Расшифруем название правила и его суть: 

• 3 копии защищают от проблем при потере одной из них. Если повредится диск или удалятся данные в основном хранилище, останутся другие экземпляры. 

• 2 разных типа носителей снижают риск общей причины отказа. Например, если рабочие данные и бэкап находятся на двух независимых системах хранения, проблема с одной инфраструктурой не затронет вторую копию.

• 1 копия вне основной площадки нужна на случай локальной катастрофы вроде пожара, потопа, повреждения дата-центра. Такое событие может вывести из строя несколько систем на одной площадке. Выручит копия в другом дата-центре или облаке. 

Развитие правила: 3-2-1-1-0 

В варианте 3-2-1-1-0 больше требований. Дополнительная единица значит, что одна копия должна быть неизменяемой или автономной.

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

Копировать нужно виртуальные машины, базы данных и журналы транзакций, 1С и информационные базы, файловые серверы, конфигурации и секреты, SaaS-данные. 

Классификация данных: базы и 1С, виртуальные машины, файлы, конфигурации — у каждого свой RPO

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

Примеры графиков резервного копирования:

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

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

• Файлы и документы — часто изменяемые и востребованные файлы можно копировать ежедневно, архивные данные — раз в 5–7 дней.

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

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

Полные и инкрементальные копии: как совместить скорость, объем хранилища и простоту восстановления

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

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

Есть и дифференциальное копирование: такая копия содержит все изменения с момента последнего полного бэкапа. Она занимает больше места, чем инкрементальная, зато для восстановления достаточно полной и последней дифференциальной копий.

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

Глубина хранения (Retention): сколько держать дневные, недельные и месячные копии

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

• дневные копии хранить до 30 дней;

• недельные — 6 месяцев;

• месячные — от 6 месяцев.

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

Хранить все резервные копии рядом с рабочими данными рискованно — при сбоях и атаках можно потерять все. Бэкапы имеет смысл распределять между локальными и удаленными хранилищами. 

Локальная копия — для быстрого восстановления, облачная — для защиты от катастроф и шифровальщиков

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

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

Защита копий от удаления: неизменяемое хранение, отдельные учетные данные, изоляция от основной сети

Резервные копии важно защитить не только от потери данных, но и от намеренного удаления или изменения, например при атаке шифровальщика. Для этого используют несколько механизмов.

Неизменяемое хранение (Immutable Storage) запрещает изменять или удалять данные в течение заданного срока. Один из вариантов — WORM-хранилища (Write Once, Read Many), работающие по принципу «записал один раз, читай многократно». В S3-совместимых объектных хранилищах для защиты объектов от перезаписи и удаления применяют механизм Object Lock. В зависимости от настроек блокировка действует в течение определенного срока или бессрочно.

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

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

Сравнение схем резервного копирования:

Создание резервной копии еще не означает, что получится ей воспользоваться. Ошибка может обнаружиться только при попытке восстановить данные. Чтобы избежать риска, проверять бэкапы стоит в процессе создания, а не во время инцидента. 

Регулярное тестовое восстановление: что, как часто и по какому сценарию проверять

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

Тесты проводятся не только с новыми копиями, но и со старыми. Это позволяет убедиться, что данные можно возвращать «издалека». 

В Cloud.ru для разных сценариев предусмотрены отдельные сервисы и механизмы. 

Evolution Agent Backup

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

Evolution Object Storage как хранилище копий

Evolution Object Storage — S3-совместимое объектное хранилище для файлов, образов и других объектов. Можно загружать любые объемы, не боясь, что хранилище переполнится — сервис автоматически наращивает размер по мере заполнения. Данные хранятся в нескольких зонах доступности, и операции над ними строго консистентные — если объект обновляется в одной зоне, то обновится и в других. 

Для защиты применяется версионирование — сохранение предыдущих состояний объектов, чтобы манипуляции с последней версией не уничтожили историю. Также есть механизмы управления сроками хранения. 

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

• Advanced Cloud Backup and Recovery — сервис для резервного копирования и восстановления серверов, дисков, файловых систем. После первой полной копии по расписанию создает инкрементальные. 

• Evolution Disaster Recovery — сервис для восстановления ИТ-инфраструктуры и миграции под нагрузкой. Обеспечивает постоянную репликацию данных и запуск резервных копий за минуты. 

• Решение Cloud.ru «Резервное копирование и аварийное восстановление» — облачные сервисы для защиты данных и виртуальных машин по моделям BaaS (Backup-as-a-Service) и DRaaS (Disaster Recovery-as-a-Service). Позволяет быстро восстановить инфраструктуру и обеспечить бесперебойную работу бизнеса. 

Что делать, чтобы бэкапы приносили пользу:

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

2. Задать RPO — определить, сколько данных не страшно потерять при сбое и за какой промежуток, например, за час, несколько часов, сутки.

3. Определить RTO — установить крайний срок, по истечении которого нужно восстановить систему. 

4. Настроить расписание — назначить частоту полного и инкрементального копирования.

5. Задать срок хранения — определить, сколько ежедневных, недельных и месячных копий нужно сохранять.

6. Применять схему 3-2-1 — делать минимум три копии данных на двух типах носителей, одну из них — в другом контуре.

7. Беречь резервные копии — предусмотреть контроль целостности копий, шифрование, защиту от шифровальщиков, разделение доступа к бэкапам.

8. Контролировать выполнение бэкапов — в процессе отслеживать ошибки, объем памяти хранилищ. 

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

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

Заключение

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

Регулярно проверяйте резервные копии и оценивайте, укладывается ли восстановление в заданный RTO. Это поможет выявить слабые места до инцидента и снизить риск длительного простоя бизнеса.

FAQ

• Что такое правило 3-2-1 в резервном копировании?

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

• Чем бэкап отличается от снапшота?

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

• Как часто нужно делать резервные копии?

  Зависит от типа данных и RPO. Каждая компания составляет график под себя. 

• Как защитить бэкапы от шифровальщиков?

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

• Как настроить резервное копирование 1С?

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

• Сколько стоит хранить резервные копии в облаке?

  Стоимость зависит от объема и типа данных, срока хранения, частоты копирования и вида хранилища. Иногда отдельно тарифицируются трафик и операции с бэкапом. 

• Как проверить, что из бэкапа можно восстановиться?

  Запустить копию в тестовой среде, замерить время восстановления и сравнить с RTO.