0 / 0 / 0
Регистрация: 13.09.2015
Сообщений: 5
1

Идея бэкапа с двойной экономией места (по аналогу RAID)

13.09.2015, 22:10. Показов 1697. Ответов 9
Метки нет (Все метки)

Доброго дня всем! Недавно появилась у меня конгениальная идея как можно сделать бэкап информации, сэкономив в 2 раза (или даже больше) на размере бэкапа.

Опишу вкратце. Может кто знает, есть ли в природе программа которая такое делает? Если нет, то может что-то подобное стоит реализовать подручными средствами или программированием?

Допустим есть у меня два жестких диска на которых хранится информация которую я хочу забэкапить. Главное условие что интересующие меня файлы - архивные и меняться или удаляться не будут (видеоархив, музыкальный архив, библиотека и т.д.)
Пусть например на первом диске есть папка с названием A1, а на втором диске папка с названием A2. Папки примерно одинаковы по объему (допустим 100 Гб).

Что нужно сделать для бэкапа:
1. В каждой из этих папок нужно создать файл CheckSum.md5, в котором будут списки архивируемых файлов с их контрольными суммами.
2. Потом согласно этому списку условно говоря нужно сложить (присоединить) эти файлы в два больших виртуальных файла A1.SUM и A2.SUM и провести над этими двумя файлами логическую операцию XOR (взаимоисключающего ИЛИ). В итоге получится файл,назовем его A12.XOR.
3. Теперь этот полученный файл надо сохранить на третий жесткий диск (диск для бэкапа).

Для справки:
Xor обладает особенностью, которая даёт возможность заменить любой операнд результатом, и, применив алгоритм xor, получить в результате недостающий операнд. Например: a xor b = c (где a, b, c — три диска рейд-массива), в случае если a откажет, мы можем получить его, поставив на его место c и проведя xor между c и b: c xor b = a. Это применимо вне зависимости от количества операндов: a xor b xor c xor d = e. Если отказывает c тогда e встаёт на его место и проведя xor в результате получаем c: a xor b xor e xor d = c. Этот метод по сути обеспечивает отказоустойчивость 5-й версии RAID. Для хранения результата xor требуется всего 1 диск, размер которого равен размеру любого другого диска в raid.
Что мы получили в итоге? Имеется три жестких диска, два из которых хранят нужную информацию в оригинальном виде, а третий хранит информацию для восстановления.
Если один из жестких дисков выйдет из строя, то информацию можно будет восстановить из двух оставшихся жестких дисков.

В чем преимущество такого подхода в сравнении с RAID 5 из трех дисков?
1. Все три диска могут быть внешними и отсоединяться.
2. Информация на первых двух дисках доступна даже если подключать диски по-одному. В то время как RAID работает только когда все диски подключены и объединены в один общий массив. Получается что если выйдут из строя два диска, один из которых бэкапный, то хотя бы половина информации останется целой.
3. Неподключенные жесткие диски не изнашиваются.
4. При восстановлении информации можно действовать выборочно и с перерывами, чтобы не перенагружать сохранившиеся жесткие диски интенсивным чтением, и тем самым не повышать вероятность выхода их из строя в этот неподходящий момент. В то время как при перестройке RAID-массива диски нагружаются на всю катушку.
5. На дисках можно создавать новые файлы, изменять или удалять файлы, которые не прописаны в файлах CheckSum.MD5. Это не повлияет на сохранность забэкапленной информации.

Ну вот примерно так. Кто что думает по-этому поводу? Существует ли софт, который реализует такое?
Т.е. смысл всего этого в том чтобы в два раза сэкономить место для бэкапа. И кроме того бэкап можно хранить где-нибудь на сетевом ресурсе и вообще не использовать его в работе, в отличие от RAID, где надо держать диск подключенным.

