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. Теперь этот полученный файл надо сохранить на третий жесткий диск (диск для бэкапа). Для справки: Если один из жестких дисков выйдет из строя, то информацию можно будет восстановить из двух оставшихся жестких дисков. В чем преимущество такого подхода в сравнении с RAID 5 из трех дисков? 1. Все три диска могут быть внешними и отсоединяться. 2. Информация на первых двух дисках доступна даже если подключать диски по-одному. В то время как RAID работает только когда все диски подключены и объединены в один общий массив. Получается что если выйдут из строя два диска, один из которых бэкапный, то хотя бы половина информации останется целой. 3. Неподключенные жесткие диски не изнашиваются. 4. При восстановлении информации можно действовать выборочно и с перерывами, чтобы не перенагружать сохранившиеся жесткие диски интенсивным чтением, и тем самым не повышать вероятность выхода их из строя в этот неподходящий момент. В то время как при перестройке RAID-массива диски нагружаются на всю катушку. 5. На дисках можно создавать новые файлы, изменять или удалять файлы, которые не прописаны в файлах CheckSum.MD5. Это не повлияет на сохранность забэкапленной информации. Ну вот примерно так. Кто что думает по-этому поводу? Существует ли софт, который реализует такое? Т.е. смысл всего этого в том чтобы в два раза сэкономить место для бэкапа. И кроме того бэкап можно хранить где-нибудь на сетевом ресурсе и вообще не использовать его в работе, в отличие от RAID, где надо держать диск подключенным. Конечно можно еще большей экономии добиться, если использовать не 3 диска, а больше - например цепочку из 5 или 6 дисков. Только это уже будет малопрактично если диски внешние и их надо будет присоединять вручную. А с тремя дисками еще можно как-то управляться, подключив их одновременно или скопировав с них нужные файлы на встроенный диск в ноутбуке.
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
0
|
|
13.09.2015, 22:10 | |
Ответы с готовыми решениями:
9
Аналогу system()
Контроллер MegaRAID 9240-8i RAID Controller Card | SAS RAID | LSI Замена двух HDD из RAID с отменой этого RAID. А что в BIOS? |
15.09.2015, 01:05 | 3 |
1
|
0 / 0 / 0
Регистрация: 13.09.2015
Сообщений: 5
|
|
15.09.2015, 02:38 [ТС] | 4 |
Кроме того даже если бы компьютер был стационарным, то установленный рейд-массив не позволял бы резервировать только отобранные мною файлы. В этом ведь и преимущество бэкапа - можно забэкапить только нужное, а не весь хлам который лежит на диске. Инкрементальный бэкап - это немного другое. Если информация не имеет версий, т.е. статична и не меняется, то инкрементальный бэкап не даст экономии места - ведь нечего инкрементировать. К примеру я вижу такой вариант практического применения: Некий пользователь является активным сидером на торрентах. И у этого пользователя есть два или три жестких диска на которых есть папки Torrents с которых раздается информация. Возможен также вариант что какие-то диски со старыми торрентами он отключил и подсоединяет когда кто-то просит вернуться на раздачу. Можно конечно ничего не бэкапить. Но в случае если выйдет из строя жесткий диск, то может случится так, что на каких-то торрентах он был последним сидером. В итоге он не сможет восстановить раздачу. А вдруг она редкая и уникальная? Кроме того даже если все торренты доступны и качаются, то понадобится время и траффик чтобы их заново перекачать. А восстановить папку из бэкапа будет намного быстрее. Вот и получается что для бэкапа информации такому пользователю достаточно в окошке из двух, трех или N колонок (в зависимости от количества дисков) выбрать какие папки нужно забэкапить, подключить еще один диск и нажать кнопку Backup. А в случае восстановления подключить все используемые диски и нажать кнопку Restore. Даже если в результате человеческого фактора (допустим удалил какие-то папки) часть файлов не восстановится, то они закачаются с торрентов.
0
|
15.09.2015, 03:39 | 5 |
![]() Решение
Там другой механизм.
IMHO, никаких препятствий для практической реализации нет, но в отличие от RAID 5, ваше решение несимметрично - различные части системы обладают существенно разной стойкостью. Например, утрата контрольной суммы делает невозможным выбор между двумя различающимися копиями, при этом сама контрольная сумма (скажем, MD5 хэш) для восстановления бесполезна. И если вы станете добиваться "равнопрочности" всех звеньев, то придете, в итоге, к "SoftRAID" :-) Hardware RAID vs. Software RAID: Which Implementation is Best for my Application?
1
|
![]() ![]() |
|
15.09.2015, 08:57 | 6 |
Узким местом является идея бэкапить файлы, которые никогда не меняются. Попробуй привести реальный (а не высосанный из пальца торренты) жизненный пример, где сие могло бы понадобиться на практике. И ты увидишь, что в жизни оно никому (или почти никому) не будет нужно
Если у меня есть редкие и уникальные данные, то я их забэкаплю зеркально (а может даже два-три раза) и зеркальный диск спрячу в сейф, вместо того, чтобы доверять их всяким нанотехнологиям, требующим особых условий. А если данные не уникальные, а распространённые, то я не буду их вобще бэкапить, т.к. в случае потери их проще скачать, чем возиться с бэкапом. Да и само условие неизменения данных (по составу) уже приводит к тому, что я не мгоу придумать жизненной ситуации, в которых такие данные присутствуют
0
|
0 / 0 / 0
Регистрация: 13.09.2015
Сообщений: 5
|
|
16.09.2015, 03:30 [ТС] | 7 |
Или допустим еще одна категория - продублированные образы CD и DVD дисков, стоящих на полке. Ведь никто эти образы на компьютере не редактирует. Они лежат неизменными с самого начала. И если жесткий диск выйдет из строя, то садиться и тратить целый день, а то и два на копирование десятков этих DVD внутрь компьютера - дело довольно муторное. С другой стороны настраивать у себя дома хард или софт-RAID рядовые пользователи, а также пользователи ноутбуков вряд ли будут. Остается вариант полностью зеркалить и ложить в сейф - но для многих это слишком затратно. И кстати, факт того что образы DVD-дисков обычно все стандартного размера (4.3 или 8 Гб), наталкивает на мысль делать бэкапный архив не для всех файлов сразу, а пофайлово. Это намного более гибкое решение. Попробую его описать: 1. Имеется 2 или больше жестких диска с папками которые надо забэкапить. 2. Программа по простому алгоритму выбирает из папок по одному файлу так чтобы размеры файлов были примерно одинаковыми - и создает для них XOR-бэкап-файл с информацией для восстановления. 3. Если попадается файл, которому нельзя подобрать пару схожего размера, то можно ему сопоставить два или более мелких файлов. И сделать бэкап только для этих нескольких файлов. В итоге мы получаем не один большой бэкап, а много файлов с бэкапами поменьше. При чем в каждом из этих бэкапов прописана информация - файлы с каким именем, какой датой, какого размера и с какими хэшами он может восстановить. С таким подходом получается можно даже не ограничивать пользователя необходимостью оставлять файлы неизменными. Достаточно периодически проверять все ли файлы на месте, и если обнаружены какие-то изменения то предлагать сделать пересборку тех нескольких бэкапов, которые отвечают за измененные или удаленные файлы. Еще более оригинальная идея - это задействовать этот алгоритм в локальной сети. Т.е. допустим в доме или офисе несколько ноутбуков объединено в сеть. И каждый пользователь сети может расшарить папку, которую он хотел бы дополнительно забэкапить. А "серверный" робот (на наиболее часто используемом ноутбуке) по вышеприведенному алгоритму мог бы собирать с этих папок файлы и делать для них XOR-бэкап, значительно экономя при этом дисковое пространство. Кроме того дополнительная экономия будет в случае если у пользователей файлы дублируются. Конечно такая идея несколько авантюрная и чем-то напоминает торренты - если пользователь захочет восстановить свою информацию, то ему прийдется ждать "сидера" в сети у которого был нужный для восстановления файл. Тут уже алгоритм должен быть более продвинутым, и анализировать доступность пользователей в сети, а также их поведение: насколько часто они меняют или удаляют файлы и в каких папках. И задача алгоритма будет состоять в том чтобы не объединять ненадежные файлы/папки с надежными и регулярно доступными. Конечно невысокая надежность такого бэкапа возводит его в ранг дополнительного страховочного средства. Но в любом случае это лучше чем ничего. Т.е. тут уже многое будет зависеть от договоренностей между участниками локальной сети - например не удалять файлы из этой папки, а переносить их в папку "Trash", откуда робот будет сам их удалять по мере пересборки бэкапов.
0
|
16.09.2015, 08:29 | 8 |
В сущности, все предлагаемое уже реализовано (дерево хэшей, автоматическая синхронизация - тот же rsync).
Что касается "экономии" в размере, то, на самом деле, она недостижима. Не по теме: В 16 веке, с развитием мореплавания, остро встала проблема "бэкапа" точного времени. Были изобретены (независимо Христианом Гюйгенсом и Робертом Гуком) часы с балансом - хронометры. Лучшее на сегодня решение - коды Рида-Соломона - требует двух проверочных бит на каждый защищаемый бит данных.
0
|
![]() ![]() |
|
16.09.2015, 09:50 | 9 |
Ты навязываешь пользователю жёсткие условия. Иметь два обязательных диска и один условно съёмный. 90% пользователей это не устроит сразу же. Нужно хранить эти фотографии условно размазанными по двум дискам (причём следить, чтобы примерно в равной пропорции), ни в коем случае их не переименовывать и не перемещать по каталогам. Таким образом ещё 90% от оставшихся 10% сия технология не устроит. Не дай боже случайно один из файлов отредактируешь, после чего имеешь долгий геморрой с тем, чтобы пересоздавать бэкап. Теперь если мы рассмотрим вариант с ноутбуком с двумя дисками, который случайно уронили или который у тебя украли. В итоге имеем бэкап, от которого нам никакого толку, а ценные фотографии потеряны. Если человеку хватило ума на то, чтобы как-то позаботиться о бэкапе, то с вероятностью 90% его устроит купить внешний диск и делать полное резервное копирование фотографий, а не заниматься онанизмом с нанотехнологиями. В raid'ах построение избыточной информации делается в первую очередь ради экономии времени для быстрой замены вышедшего из строя диска, а вовсе не для спасения данных. Любая ценная информация, хранящаяся на raid'е любым здравомыслящим человеком будет полностью куда-нибудь продублирована. Ты же идею raid'а пытаешься натянуть на идею спасения данных
Есть хорошая пословица - "скупой платит дважды". Для резервного копирования ценных данных твой метод ни разу не канает. Для всего остального, на мой взгляд, резервное копирование большого смысла не имеет (в реальной жизни, а не на слайдах с презентацией)
0
|
0 / 0 / 0
Регистрация: 13.09.2015
Сообщений: 5
|
|
16.09.2015, 20:57 [ТС] | 10 |
Т.е. получается имея такие крайности как "бэкапить надежно" и "вообще не бэкапить" хочется еще иметь какой-то гибкий срединный вариант оптимального использования имеющихся дисковых ресурсов. Допустим если свободное место на дисках позволяет - то бэкап идет надежный. А если его не хватает - то "интеллектуальный". А на случай переименовывания и перемещений файлов, как я уже описал выше, можно задействовать несложный алгоритм поиска файлов по размеру и хэшу. Это даже в простом батнике можно сделать. Фактически все вышеперечисленное можно реализовать с помощью нескольких BAT-файлов и какой-нибудь простой консольной утилиты для XOR-ирования файлов. Опыт написания батников у меня есть. А вот в создании утилит по работе с большими файлами опыта нет. Поэтому хотелось бы узнать - вдруг кто знает какой-то готовый консольный софт для XOR-ирования файлов. Можно было бы хотя бы в академических целях с ним поэкспериментировать. Или для какой-то частной задачи использовать. А попутно еще и применять для шифрования.
0
|
16.09.2015, 20:57 | |
Помогаю со студенческими работами здесь
10
ошиба при загрузке No disk reserved for RAID use, RAID disabled. ASUS P8Z68 Deluxe SATA III Raid поддерживает Raid на 6-гигабитных сата-портах? Windows 2008 server R2 Накрылся crcdisk.sys. Харды в массиве RAID 10. Хардверный RAID контроллер Нарисуйте RAID 65 и RAID 1014
Схема raid 66 и raid 666 Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |