Тенденции резервного копирования — «золотой век» дискет и современный взгляд на сетевой бэкап

в 7:35, , рубрики: backup, flash, бекап, Блог компании Acronis, Inc, бэкап, дискета, жесткий диск, ит-инфраструктура, резервное копирование, тенденции

Тенденции резервного копирования — «золотой век» дискет и современный взгляд на сетевой бэкап - 1
Плёночный архив, почти современность

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

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

Проблема резервного копирования данных начала остро вставать, пожалуй, только в последние века. Конечно, в Египте, Древней Греции, в отдельных древних государствах на территории современного Китая были бумажные или папирусные библиотеки, но как таковой индустрии бэкапа не существовало.

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

Тенденции резервного копирования — «золотой век» дискет и современный взгляд на сетевой бэкап - 2

Напомню, дискета представляла собой конверт с антифрикционными прокладками, внутри которого находился пластиковый диск с магнитным покрытием. Фактически развитие технологии магнитной плёнки, но только с заменой, собственно, плёнки на диск. Считывалась дискета с помощью головки дисковода, фактически скользящей по поверхности диска. Дискеты по мере использования могли резко уйти в отказ из-за физического износа. Чем больше вы читаете или пишете, тем больше царапин остаётся на диске от плохо откалиброванной головки дисковода, от того, что диск пошёл волной после хранения или транспортировки и начал натыкаться на головку, просто от того, что он крутится внутри конверта. Любая пылинка, попадающая внутрь конверта, становилась источником царапин, не критичных для данных, но всё же неприятных. Вторая проблема была в хранении — дискеты размагничивались. Некоторые могли выдержать и десятилетия, но гораздо чаще отказывали за 2-3 года.

До появления жёстких дисков с дискет грузились, на них работали как на основном системном диске, и нормальной практикой было размещение в системном блоке двух дисководов: одного для дискеты с ОС, второго — для рабочих данных. Если софт был большой, то приходилось играть во «вставьте диск 2». Например, забегая вперёд, наша система резервного восстановления помещалась на 4 дискетах формата 3,5 дюйма, по 1,44 мегабайта, надо было вставлять их по очереди по мере загрузки.

Важный культурный момент. Обратите внимание, в том же «домашнем» DOS у файла было четыре атрибута: скрытый, только для чтения, системный и архивный. Read-only понятно для чего, скрытый — чтобы пользователь случайно не наткнулся, системный — это связка RO и скрытого плюс особые предупреждения от ОС при действиях с файлом, а архивный — это флаг того, что файл был забэкаплен. При изменении файла атрибут снимался, и файл снова подлежал копированию на дискету в конце недели.

Тенденции резервного копирования — «золотой век» дискет и современный взгляд на сетевой бэкап - 3

Обычная ёмкость 5,25-дискеты составляла сначала 180 килобайт, потом «народные» 360 килобайт, а потом — 1,2 мегабайта. При этом сам диск позволял по факту записать больше: например, на 360-килобайтной дискете была возможность хранить больше 500 килобайт. Народный «лайфхак» выглядел так: берёте 360-килобайтную дискету и форматируете её под 1,2 мегабайта. Потом тщательно проверяете тем же «Скандиском» или «Диск Дестроером Доктором». Получается чуть больше места для записи. Записываете, несёте другу по флоппонету, быстро копируете — и вот удалось сделать, что хотелось, за один поход.

Потом появилась довольно удачная для бэкапа пара из небольшого жёсткого диска и дискет. 20 и 50-мегабайтные HDD, распространённые в серии 386-х персональных компьютеров, казались тогда просто бесконечностью. Целиком забэкапить их на дискеты было довольно сложно, поэтому сохранялись только ключевые данные.

Чуть раньше этого периода широкое распространение получил бэкап больших некритичных данных на видеоплёнку, то есть на обычные видеокассеты. Использовалось специальное устройство, способное писать на магнитную плёнку и корректировать ошибки. Поскольку процент ошибок чтения просто потрясал, использовался довольно высокий уровень избыточности. Собственно, именно на аналоговых технологиях хранения отрабатывались алгоритмы восстановления данных. Самый распространённый способ — писать данные неким развитием кода Хэмминга в N частей, где по любому N-1 (при повреждении одного любого из сегментов) можно восстановить остальное. Технология, наверняка прекрасно знакомая вам по RAID-массивам.