Конечно можно еще большей экономии добиться, если использовать не 3 диска, а больше - например цепочку из 5 или 6 дисков. Только это уже будет малопрактично если диски внешние и их надо будет присоединять вручную. А с тремя дисками еще можно как-то управляться, подключив их одновременно или скопировав с них нужные файлы на встроенный диск в ноутбуке.
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
0
Лучшие ответы (1)
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
13.09.2015, 22:10
Ответы с готовыми решениями:

Аналогу system()
Написал программу с использованием system(" *>E:/1.txt"). Но тут проблема, при выполнении мелькает...

Разработать программу, генерирующую случайное число по аналогу игральной кости
Задание: Разработать программу генерирующее случайное число по аналогу игральной кости. Программа...

Контроллер MegaRAID 9240-8i RAID Controller Card | SAS RAID | LSI
Имеется контроллер MegaRAID 9240-8i RAID Controller Card | SAS RAID | LSI (по этой ссылке раньше...

Замена двух HDD из RAID с отменой этого RAID. А что в BIOS?
Сейчас у меня, помимо системного, стоят два диска, объединённые в RAID. Пришла пора поменять оба....

9
Evg
Эксперт CАвтор FAQ
21235 / 8248 / 636
Регистрация: 30.03.2009
Сообщений: 22,600
Записей в блоге: 30
14.09.2015, 23:09 2
Идея из разряда нанотехнологий. Т.е. на бумаге и в презентациях выглядит красиво, но на практике оказывается никому не нужным
1
3174 / 1933 / 313
Регистрация: 27.08.2010
Сообщений: 5,131
Записей в блоге: 1
15.09.2015, 01:05 3
Цитата Сообщение от dionus Посмотреть сообщение
есть ли в природе программа, которая такое делает
  • MD5 здесь ни при чем (и бесполезна).
  • Сама идея - "размазать информацию тонким слоем" - безусловно правильна, но уже решена (1987) лучшими способами (RAID 5 устроен именно так, как вы предлагаете: XOR + чередование блоков, RAID 6 дополнительно использует коды Рида-Соломона для коррекции ошибок).
  • How does RAID 5 work? The Shortest and Easiest explanation ever!
  • VCS - системы контроля версий (и, в какой-то степени, инкрементальный backup) эксплуатируют тот же механизм: взамен двух копий хранится только одна + дельта между ними.
1
0 / 0 / 0
Регистрация: 13.09.2015
Сообщений: 5
15.09.2015, 02:38  [ТС] 4
уже решена (1987) лучшими способами (RAID 5 устроен именно так, как вы предлагаете
Что такое RAID я конечно же почитал. Правда на практике не пользовался. Безусловно штука хорошая - но проблема в том что в ноутбуке ее не реализуешь. А у меня мысль о таком рэйд-подобном бэкапе возникла именно потому что я работаю на ноутбуке, а информацию сохраняю на внешние жесткие диски. Их у меня 3 штуки. Вот и начала мысль работать в направлении, что можно тут придумать.
Кроме того даже если бы компьютер был стационарным, то установленный рейд-массив не позволял бы резервировать только отобранные мною файлы. В этом ведь и преимущество бэкапа - можно забэкапить только нужное, а не весь хлам который лежит на диске.
Инкрементальный бэкап - это немного другое. Если информация не имеет версий, т.е. статична и не меняется, то инкрементальный бэкап не даст экономии места - ведь нечего инкрементировать.

MD5 здесь ни при чем (и бесполезна).
MD5 я приплел сюда по аналогии с торрентами - ведь там контролируется кэш файлов перед тем как начинать их использовать. Так и тут: MD5-файл необходим для того чтобы удостовериться что данные находятся в целости и сохранности. И в случае восстановления можно будет по этим суммам убедиться что данные восстановлены в полном объеме. Более того, если часть данных будет утеряна (ведь всякое бывает, допустим один диск сломался а на втором оказалось много бэд-блоков) - то будет видно какие файлы пострадали. Если эти файлы есть в интернете или записаны на DVD то можно их оттуда скачать/скопировать и тем самым полностью восстановить архив.

Идея из разряда нанотехнологий. Т.е. на бумаге и в презентациях выглядит красиво, но на практике оказывается никому не нужным
Ну а конкретнее можно сформулировать - какие узкие места процесса приводят к непрактичности? Может их можно как-то обойти? Автоматизировать? Чтобы грубо говоря свести работу системы к нажатию одной кнопки.
К примеру я вижу такой вариант практического применения:
Некий пользователь является активным сидером на торрентах. И у этого пользователя есть два или три жестких диска на которых есть папки Torrents с которых раздается информация. Возможен также вариант что какие-то диски со старыми торрентами он отключил и подсоединяет когда кто-то просит вернуться на раздачу. Можно конечно ничего не бэкапить. Но в случае если выйдет из строя жесткий диск, то может случится так, что на каких-то торрентах он был последним сидером. В итоге он не сможет восстановить раздачу. А вдруг она редкая и уникальная? Кроме того даже если все торренты доступны и качаются, то понадобится время и траффик чтобы их заново перекачать. А восстановить папку из бэкапа будет намного быстрее.
Вот и получается что для бэкапа информации такому пользователю достаточно в окошке из двух, трех или N колонок (в зависимости от количества дисков) выбрать какие папки нужно забэкапить, подключить еще один диск и нажать кнопку Backup. А в случае восстановления подключить все используемые диски и нажать кнопку Restore. Даже если в результате человеческого фактора (допустим удалил какие-то папки) часть файлов не восстановится, то они закачаются с торрентов.
0
3174 / 1933 / 313
Регистрация: 27.08.2010
Сообщений: 5,131
Записей в блоге: 1
15.09.2015, 03:39 5
Лучший ответ Сообщение было отмечено dionus как решение

Решение

Цитата Сообщение от dionus Посмотреть сообщение
MD5 я приплел сюда по аналогии с торрентами
Там другой механизм.

IMHO, никаких препятствий для практической реализации нет, но в отличие от RAID 5, ваше решение несимметрично - различные части системы обладают существенно разной стойкостью. Например, утрата контрольной суммы делает невозможным выбор между двумя различающимися копиями, при этом сама контрольная сумма (скажем, MD5 хэш) для восстановления бесполезна. И если вы станете добиваться "равнопрочности" всех звеньев, то придете, в итоге, к "SoftRAID" :-)

Hardware RAID vs. Software RAID: Which Implementation is Best for my Application?
1
Evg
Эксперт CАвтор FAQ
21235 / 8248 / 636
Регистрация: 30.03.2009
Сообщений: 22,600
Записей в блоге: 30
15.09.2015, 08:57 6
Цитата Сообщение от dionus Посмотреть сообщение
Ну а конкретнее можно сформулировать - какие узкие места процесса приводят к непрактичности?
Узким местом является идея бэкапить файлы, которые никогда не меняются. Попробуй привести реальный (а не высосанный из пальца торренты) жизненный пример, где сие могло бы понадобиться на практике. И ты увидишь, что в жизни оно никому (или почти никому) не будет нужно

Цитата Сообщение от dionus Посмотреть сообщение
А вдруг она редкая и уникальная?
Если у меня есть редкие и уникальные данные, то я их забэкаплю зеркально (а может даже два-три раза) и зеркальный диск спрячу в сейф, вместо того, чтобы доверять их всяким нанотехнологиям, требующим особых условий. А если данные не уникальные, а распространённые, то я не буду их вобще бэкапить, т.к. в случае потери их проще скачать, чем возиться с бэкапом. Да и само условие неизменения данных (по составу) уже приводит к тому, что я не мгоу придумать жизненной ситуации, в которых такие данные присутствуют
0
0 / 0 / 0
Регистрация: 13.09.2015
Сообщений: 5
16.09.2015, 03:30  [ТС] 7
придете, в итоге, к "SoftRAID" :-)
Ну а там недалеко и до хардрейда ))) Ведь как я понимаю для софтрейда все равно надо наличие постоянно подключенных нескольких дисков и при этом используется все их пространство.

