Для чего нужно сохранять резервные копии
Резервное копирование: где, как и зачем?
Защита данных предполагает наличие бэкапа — резервных копий, из которых можно выполнить их восстановление. Для большинства компаний и организаций резервное копирование данных относится к числу наиболее важных приоритетов. Около половины компаний работают со своими данными как со стратегическим активом. И ценность хранимых данных постоянно растет. Их используют для повышения качества обслуживания клиентов, поддержки текущей деятельности, исследований и разработок, учета, они задействованы в системах автоматизации, интернета вещей, искусственного интеллекта и др. Поэтому задача защиты данных от аппаратных сбоев, человеческих ошибок, вирусов и кибератак становится крайне актуальной.
В мире наблюдается рост киберпреступности. В прошлом году более 70% компаний подверглись кибератакам. Компрометация персональных данных клиентов и конфиденциальных файлов может иметь серьёзные последствия и приводить к огромным убыткам.
Вместе с тем появляется культура работы с данными, понимание того, что данные – это ценный ресурс, с помощью которого компания может получать дополнительную прибыль или сокращать издержки, а вместе с этим — и желание обеспечить надежную защиту своих данных.
Вариантов резервирования несколько: локальное или удаленное хранение резервных копий на собственной площадке, облачное хранение или бэкапы у хостинг-провайдеров.
Хранить и защищать
Как показывают результаты опросов, примерно четверть респондентов выполняет резервирование данных ежемесячно, столько же – еженедельно, и более четверти – ежедневно. И это вполне оправдано: в результате такой предусмотрительности почти 70% организаций избежали в минувшем году простоев из-за потери данных. В этом им помогают совершенствующиеся программные инструменты и сервисы.
Согласно исследованию IDC мирового рынка программного обеспечения репликации защиты данных (Data Replication and Protection), его продажи в мире будут расти с 2018 по 2022 годы ежегодно на 4,7% и достигнут 8,7 млрд. долларов. Аналитики DecisionDatabases.com в своем отчете (Global Data Backup Software Market Growth 2019-2024) пришли к выводу, что в ближайшие пять лет среднегодовые темпы роста мирового рынка программного обеспечения резервного копирования данных будут составлять 7,6%, и в 2024 году его объем достигнет 2,456 млрд. долларов против 1,836 млрд. долларов в 2019 году.
В октябре 2019 года Gartner представила «магический квадрант» по программному обеспечению резервного копирования и восстановления ИТ-систем дата-центров. Ведущими вендорами этого ПО стали Commvault, Veeam, Veritas, Dell EMC и IBM.
При этом растет популярность облачного резервного копирования: продажи таких продуктов и сервисов, по прогнозам, будут расти более чем вдвое быстрее рынка программного обеспечения защиты данных в целом. По прогнозу Gartner, уже в этом году до 20% предприятий будут использовать резервное копирование в облако.
По прогнозам Marketintellica, мировой рынок ПО для создания и хранения резервных копий на своей (on premises) и на сторонней площадке (off-site) в ближайшей перспективе будет стабильно расти.
По информации IKS Consulting, в России сегмент «облачное резервное копирование как сервис» (BaaS) увеличивается в среднем на 20% в год. По данным опроса Acronis 2019 года, компании все чаще полагаются именно на облачное резервное копирование: его используют более 48% респондентов, а около 27% предпочитают комбинировать облачное и локальное резервное копирование.
Требования к системам резервного копирования
Тем временем требования к программному обеспечению резервного копирования и восстановления данных меняются. Чтобы успешнее решать задачи защиты данных и оптимизировать расходы, компании готовы приобретать более простые, гибкие и недорогие решения, считают аналитики Gartner. Привычные методы защиты данных не всегда соответствуют новым требованиям.
Системы резервного копирования и восстановления данных должны предусматривать простое развертывание и администрирование, удобное управление процессом резервирования и восстановления, оперативное восстановление данных. Современные решения нередко реализуют функции репликации данных, позволяют автоматизировать операции, предусматривают интеграцию с облаками, встроенные функции архивирования, поддерживают аппаратные снимки данных.
По прогнозу Gartner, в ближайшие два года до 40% компаний перейдут на новые решения резервного копирования, заменив имеющееся ПО, а многие будут использовать одновременно несколько продуктов или сервисов, оптимально защищающих те или иные системы. Чем же их не устраивают прежние решения резервного копирования и восстановления данных?
Все в одном
Аналитики полагают, что в результате такого перехода компании получают более гибкие, масштабируемые, простые и производительные системы, нередко представляющие собой унифицированное программное обеспечения для управления данными и их хранения. Усовершенствованные продукты резервного копирования и восстановления включают в себя инструменты эффективного управления данными, дают возможность перемещать данные туда, где их хранение наиболее эффективно (в том числе автоматически), управлять ими, защищать и восстанавливать.
С ростом разнообразия и объемов данных важным требованием становится комплексная защита и управление данными: файлами, базами данных, данными виртуальных и облачных сред, приложений, а также доступ к различным типам данных в первичных, вторичных и облачных хранилищах.
Комплексные решения управления данными обеспечивают единое управление ими в масштабе всей ИТ-инфраструктуры: их резервное копирование, восстановление, архивирование и управления моментальными снимками. Однако администраторы должны четко понимать, где, как долго и какие данные хранятся, какие к ним применяются политики. Быстрое восстановление приложений, виртуальных машин и рабочих нагрузок из локального или облачного хранилища данных минимизирует простои, а автоматизация позволяет свести к минимуму ошибки из-за человеческого фактора.
Крупные организации с комбинацией унаследованных, традиционных и современных приложений нередко выбирают системы резервного копирования, поддерживающие широкий спектр операционных систем, приложений, гипервизоров и реляционных баз данных, обладающие высокой масштабируемостью (до нескольких петабайт и тысяч клиентов), а также предусматривающих интеграцию с широким спектром систем хранения данных, публичных, частных и гибридных облаков и ленточных накопителей.
Как правило, это платформы с традиционной трехуровневой архитектурой из агентов, медиа-серверов и сервера управления. Они могут объединять функции резервного копирования и восстановления, архивирования, аварийного восстановления (DR) и облачного резервного копирования, оптимизировать производительность, используя алгоритмы искусственного интеллекта и машинного обучения.
Как считают в компании Forrester, централизованное управление источниками данных, политиками, способность к надежному восстановлению данных и безопасность являются наиболее важными характеристиками решений резервного копирования.
Современные решения могут с любой периодичностью выполнять резервное копирование виртуальных машин на основе моментальных снимков практически без снижения производительности рабочих сред. Они ликвидируют разрыв между целевой точкой восстановления (Recovery Point Objective, RPO) и целевым временем восстановления (Recovery Time Objective, RTO), гарантируют доступность данных в любое время и обеспечивают непрерывность бизнеса.
Рост объемов данных
Тем временем в мире продолжается экспоненциальный рост объема создаваемых данных, и в ближайшие годы эта тенденция сохранится. По прогнозу IDC, объем создаваемых за год данных вырастет с 2018 до 2025 годы с 33 до 175 ЗБ. Среднегодовые темпы роста превысят 27%. На этот рост влияет и увеличение числа пользователей интернета. В прошлом году интернетом пользовались 53% населения Земли. Число пользователей интернета ежегодно увеличивается на 15-20%. Новые и развивающиеся технологии, такие как 5G, видео UHD, аналитика, IoT, искусственный интеллект, AR/VR, влекут за собой генерацию все больших объемов данных. Источниками роста объема данных также являются также развлекательный контент и видео с камер систем видеонаблюдения. Например, рынок хранения видео с камер наблюдения, по прогнозам MarketsandMarkets, будет расти на 22,4% в год и достигнет в этом году 18,28 млрд долларов.
Экспоненциальный рост объемов создаваемых данных.
За последние два-три года объемы корпоративных данных выросли примерно на порядок. Соответственно, усложнилась задача резервного копирования. Емкости хранилищ данных достигают сотен терабайт и продолжают увеличиваться по мере накопления данных. Потеря даже части этих данных может сказаться не только на бизнес-процессах, но и повлиять на репутацию бренда или на лояльность клиентов. Поэтому создание и хранение бэкапов в значительной мере влияет на весь бизнес.
Сориентироваться в предложениях вендоров, предлагающих свои варианты резервного копирования, бывает нелегко. Существуют разные варианты создания и хранения резервных копий, но наиболее популярными являются локальные системы резервного копирования и использования облачных сервисов. Резервное копирование в облако или в ЦОД провайдера обеспечивает надежную защиту данных и минимизирует риски, связанные с программными сбоями, техническими неисправностями оборудования и ошибками сотрудников.
Миграция в облака
Данные можно накапливать и хранить в собственных центрах обработки данных, но при этом придется обеспечить отказоустойчивость, кластеризацию и масштабирование емкости, иметь в штате квалифицированных специалистов по администрированию систем хранения. В этих условиях передача всех подобных вопросов на аутсорсинг провайдеру очень актуальна. Например, при размещении баз данных в ЦОД провайдера или в облаке можно возложить ответственность за хранение, резервирование данных, функционирование баз данных на профессионалов. Провайдер будет нести финансовую ответственность по соглашению об уровне обслуживания. Помимо прочего это позволяет быстро развернуть типовую конфигурацию для решения конкретной задачи, а также обеспечить высокую степень доступности за счёт резервирования вычислительных ресурсов и резервного копирования.
В 2019 году объем мирового рынка облачного резервного копирования составил 1834,3 млн. долл., и ожидается, что к концу 2026 года он достигнет 4229,3 млн. долл. при среднегодовом росте 12,5%.
При этом все больше данных будет храниться не в корпоративных сетях и не на конечных устройствах, а в облаке, причем, согласно IDC, доля данных в публичных облаках вырастет к 2025 году до 42%. Более того, организации переходят к использованию мультиоблачных инфраструктур и гибридных облаков. Такого подхода придерживаются уже 90% европейских компаний.
Облачное резервное копирование представляет собой стратегию резервного копирования данных, которая включает отправку копии данных по сети на сервер за пределами собственной площадки. Обычно это сервер сервис-провайдера, который взимает с клиента плату на основе выделенной емкости, пропускной способности или количестве пользователей.
Широкое внедрение облачных технологий и необходимость управления большими объемами данных способствуют росту популярности облачных решений для резервного копирования. Кроме того, с внедрением облачных решений резервного копирования связывают такие преимущества как простое управление и мониторинг, резервное копирование и восстановление в режиме реального времени, простая интеграция облачного резервного копирования с другими корпоративными приложениями, дедупликация данных и поддержка различных клиентов.
Ключевыми игроками данного рынка аналитики считают компании Acronis, Asigra, Barracuda Networks, Carbonite, Code42 Software, Datto, Druva Software, Efolder, IBM, Iron Mountain и Microsoft.
Мультиоблачные среды
Поставщики систем хранения данных делают все возможное, чтобы их продукты эффективно работали в мультиоблачной среде. Задача — упростить использование данных и перемещать их туда, где они необходимы, а их хранение — наиболее эффективно. Например, они применяют распределенные файловые системы следующего поколения, которые поддерживают единое пространство имен, обеспечивая доступ к данным в разных облачных средах, предлагают общие стратегии и политики управления в разных облаках и на локальном уровне. Конечная цель состоит в управлении, защите и эффективном использовании данных, где бы они ни находились.
Мониторинг — еще одна из проблем мультиоблачного хранения. Нужны инструменты мониторинга для отслеживания результатов в мультиоблачной среде. Независимый инструмент мониторинга, разработанный для нескольких облаков, позволит получить общую картину.
Прогноз роста мирового рынка систем управления мультиоблачными средами.
Совмещение периферийного и мультиоблачного хранения – также непростая задача. Чтобы эти системы эффективно работали вместе, нужно знать объемы и типы данных, где и как эти данные будут собираться, передаваться и сохраняться. Для планирования процесса потребуется также знать, как долго должны храниться данные каждого типа, где, когда и сколько данных нужно будет передавать между различными системами и облачными платформами, как осуществляется их резервное копирование и защита.
Все это поможет администраторам свести к минимуму сложности, связанные с объединением периферийного и мультиоблачного хранения.
Данные на периферии
Еще один тренд – периферийные вычисления. Как считают аналитики Gartner, в ближайшие годы около половины всех корпоративных данных будут обрабатываться за пределами традиционных ЦОД или облачной среды: все более значительная их доля размещается на периферии — для хранения и локальной аналитики. По прогнозу IDC, в регионе EMEA доля «периферийных» данных вырастет почти вдвое — с 11% до 21% от общего объема. Причины — распространение интернета вещей, перенос аналитики и обработки данных ближе к их источнику.
Переход от облачных и централизованных вычислений к периферийным вычислениям уже начался. Такие системы становятся все более востребованными. Затраты и сложность создания централизованной архитектуры для обработки большого объема данных чрезмерно велики, такая система может стать плохо управляемой по сравнению с распределением обработки данных по периферии или на соответствующем уровне сети. Кроме того, на периферии можно объединять или деперсонализировать данные перед отправкой в облако.
Данные за границей
Некоторые компании предпочитают хранить данные за рубежом, считая такой вариант надежной защитой данных от несанкционированного доступа и важным фактором снижения риска. Данные за границей – это гарантия защиты ценной информации. Размещенное за рубежом оборудование не находится под российской юрисдикцией. А благодаря шифрованию сотрудники ЦОД могут вообще не иметь доступа к вашим данным. В современных зарубежных дата-центрах используется высоконадежное оборудование, обеспечиваются высокие показатели надежности на уровне ЦОД в целом.
Использование иностранных ЦОД может иметь и ряд других преимуществ. Клиент застрахован от рисков, связанных с форс-мажорами или недобросовестной конкуренцией. Использование таких площадок для хранения и обработки данных позволит минимизировать подобные риски. Например, в случае изъятия серверов в России компания сможет сохранить копию своих систем и данных в зарубежных ЦОД.
Как правило, ИТ-инфраструктура зарубежных ЦОД – это стандарты качества, высокий уровень безопасности и контроля хранения данных. В них используются новейшие ИТ-решения, межсетевые экраны, технологии шифрования каналов связи, средства защиты от DDoS-атак. Энергообеспечение ЦОД также реализовано с высоким уровнем надежности (до TIER III и IV).
Резервное копирование в зарубежных ЦОД актуально для любого бизнеса в РФ, не работающего с персональными данными пользователей, хранение и обработка которых, согласно закону № 152-ФЗ «О персональных данных», должна осуществляться на территории России. Эти требования можно выполнить путем развертывания двух площадок: основной в России, где происходит первичная обработка данных, и зарубежной, где размещаются резервные копии.
Зарубежные площадки нередко используют и в качестве резервного ЦОД. Тем самым достигается максимальная безопасность и надежность, минимизируются риски. В ряде случаев они удобны для размещения данных и подключения к ним европейских клиентов. При этом достигается лучшее время отклика для европейских пользователей. Такие дата-центры имеют прямой доступ к европейским точкам обмена трафиком. Мы например предлагаем своим клиентам сразу 4 точки размещения данных в Европе — это Цюрих (Швейцария), Франкфурт (Германия), Лондон (Великобритания) и Амстердам (Нидерланды).
Что нужно учитывать при выборе дата-центра?
Используя услуги коммерческих ЦОД, помимо удобной структуры расходов, бизнес получает более гибкий сервис, который можно масштабировать в режиме реального времени, а оплачиваются только потребляемые ресурсы (pay-per-use). Услуги внешнего ЦОД также позволяют снизить риски, связанные с неопределенностью будущего, легко адаптировать ИТ к новым технологическим трендам, сосредоточиться на своих ключевых бизнес-процессах, а не на обслуживании ИТ-инфраструктуры.
Провайдеры учитывают при строительстве и эксплуатации своих площадок лучшие практики и международные стандарты, предъявляющие высокие требования к инженерным и ИТ-системам ЦОД, такие как ISO 27001:2013 Information Security Management (управление информационной безопасностью), ISO 50001:2011 Energy Management System (эффективное планирование систем энергоснабжения дата-центра), ISO 22301:2012 Business Continuity Management System (обеспечение непрерывности бизнес-процессов ЦОД), а также европейские стандарты EN 50600-x, стандарт PCI DSS, касающийся безопасности обработки и хранения данных пластиковых карт международных платежных систем.
В результате заказчик получает отказоустойчивый сервис, обеспечивающий надежный надежное хранение данных и непрерывность бизнес-процессов.
Резервное копирование, часть 1: Назначение, обзор методов и технологий
Идеальная программа работает быстро, не течет по оперативной памяти, не имеет дыр и не существует.
Поскольку программы все еще пишутся белковыми разработчиками, а процесс тестирования зачастую отсутствует, плюс поставка программ крайне редко происходит с применением «best practices» (которые сами по себе тоже программы, а следовательно, неидеальны), системным администраторам чаще всего приходится решать задачи, которые звучат кратко, но емко: «вернуть, как было», «привести базу к нормальной работе», «медленно работает — откатываем», а также мое любимое «не знаю что, но почини».
Кроме логических ошибок, которые вылезают в результате небрежной работы разработчиков, либо стечения обстоятельств, а также неполного знания или непонимания мелких особенностей построения программ — в том числе связующих и системных, включая операционные системы, драйвера и прошивки, — есть еще и другие ошибки. Например большинство разработчиков полагается на рантайм, совершенно забывая о физических законах, обойти которые с помощью программ все еще невозможно. Это и бесконечная надежность дисковой подсистемы и вообще любой подсистемы хранения данных (включая оперативную память и кэш процессора!), и нулевое время обработки на процессоре, и отсутствие ошибок при передаче по сети и при обработке на процессоре, и задержки сети, которые равны 0. Не стоит пренебрегать и пресловутым дедлайном, ведь если к нему не успеть — будут проблемы почище нюансов работы сети и диска.
Как же быть с проблемами, которые встают в полный рост и нависают над ценными данными? Живых разработчиков заменить нечем, да и не факт, что можно будет в ближайшее время. С другой стороны, полностью доказать, что программа будет работать как задумано, пока что получилось только у нескольких проектов, и совершенно не обязательно можно будет взять и применить доказательства на другие, схожие проекты. Также подобные доказательства занимают уйму времени, и требуют особых навыков и знаний, а это практически сводит к минимуму возможность их применения с учетом дедлайнов. К тому же мы еще не умеем в сверхбыструю, дешевую и бесконечно надежную технологию хранения, обработки и передачи информации. Подобные технологии, если и существуют, то в виде концептов, либо — чаще всего — только в фантастических книгах и фильмах.
Хорошие художники копируют, великие художники воруют.
Самые удачные решения и удивительно простые вещи обычно происходят там, где встречаются абсолютно несовместимые, на первый взгляд, понятия, технологии, знания, области наук.
Например, у птиц и у самолетов есть крылья, однако несмотря на функциональную схожесть — принцип действия в некоторых режимах совпадает, и технические проблемы решаются аналогично: полые кости, использование прочных и легких материалов и т.п., — результаты абсолютно разные, хоть и весьма похожие. Лучшие образцы, которые мы наблюдаем в нашей технике, также по большей части заимствованы у природы: герметичные отсеки у кораблей и подводных лодок — прямая аналогия с кольчатыми червями; построение raid-массивов и проверка целостности данных — дублирование цепочки ДНК; а также парные органы, независимость работы разных органов от ЦНС (автоматия работы сердца) и рефлексы — автономные системы в Интернет. Конечно брать и применять готовые решения «в лоб» чревато проблемами, но кто знает, может, других решений-то и нет.
Знать бы, где упадешь — соломки подстелил бы!
—Белорусская народная пословица
Значит, резервные копии жизненно необходимы тем, кто желает:
Любая классификация произвольна. Природа не классифицирует. Классифицируем мы, потому что для нас так удобнее. И классифицируем по данным, которые мы берем также произвольно.
Независимо от физического способа хранения логическое хранение данных можно условно разделить по 2 способам доступа к этим данным: блочное и файловое. Такое деление в последнее время весьма размыто, ведь чисто блочных, как и чисто файловых, логических хранилищ не существует. Однако для простоты будем считать, что они есть.
Блочное хранение данных подразумевает, что есть физическое устройство, куда записывают данные некоторыми фиксированными порциями, блоками. Доступ к блокам идет по некоторому адресу, каждому блоку соответствует свой адрес в пределах устройства.
Резервная копия обычно делается путем копирования блоков данных. Для обеспечения целостности данных на момент копирования приостанавливается запись новых блоков, а также изменение существующих. Если брать аналогию из обычного мира — ближе всего шкаф с одинаковыми пронумерованными ячейками.
Файловое хранение данных по принципу логического устройства близко к блочному и зачастую организуется поверх. Важные различия — наличие иерархии хранения и человекопонятные имена. Выделяется абстракция в виде файла — именованной области данных, а также каталога — специального файла, в котором хранятся описания и доступы к другим файлам. Файлы могут снабжаться дополнительными метаданными: время создания, флаги доступа и т.п. Резервируют обычно так: ищут измененные файлы, потом копируют их в другое, одинаковое по структуре файловое хранилище. Целостность данных обычно реализуют путем отсутствия файлов, в которые идет запись. Метаданные файлов резервируются аналогично. Ближайшая аналогия — библиотека, в которой есть разделы с разными книгами, а также есть каталог с человекопонятными именами книг.
В последнее время иногда описывают еще один вариант, с которого, в принципе, и началось файловое хранение данных, и у которого есть те же архаичные черты: объектное хранение данных.
От файлового хранения отличается тем, что не имеет вложенности больше одного (плоская схема), а имена файлов хотя и человекочитаемые, но все же больше приспособлены для обработки машинами. При резервном копировании объектные хранилища чаще всего обрабатывают подобно файловым, но изредка есть и другие варианты.
— Есть два вида системных администраторов, те кто не делает резервные копии, и те, кто УЖЕ делает.
— На самом деле три вида: есть еще те, кто проверяет, что резервные копии можно восстановить.
Также стоит понимать, что сам процесс резервного копирования данных осуществляется программами, поэтому ему присущи все те же минусы, как и другой программе. Чтобы убрать (не исключить!) зависимость от человеческого фактора, а также особенностей — которые по отдельности не сильно влияют, но вместе могут дать ощутимый эффект, — применяют т.н. правило 3-2-1. Есть много вариантов, как его расшифровать, но мне больше нравится следующая трактовка: хранить надо 3 набора одних и тех же данных, 2 набора надо хранить в разных форматах, а также 1 набор надо иметь на географически удаленном хранилище.
Под форматом хранения следует понимать следующее:
С точки зрения готовности резервной копии по ее прямому назначению — восстановлению работоспособности, — различают «горячие» и «холодные» резервные копии. Горячие от холодных отличаются только одним: они сразу же готовы к работе, в то время как холодные для восстановления требуют некоторых дополнительных действий: расшифровки, извлечения из архива и т.п.
Не стоит путать горячие и холодные копии с online и offline копиями, которые подразумевают физическую изоляцию данных, и по сути, являются другим признаком классификации способов резервного копирования. Так offline копия — не подключенная непосредственно к системе, где ее надо восстановить, — может быть как горячей, так и холодной (с точки зрения готовности к восстановлению). Online копия может быть доступна непосредственно там, где ее надо восстанавливать, и чаще всего является горячей, но бывают и холодные.
Кроме того, не стоит забывать, что сам процесс создания резервных копий обычно не заканчивается на создании одной резервной копии, а копий может быть достаточно большое число. Следовательно, надо различать полные резервные копии, т.е. те, которые восстановимы независимо от других резервных копий, а также разностные (инкрементальные, дифференциальные, декрементальные и т.п.) копии — те, которые не могут быть восстановлены самостоятельно и требуют предварительного восстановления одной или нескольких других резервных копий.
Разностные инкрементальные копии — попытка сэкономить размер пространства для хранения резервных копий. Таким образом в резервную копию пишутся только измененные данные с прошлой резервной копии.
Разностные декрементальные создаются с той же целью, но немного другим путем: делается полная резервная копия, но реально хранится только разница между свежей копией и предыдущей.
Отдельно стоит рассмотреть процесс резервного копирования поверх хранилища, которое поддерживает отсутствие хранения дубликатов. Таким образом, если писать полные резервные копии поверх него, реально будет записана только разница между резервными копиями, однако процесс восстановления резервных копий будет происходить аналогично восстановлению с полной копии и полностью прозрачно.
(Кто устережет самих сторожей? — лат.)
Весьма неприятно, когда резервных копий нет, однако гораздо хуже, если резервная копия вроде бы и сделана, но при восстановлении выясняется, что она не может быть восстановлена, потому что:
Правильно построенный процесс резервного копирования обязан учитывать подобные замечания, особенно первые два.
Целостность исходных данных можно гарантировать несколькими способами. Наиболее часто используются следующие: а) создание слепков файловой системы на блочном уровне, б) «заморозка» состояния файловой системы, в) особое блочное устройство с хранением версий, г) последовательная запись файлов или блоков. Также применяются контрольные суммы, чтобы обеспечивать проверку данных при восстановлении.
Повреждения хранилища также можно обнаружить с помощью контрольных сумм. Дополнительный метод — применение специализированных устройств, либо файловых систем, в которых нельзя изменять уже записанные данные, но можно дописывать новые.
Для ускорения восстановления применяется восстановление данных с несколькими процессами для восстановления — при условии, что нет «бутылочного горлышка» в виде медленной сети или небыстрой дисковой системы. Для того, чтобы обойти ситуацию с частично восстановленными данными, можно разбить процесс резервного копирования на относительно небольшие подзадачи, каждая из которых выполняется отдельно. Таким образом, появляется возможность последовательно восстановить работоспособность с прогнозированием времени восстановления. Данная проблема чаще всего лежит в огранизационной плоскости (SLA), поэтому не будем останавливаться на этом подробно.
Знает толк в пряностях не тот, кто добавляет их в каждое блюдо, но тот, кто никогда не добавит в него ничего лишнего.
Практика в части применяемого ПО у системных администраторов может различаться, но общие принципы все равно, так или иначе, те же, в частности:
Для снятия резервных копий с блочных устройств есть следующие распостраненные программы:
Для файловых систем задача резервного копирования частично решается с помощью методов, применимых для блочных устройств, однако задачу можно решить и более эффективно, используя, например:
Итак, для небольшого сервера нужно обеспечить схему резервного копирования, отвечающую следующим требованиям:
В качестве тестового стенда будет применяться виртуальная машина (на базе XenServer) со следующими характеристиками:
Операционная система — Centos 7 x64: разбивка стандартная, дополнительный раздел будет использоваться как источник данных.
В качестве исходных данных возьмем сайт на wordpress, с медиафайлами размером 40 гб, базой данных на mysql. Так как виртуальные сервера весьма сильно различаются по характеристикам, а также для лучшей воспроизводимости, здесь есть
Prime numbers limit: 20000
Initializing worker threads…
CPU speed:
events per second: 836.69
Throughput:
events/s (eps): 836.6908
time elapsed: 30.0039s
total number of events: 25104
Latency (ms):
min: 2.38
avg: 4.78
max: 22.39
95th percentile: 10.46
sum: 119923.64
Threads fairness:
events (avg/stddev): 6276.0000/13.91
execution time (avg/stddev): 29.9809/0.01
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads…
Total operations: 50900446 (1696677.10 per second)
49707.47 MiB transferred (1656.91 MiB/sec)
Throughput:
events/s (eps): 1696677.1017
time elapsed: 30.0001s
total number of events: 50900446
Latency (ms):
min: 0.00
avg: 0.00
max: 24.01
95th percentile: 0.00
sum: 39106.74
Threads fairness:
events (avg/stddev): 12725111.5000/137775.15
execution time (avg/stddev): 9.7767/0.10
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads…
Total operations: 35910413 (1197008.62 per second)
35068.76 MiB transferred (1168.95 MiB/sec)
Throughput:
events/s (eps): 1197008.6179
time elapsed: 30.0001s
total number of events: 35910413
Latency (ms):
min: 0.00
avg: 0.00
max: 16.90
95th percentile: 0.00
sum: 43604.83
Threads fairness:
events (avg/stddev): 8977603.2500/233905.84
execution time (avg/stddev): 10.9012/0.41
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads…
Throughput:
read: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
write: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latency (ms):
min: 0.00
avg: 0.27
max: 18.01
95th percentile: 1.08
sum: 238469.45