Продукты для резервного копирования информации
100,43
рейтинг
1 августа 2013 в 12:38

Разное → Правило резервного копирования «3-2-1». Часть 1 tutorial

Считается, что бэкап-правило «3-2-1» впервые описал Peter Krogh в своей книге «Управление цифровыми активами для фотографов». И это, наверное, неудивительно, так как потеря личного архива означает для профессионального фотографа полную катастрофу, и он просто обязан придерживаться такой стратегии резервного копирования, которая гарантировано защитит его от потери данных.



Итак, правило «3-2-1» гласит, что для обеспечения надежного хранения данных, необходимо иметь как минимум:
  1. ТРИ резервные копии,
  2. которые должны быть сохранены в ДВУХ различных физических форматах хранения,
  3. причем ОДНА из копий, должна быть передана на внеофисное хранение

Все три составляющих правила базируются на принципе обеспечения отказоустойчивости через избыточность хранения данных.

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

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

Почему копий нужно три, а не две? Потому что в реальной жизни, очень часто, угрозы двум копиям данных оказываются статистически зависимыми в силу логической организации процедуры резервного копирования. К примеру, рассмотрим RAID1 (или дисковый массив с «зеркалированием», см. подробнее пост "технологии дисковых снапшотов"). Если вирус заражает файл на одном диске массива, сразу же происходит заражение второй копии на зеркальном диске. Аналогично, если настроена репликация, то реплика мгновенно будет также испорчена вирусом. Даже, если просто выполняется ежедневное построение полной резервной копии, она также будет заражена, если администратор за день не заметит заражение исходных данных. В целом: двух копий будет не достаточно для восстановления информации во всех случаях, когда время выявления и реакции администратора на повреждение оригинальных данных превышает период между смежными задачами по копированию/реплицированию/зеркалированию этих данных.

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

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

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

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

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

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

Всегда ли нужно жестко следовать правилу «3-2-1»? Нет, все зависит от стоимости ваших данных, с одной стороны, и критичности (стоимости потенциального ущерба) и вероятности угроз данным, с другой стороны. Любая защита не должна превышать по стоимости защищаемый объект. Поэтому, если у вас хранятся не особо ценные данные, или угрозы низко критичны или маловероятны — можно реализовывать правило «3-2-1» частично. Главное — все же составить матрицу угроз данным (то есть составить список всех возможных угроз, оценить их вероятность и критичность) и провести процесс их деактуализии (то есть у каждой угрозы либо написать в таблице либо «деактуализирована такой-то технической мерой» или «признать не актуальной с точки зрения характера бизнеса компании»). После проработки матрицы угроз, станет понятно в какой степени следует реализовывать правило 3-2-1, и какой в итоге потребуется бюджет.

Во второй части данной статьи будет рассказано как можно реализовать бэкап-правило «3-2-1» с помощью продукта Veeam Backup & Replication v7.

Ссылки:
1. Peter Krogh. «The DAM Book: Digital Asset Management for Photographers»
Автор: @sysmetic
Veeam Software
рейтинг 100,43
Продукты для резервного копирования информации