А если данные не уникальные, а распространённые, то я не буду их вобще бэкапить, т.к. в случае потери их проще скачать, чем возиться с бэкапом.
К сожалению нет четкой грани между уникальностью и распространенностью. Часто бывает что вроде информация была распространенная, а через время пытаешься ее найти - а все ссылки битые, торренты умершие, а домен сайта-источника выставлен на продажу. Кроме того даже если информация из разряда "есть везде", то вбивать названия в поисковик, переходить по ссылкам и снова закачивать сотни файлов - по времени намного дольше чем подключить жесткий диск с информацией для восстановления и восстановить большинство этих файлов из бэкапа. К тому же это еще надо вспомнить названия которые надо искать - в такой ситуации мне не раз на помощь приходила программа Camel Disk Catalog - посмотреть что именно было на сломавшемся жестком диске и по горячим следам перекачать нужное. Но не все же пользуются такими каталогизаторами.

Узким местом является идея бэкапить файлы, которые никогда не меняются. Попробуй привести реальный (а не высосанный из пальца торренты) жизненный пример, где сие могло бы понадобиться на практике.
Ну вообще-то более 80% файлов рядового пользователя - это файлы которые после попадания на жесткий диск и первичного редактирования (допустим поворота фоток на 90°) больше никогда не меняются. И как показывает практика большинство обычных пользователей хранит все фото-видеоматериалы, отснятые с камеры или планшета, в одном экземпляре. И только часть из них заливая в какие-нибудь "Яндекс-фотки", а часть записывая на диски. К этим многогигабайтным папкам добавляется любимая подборка музыки, фильмов и PDF-книг, которые тоже никто не редактирует.

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