С появлением дискет формата 3,5 дюйма (это гибкие диски с жёстким корпусом) появилась возможность хоть как-то не беспокоиться за то, что при хранении (не чтении-записи, а именно хранении или транспортировке) данные никуда не денутся. Физический корпус хорошо защищал диск от случайных повреждений. Интересно, что долгую жизнь этому носителю в России обеспечила налоговая: они крайне долго принимали отчёты в цифровом виде именно и только на таких дискетах. Возможно, где-то ещё до сих пор так делают. Поэтому они продавались даже в переходах и задорого.

В этот же примерно период получили широкое распространение в домашнем сегменте программы вроде Double Space (он же DrvSpace позже) — то, что мы бы сегодня назвали драйвером для работы с жёстким диском с возможностью записи данных. Все данные, которые поступали на запись, сначала сжимались, все данные чтения сначала разархивировались. Всё это делалось прозрачно для пользователя. Получалось, что из 50-мегабайтного HDD можно было получить 70-мегабайтный. Пользователям нравилось. Естественной проблемой было то, что при повреждении диска убивалось нередко вообще всё, а не только один участок. Наверное, в плане бэкапа важных данных, именно тут произошло важное изменение в сознании обычных пользователей.

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

Предполагалось, что технология магнитной записи будет развиваться и дальше. Появились ZIP-дискеты. Люди их немного пугались: вроде дискета, а вроде можно записать хоть 100 мегабайт. К сожалению (или к счастью), долго они не протянули —японцы в это время уверенно решали задачу записи своей любимой классической музыки в плеер, и магнитные носители не подходили. Появились первые компакт-диски.
Счастливые обладатели первых приводов очень быстро обнаружили в них баг: читать они могли, а вот писать — нет. С появлением пишущих CD-драйвов резко изменилось вообще всё представление о бэкапе. Когда в музыкальные хиты пробился рок-альбом «CD-R» группы «750 мегабайт», бэкап делался достаточно просто. 15 минут в неделю, чтобы забрать реально большие данные — это было круто. У многих были целые библиотеки таких дисков.

К сожалению, они тоже оказались недолговечными. R-болванки (для однократной записи) держались дольше, а RW-диски (многократные), особенно ширпотребные, не очень хорошего качества, «стирались» за 2-3 года лежания в сухом прохладном месте. Поэтому для бэкапа они не годились, и в дата-центрах продолжала использоваться старая добрая магнитная плёнка.

Распространение получили зеркальные RAID’ы.

Где-то в этот момент HDD настолько подешевели, что хранилища стало можно делать на них. Понятно, что технологии, подходы, методология и основные алгоритмы были отработаны давно, но именно в момент поиска новых средств хранения (ставили на оптические носители, flash-память, фантазировали о бионосителях) потребовалось делать надёжные и долговечные вещи на ненадёжном материале. Вся история человечества так и устроена, кстати говоря.

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

Появление и массовое распространение flash-памяти наконец-то изменило сознание — больше никто не рассматривал носители как нечто постоянное. Речь шла о постоянном «трогании» данных, обновлении и перезаписи.

Мы в целом двигались до этого периода по очень понятной парадигме. Первое, что мы начали продавать, — продукт, который имел дружелюбный GUI (редкость для системных утилит в начале 2000-х) и позволял обычному конечному пользователю (не админу) делать бэкап быстро, уметь просто восстанавливаться из него и прививать привычку копировать важные данные. Требовались технологии снепшотов, было много работы с диском на почти физическом уровне, много особенностей ОС. Бэкап делался на внешние носители или соседние жёсткие диски, и в целом всё было предсказуемо. Вот тут есть чуть больше деталей от одного из наших первых сотрудников.

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

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

Очевидно, следующая идея, которая прямо проистекает из современных тенденций виртуализации и распределения данных — это отвязка данных от терминалов домашних пользователей. Уже сейчас они прекрасно знакомы с тем, как бэкап с телефона можно накатить на новую «трубку» (и всё будет точно таким же), видят свои файлы из командировки при доступе к бэкапу через веб-агента, пользуются тем же «Яндекс.Диском» или «Дропбоксом», и в целом готовы отдавать данные в сеть относительно свободно. Каналы тоже уже доросли, если не считать прыгающую через спутник Камчатку, у нас в России с интернетом почти везде почти порядок. И благодаря распространению 3G и LTE нормальный канал есть почти везде на планете.

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

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

Если интересно

То заглядывайте в Beta Acronis True Image 2017

Автор: Acronis

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js