Комментарии (16)

  • 0
    Личные данные свои — давно храню в облаке копию! И на независимом переносном винте! Но это личные…
    На работе делаем бакапы разными способами! В основном на библиотеку ленточную! Вернее сначала на полку (для быстрого доступа), затем на библиотеку — для долгосрочного хранения! :) Плюс периодические бакапы образов серверов на всякий случай для себя! Самое критичное — не бакапится, а резервируется в относительно реальном времени — для быстрого выхода в штатный режим функционирования. Хотя, данные в самом критичном — тоже хранятся на стороне — их бакапят другие админы! :) Ну вот как-то так!
    • 0
      А если не секрет, какой давности вы обычно храните резервной копии? Пару дней, неделя, месяц? И как часто вообще делаете бэкап?
      • +3
        Вопрос относится к личному или к корпоративному?
        Если к первому — то просто сервисы аля дропбокс — реально спасли недавно — когда мак ссд свое спалил!
        А если к корпоративному — то тут по разному! Написан подробный бакап-план — по нему — файлопомойки и базы данных еженочно, критические системы — раз в 15 минут! А храним — файлопомойки долго — до 1,5 месяцев (вдруг — пользователю чего понадобится) — все остальное — около недели, не больше! Виртуалки на vmware — раз в неделю тоже копируем! То есть еженочно снимаем данные с этих виртуалок, А еженедельно — копируем сами виртуалки! Софт — hp dataprotector — гибко, удобно!
  • +2
    Как раз недавно у меня был разговор с про-фотографом и я поинтересовался — а как и где хранит. Оказалось — на домашнем NAS-е с RAID1. Следующий вопрос «а если в форточку залезут и сопрут?» позволил мне оседлать своего конька )
    Вообще, для фотографов, я считаю, недорогой «домашний» двудисковый Raid1 NAS от Qnap или Synology, где есть возможность настоить синхронизацию отдельных фолдеров с Амазоновским S3 и другими облаками — идеальное решение для домашнего хранения. Масса небольших файлов идеально подходит для такого механизма синхронизации. Периодическое пополнение архива не создает большой нагрузки на траффик синхронизации.

    Второе условие, описанное в статье — идеал, конечно, но от «магнитного импульса» и прочих страстей спасет обычная герметичная железная коробка. Такую я и вожу в багажнике, соблюдая пункт 3 )
    • 0
      Да не смешите мои тапки, s3 довольно дорог на большие объемы, заходил к знакомой фотографше, так у неё жестких дисков больше чем у меня во время жесткого увлечения аниме, фоток террабайты, если не десятки террабайт. Такое хранить в облаке себе дороже.
      • +2
        Не хочу смешить ваши тапки, но я говорил именно про эти самые террабайты…
        И если у фотографа нет десятки американских денег за хранение терабайта на Glacier — поверьте, там терять действительно нечего )
        • 0
          s3 и glacier все таки разные штуки, ну а залить в glacier не так уж и просто технически. Это вам все таки не сисадмин, а фотограф.
          В s3 10 террабайт хранить 652 доллара ежемесячно, проще в аренду дедики брать.
          • +2
            Почитайте все-таки что такое lifecycle — как автоматом S3 умеет через указанное ему время после закачки в S3 папку все уносить на Glacier.
            • 0
              Когда я тестил гласиер такой возможности точно не было.
              Спасибо за наводку.
              Плюсанул ваши комменты, жалко карму не могу.
              Спасибо что направили на путь истинный, был не прав, исправлюсь.
  • 0
    >> Если вирус заражает файл на одном диске массива, сразу же происходит заражение второй копии на зеркальном диске.

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

    от вирусни спасет только дифференциальный бэкап, и ничто другое
    • 0
      Полагаю, вы имеете в виду ситуацию, когда дифференциальный бэкап делается (как он описан в классике), скажем, 6 дней в неделю, а на 7 день проходит полный бэкап (назовем это схемой «6+1»). В этом случае мы имеем историю изменения данных за неделю (фактически 7 исторических копий данных), и, конечно, такой способ намного надежнее, чем случай с тремя копиями. Однако, если администратор не заметит заражения файла за неделю, или если дифференциальный бэкап делается не по описанной схеме 6+1, а скажем, 3+1, или 2+1, то и этот способ может не помочь избежать потери оригинальной (не зараженной вирусом) копии файла.

      В статье я хотел описать некий минимальный уровень количества резервных копий. Хотел показать, что две — точно мало. По сути, описана следующая концепция: когда у вас есть постоянно меняющиеся оригинальные данные, нужно как можно чаще делать их дубликат (реплику, вторую копию) на другом физическом носителе. Чем чаще будете снимать дубликат данных, тем лучше будет RPO (то есть будет меньше потерянных новых изменившихся данных в случае, если произойдет сбой оригинального диска). Т.о. хранилище «второй копии» д.б. быстрым — то есть лучше всего на эту роль подходит дисковое СХД. Вторым аргументом в пользу быстрого дискового СХД является RTO (скорость восстановления после сбоя). Но у такого подхода есть и «обратная сторона».

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

      По сути, только третья копия (и последующие) является средством резервного копирования, если она создается уже по другому, более «медленному», расписанию (скажем, не мгновенно, а раз в день), а сохранение идет в другую среду, чем диски (то есть, например, в облако или на ленты). Эта третья копия (и последующие) хранят по сути историю изменений за период времени, чем их больше -конечно тем лучше. Тем больше у администратора возможностей заметить заражение файла и откатится к той версии файла, когда он был еще не заражен.
      • 0
        я специально перечитал ещё раз Ваш топик, и всё равно не понял, для чего необходим третий бэкап. что в нём волшебного? как он спасает от вирусов?
        если речь идёт конкретно о вирусах, то любой уважающий себя админ имеет в сетке сканер, который, при аномальной активности хотя бы на одном компьютере, завалит алертами почтовый ящик или сотовый телефон. напомню, время реагирования на вирусную активность — 15 минут. о какой НЕДЕЛЕ может идти речь? точнее, что за такой администратор, который за неделю не может обнаружить вирусы в локальной сети?
        • 0
          ОК, может, я ответил, немного неверно поняв ваш изначальный вопрос: итак, на вопрос «зачем нужна вторая локальная копия?», могу дать такой ответ: «для отказоустойчивости и уменьшения RTO и RPO (так как процесс восстановления В/ИЗ удаленного хранилища обычно не быстрый)». Если в этом нет большой необходимости, то, конечно, согласен с вами,- вторая локальная копия данных не нужна.

          Еще могло быть терминологическая неточность. Первой копией данных я называю сами оригинальные данные, второй локальной их копией — первую резервную локальную копию.
  • 0
    «То есть, когда вы делаете три копии вместо одной, то получаете утроение вероятности сбоя данной совокупности копий»

    Именно совокупности? Т. е. всех сразу?
    • 0
      Да, я имел в виду, что, когда мы имеем совокупность (в смысле «группу объектов»), скажем, из двух зеркалируемых копий данных, расположенных на двух одинаковых по характеристикам дисках, то вероятность сбоя отдельного диска в целой группе будет больше, чем в случае единственного диска, просто за счет того, что объектов больше. При этом надежность такой группы выше, чем у единственного диска, потому что сбой отдельного диска в такой зеркалированной группе не является критическим событием (ведь копия данных осталась на втором диске), а вероятность одновременного сбоя всех дисков в группе — меньше пропорционально степенной функции (то есть квадрату, кубу и т.д. вероятностей сбоя отдельных дисков).

      Говоря проще: когда у вас два автомобиля, а не один, то вы среднестатистически за год в два раза чаще посещаете сервис (то с одной, то с другой машиной), при этом вероятность остаться вообще без средства передвижения в некий день у вас квадратично ниже, чем в случае одного автомобиля. (Иными словами за надежность группы машин выше)

      Нашел небольшую статью на эту тему (англ. яз.): "RAID1 increases chances of disk failure".
      • +1
        Да, так, но тогда приведенная мной цитата из вашего поста некорректна.

        Сравните.
        "… то получаете утроение вероятности сбоя данной совокупности копий" vs «то вероятность сбоя отдельного диска в целой группе будет больше, чем в случае единственного диска, просто за счет того, что объектов больше.»
        Ко второй цитате претензий нет, первую можно понять так, что сбой элемента группы фатален для всей группы, что, конечно же не так.

        Было бы точней что-то типа "… то получаете утроение вероятности сбоя отдельного элемента из данной совокупности копий", но вероятность для совокупности как единого объекта не растет, а уменьшается по такой-то зависимости.

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

Самое читаемое Разное