И кстати, факт того что образы DVD-дисков обычно все стандартного размера (4.3 или 8 Гб), наталкивает на мысль делать бэкапный архив не для всех файлов сразу, а пофайлово. Это намного более гибкое решение. Попробую его описать:
1. Имеется 2 или больше жестких диска с папками которые надо забэкапить.
2. Программа по простому алгоритму выбирает из папок по одному файлу так чтобы размеры файлов были примерно одинаковыми - и создает для них XOR-бэкап-файл с информацией для восстановления.
3. Если попадается файл, которому нельзя подобрать пару схожего размера, то можно ему сопоставить два или более мелких файлов. И сделать бэкап только для этих нескольких файлов.

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

Еще более оригинальная идея - это задействовать этот алгоритм в локальной сети. Т.е. допустим в доме или офисе несколько ноутбуков объединено в сеть. И каждый пользователь сети может расшарить папку, которую он хотел бы дополнительно забэкапить. А "серверный" робот (на наиболее часто используемом ноутбуке) по вышеприведенному алгоритму мог бы собирать с этих папок файлы и делать для них XOR-бэкап, значительно экономя при этом дисковое пространство. Кроме того дополнительная экономия будет в случае если у пользователей файлы дублируются.
Конечно такая идея несколько авантюрная и чем-то напоминает торренты - если пользователь захочет восстановить свою информацию, то ему прийдется ждать "сидера" в сети у которого был нужный для восстановления файл. Тут уже алгоритм должен быть более продвинутым, и анализировать доступность пользователей в сети, а также их поведение: насколько часто они меняют или удаляют файлы и в каких папках. И задача алгоритма будет состоять в том чтобы не объединять ненадежные файлы/папки с надежными и регулярно доступными. Конечно невысокая надежность такого бэкапа возводит его в ранг дополнительного страховочного средства. Но в любом случае это лучше чем ничего. Т.е. тут уже многое будет зависеть от договоренностей между участниками локальной сети - например не удалять файлы из этой папки, а переносить их в папку "Trash", откуда робот будет сам их удалять по мере пересборки бэкапов.
0
3174 / 1933 / 313
Регистрация: 27.08.2010
Сообщений: 5,131
Записей в блоге: 1
16.09.2015, 08:29 8
В сущности, все предлагаемое уже реализовано (дерево хэшей, автоматическая синхронизация - тот же rsync).

Что касается "экономии" в размере, то, на самом деле, она недостижима.

Не по теме:

В 16 веке, с развитием мореплавания, остро встала проблема "бэкапа" точного времени. Были изобретены (независимо Христианом Гюйгенсом и Робертом Гуком) часы с балансом - хронометры.

Понятно, что одного хронометра в походе недостаточно. Двух - тоже: при разнице показаний нет возможности выбрать "правильные" часы. Нужно не менее трех устройств для "голосования" (мажорирование два из трех).

Принцип этот универсален - от кодов, исправляющих ошибки до атомной энергетики и космических полетов.


Лучшее на сегодня решение - коды Рида-Соломона - требует двух проверочных бит на каждый защищаемый бит данных.
0
Evg
Эксперт CАвтор FAQ
21235 / 8248 / 636
Регистрация: 30.03.2009
Сообщений: 22,600
Записей в блоге: 30
16.09.2015, 09:50 9
Цитата Сообщение от dionus Посмотреть сообщение
Ну вообще-то более 80% файлов рядового пользователя - это файлы которые после попадания на жесткий диск и первичного редактирования (допустим поворота фоток на 90°) больше никогда не меняются
Ты навязываешь пользователю жёсткие условия. Иметь два обязательных диска и один условно съёмный. 90% пользователей это не устроит сразу же. Нужно хранить эти фотографии условно размазанными по двум дискам (причём следить, чтобы примерно в равной пропорции), ни в коем случае их не переименовывать и не перемещать по каталогам. Таким образом ещё 90% от оставшихся 10% сия технология не устроит. Не дай боже случайно один из файлов отредактируешь, после чего имеешь долгий геморрой с тем, чтобы пересоздавать бэкап. Теперь если мы рассмотрим вариант с ноутбуком с двумя дисками, который случайно уронили или который у тебя украли. В итоге имеем бэкап, от которого нам никакого толку, а ценные фотографии потеряны. Если человеку хватило ума на то, чтобы как-то позаботиться о бэкапе, то с вероятностью 90% его устроит купить внешний диск и делать полное резервное копирование фотографий, а не заниматься онанизмом с нанотехнологиями. В raid'ах построение избыточной информации делается в первую очередь ради экономии времени для быстрой замены вышедшего из строя диска, а вовсе не для спасения данных. Любая ценная информация, хранящаяся на raid'е любым здравомыслящим человеком будет полностью куда-нибудь продублирована. Ты же идею raid'а пытаешься натянуть на идею спасения данных

Цитата Сообщение от dionus Посмотреть сообщение
Конечно невысокая надежность такого бэкапа возводит его в ранг дополнительного страховочного средства. Но в любом случае это лучше чем ничего
Есть хорошая пословица - "скупой платит дважды". Для резервного копирования ценных данных твой метод ни разу не канает. Для всего остального, на мой взгляд, резервное копирование большого смысла не имеет (в реальной жизни, а не на слайдах с презентацией)
0
0 / 0 / 0
Регистрация: 13.09.2015
Сообщений: 5
16.09.2015, 20:57  [ТС] 10
В raid'ах построение избыточной информации делается в первую очередь ради экономии времени для быстрой замены вышедшего из строя диска, а вовсе не для спасения данных.
Так вот об экономии времени как раз и речь. Ясное дело что особо ценные данные надо бэкапить целиком и полностью. А все вышеизложенное мной - это способ быстрого автоматического восстановления утраченной информации, которая хоть и не крайне важна, но все-таки полезна и периодически используется.
Т.е. получается имея такие крайности как "бэкапить надежно" и "вообще не бэкапить" хочется еще иметь какой-то гибкий срединный вариант оптимального использования имеющихся дисковых ресурсов. Допустим если свободное место на дисках позволяет - то бэкап идет надежный. А если его не хватает - то "интеллектуальный".

Ты навязываешь пользователю жёсткие условия. Иметь два обязательных диска и один условно съёмный.
Так ведь у RAID условия к количеству дисков такие же. А у зеркального бэкапа количество дисков требуется еще больше.
Нужно хранить эти фотографии условно размазанными по двум дискам (причём следить, чтобы примерно в равной пропорции), ни в коем случае их не переименовывать и не перемещать по каталогам.
Не обязательно равными. Просто чем больше разница в размере, тем меньше экономия места при бэкапе. Зато часть файлов, которым не хватило пары, бэкапится обычным методом. Ну а если у пользователя будет стоять два одинаковых по объему диска, то по мере уменьшения свободного места на этих дисках размеры данных будут уравниваться и "процент сжатия" будет возрастать
А на случай переименовывания и перемещений файлов, как я уже описал выше, можно задействовать несложный алгоритм поиска файлов по размеру и хэшу. Это даже в простом батнике можно сделать. Фактически все вышеперечисленное можно реализовать с помощью нескольких BAT-файлов и какой-нибудь простой консольной утилиты для XOR-ирования файлов. Опыт написания батников у меня есть. А вот в создании утилит по работе с большими файлами опыта нет. Поэтому хотелось бы узнать - вдруг кто знает какой-то готовый консольный софт для XOR-ирования файлов. Можно было бы хотя бы в академических целях с ним поэкспериментировать. Или для какой-то частной задачи использовать. А попутно еще и применять для шифрования.

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

Для всего остального, на мой взгляд, резервное копирование большого смысла не имеет (в реальной жизни, а не на слайдах с презентацией)
Вот для такого "всего остального" я уже думал над таким вариантом резервирования: чтобы вместе с файлами в каком-то виде хранить информацию откуда они скачаны. И эту небольшую текстовую информацию бэкапить. А в теоретическом идеале чтобы была какая-то софтинка, которая могла бы используя эту информацию закачать все одним махом и тем самым восстановить утерянное без кропотливого участия пользователя. В принципе для файлов с прямыми ссылками и торрентов такое теоретически возможно. А предел мечтаний - это чтобы утилита периодически проходилась по этим ссылкам с адресами, и выясняла доступны ли там файлы для скачивания. Если ссылки битые, а на торрентах один или два сидера - то делать резервное копирование таких файлов, как ставших редкостью. Опять же вопрос - может кто знает, есть ли какие-то утилиты проверки наличия файлов по ссылкам и проверки страниц с торрентами на предмет количества раздающих?
0
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
16.09.2015, 20:57
Помогаю со студенческими работами здесь

ошиба при загрузке No disk reserved for RAID use, RAID disabled.
Помогите пожалуйста с такой проблемой.Старенький комп, только для выхода в инет АМД семпрон...

ASUS P8Z68 Deluxe SATA III Raid поддерживает Raid на 6-гигабитных сата-портах?
Ребят, подскажите, данная мать поддерживает Raid на 6-гигабитных сата-портах? Нигде такой...

Windows 2008 server R2 Накрылся crcdisk.sys. Харды в массиве RAID 10. Хардверный RAID контроллер
Здравствуйте. Сервер самопромзвольно уходит в ребут, как только загрузка добирается до...

Нарисуйте RAID 65 и RAID 1014
Пожалуйста, нарисуйте RAID 65 и RAID 1014! Сделайте в Paint!

Создание Raid 0+1 из существующего Raid 1
Доброго времени суток. Имеется сервер с 1С:Предприятие 8, на нем настроен Raid 1. Появилась...

Схема raid 66 и raid 666
Я не особо понимаю куда писать на эту тему, вряд ли вообще кто-то ответит но все же... Задали...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
10
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2022, CyberForum.ru