Выбор оптимального способа хранения архивных данных
 

Добрый день,

сразу прошу прощения, возможно, мои вопросы окажутся банальными, но не смог с ходу на них ответить. И за длиннопост.

Задача - отправить в "архив" большой объем информации (предположительно 1-3Тб) - старых фотографий, видео, документов, то есть всего, что либо с 90% вероятностью не понадобится (но удалить жалко), либо требуется раз в несколько месяцев. В данный момент все это разбросано по разным носителям - дискам, ЖД в компьютерах, ЖД не в компьтерах, облачных хранилищах. Частично с дублированием/ пересечением.

Требуется подобрать вариант по балансу цена-надежность-удобство доступа. С небольшим уклоном в надежность. Безопасность обеспечивается физической доступностью жд (облачное хранилище пока как опция).

Основные вопросы:
1. Как разобраться с дублированием/ пересечением? Все скопировать в одно место, потом сравнивать в Тотал Коммандере? Или есть спец. заточенные под это программы? Возможно, до архивирования за счет дублирований файлов может быть 2-3 Тб. Пока не придумал, как это обойти.
2. Достаточным вариантом по надежности будет два жд (по 1 или 2 ТБ или 3 ТБ, как получится) под архив с дублированием файлов на каждый? Дешевле варианта более-менее с нормальной сохранностью не смог придумать. Или лучше еще добавить облачное хранилище как третье хранилище (оплатить место для хранения самых важных файлов)?
3. Проще просто копировать по экземпляру файла на оба диска или выполнить клонирование на какой-нибудь док станции? Что в этом случае делать с обновлениями? Каждый раз клонировать?
4. Чисто теоретически - есть ли какая-либо возможность проверить файлы (хотя бы какие-нибудь форматы) на "битость" - то есть этот документ не массив битов, поврежденный по тем или иным причинам, а тот, который можно открыть?
5. Есть ли смысл рассматривать вариант сетевого хранилища, если доступ требуется крайне редко? Но теоретически будет большой плюс в удобстве.
6. Есть ли хитрости по долговоременному хранению ждисков в плане климата? Электромагнитному воздействию? Например, лучше убрать в металлический кейс?
7. Есть док. станция Орико USB 3.0 - нормально ли осуществлять доступ через нее? Или док станций лучше избегать и пользоваться подключением по Сата? Требуется ли для док. станции подключать её через ИБП во избежание последствий скачков напряжения?
8. Есть ли смысл переплачивать за более дорогие ЖД? Например, серии не Green/ Blue/ Barracuda, а Red/ Black, IronWolf и т.п. для большей сохранности/ надежности?
9. Есть ли смысл делать MBR вместо GPT для повышения шансов восстановления ЖД после отказа? А если жд потребуется в итоге по общему весу файлов больше 2 Тб?
10. Архивирование (сжатие) будет во вред в плане надежности или на пользу (с учетом данных для восстановления)? Или архивирование понизит шансы восстановления отдельных файлов?
11. Есть ли какие-либо другие способы повышения надежности/ защиты от утери типа рар архивирования с данными для восстановления? Или это будет только во вред?


Заранее спасибо.

WinRAR может восстановить 5% повреждений в виде непрерывного куска, а если повреждений больше? Лучше дублирование. Или сохранение в rar, но без компрессии, чтобы, если WinRAR не справится, можно было вытащить самому.

1. Как будет удобно, так и сравнивайте. Я пользую Far Manager и CloneSpy.

Но не забывайте главное — если Вы просто соберёте несколько помоек в одно место — будет всего лишь ещё одна помойка, только большая. Тщательно продумайте организацию хранилища (по сути — структуру каталогов). Используйте NTFS и её возможности по созданию жестких ссылок, связей каталогов и символических ссылок (что весьма удобно создавать и пользовать в Far Manager'е — там это встроенный функционал), дабы избежать реального дублирования информации, когда нужно организовать какое-либо перекрёстное хранение.

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

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

4. Теоретическая вероятность есть. Практически этого никто никогда не делает, потому что это требует ру́́чек и гла́́зок.

5. Нет. Сетевое хранилище — те данные, доступ к которым требуется периодически, но они большого объёма. Архив — не тот случай.

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

7. —//—

8. Нет. Blue, но не Barracuda. Впрочем, коллега ShaddyR тут лучше подскажет, как практик.

9. —//—

10. Какое именно архивирование? Какого типа? Так-то и без сжатия может быть достаточно повреждения пары байт, чтобы файл стал неоткрываемым в родном приложении.

11. Аппаратная реализация CRC.

Тады — «Ой».

Вот уж бессмысленное действие.

Iska,

большое спасибо за развернутые ответы.

по п. 8 - это связано с аппаратным особенностями линейки Seagate? SMR?

по п. 10 имел в виду сжатие с компрессией и с данными для восстановления в архивы RAR хорошо сжимаемых данных типа файлов word *.doc - небольшими группами по несколько десятков файлов для более эффективного исп. места.

по п. 11 Вы имеете в виду именно обнаружение факта наличия повреждений?

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

Я к тому, что если повредится архив и WinRAR сможет восстановить только до определенного места, то, если архив без сжатия, можно отбросить rar заголовок и получить чистый, хоть и поврежденный файл. Видео и аудиозаписи в случае повреждений все равно представляют ценность. Еще раз говорю, это на тот случай, если WinRAR не справится или справится плохо. Со сжатыми данными в таком случае мы получим кусок мусора. Хотя, практически с подобным не сталкивался. Но файлы бились на DVD+R, лучшей защитой от этого является дублирование, хотя бы важных файлов. Например, если есть семейная видеозапись в хорошем качестве и высоком разрешении, имеет смысл сделать ее рип с меньшими параметрами и меньшим весом, тогда, если оригинал повредится, останется хотя бы рип.

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

В свое время пользовался DupKiller, выручала.

Да есть, называется данная процедура сравнение хэш сумм. Автоматически реализовать это не знаю как, а в ручную или с помощью командной строки можно.

Без разницы, притом совсем.

Да есть и называется многократное дублирование на разных типах в видах носителей.

Со встречавшимися отзывами. Но — смотри замечание в тексте.

Навряд ли у Вас найдётся документов Word на терабайт :). Впрочем, решать Вам.

Определения факта и автоматической коррекции за счёт избыточности.

Но мы-то тут про хранение.

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

простое увеличение количества дублей особо не поможет
всё это надо оборачивать метаданными с контрольными суммами и историей изменений
сразу думайте, что вы потом делать будете с этим своим дублированием

плохая затея - такая структура нетривиально синхронизируется, да и в порядке вещей хранить подобный архив там, где NTFS нет - на NAS, в облаке и т.п.

чтобы проверить целостность файла ручки и глазки не нужны

Каким волшебным образом вы без сетевого хранилища собираете синхронизировать три копии в разных географических точках - занимательный вопрос.

этот символ обозначает повтор предыдущего текста
к чему он здесь?

dan_p, можете поэкспериментировать с файловой системой UDF

похоже, вы говорите про разное
Сохранённая контрольная сумма (она не обязательно должна быть получена по хэш-алгоритму) сможет сказать менялся ли файл вообще.
А dan_p похоже, хотел отличить нежелательные повреждения от осмысленного изменения целевым ПО
универсального инструмента я не знаю
К примеру, docx, xlsx на самом деле zip-архивы. Их целостность можно проверить архиватором.
А какой-нибудь mp3 можно довольно сильно покрамсать не ломая логику хранения данные

Для архивирования есть большие коммерческие решения. Но что-то бесплатное, простое, да ещё и синхронизацией "голубиной почтой" мне не встречалось.
Если найдёте - дайте знать, pls.

Можно, наверное, соорудить что -нибудь на основе git (или иных систем контроля версий):

• децентрализованный
• сам является сетевым сервером, т.е. нет прямого доступа к данным
• хранит историю изменений
• современные git и hg поддерживают бинарники (не пытаются работать как с текстом)
• есть масса разнообразнейших обёрток и расширений
• доказали свою надёжность и эффективность в самых разнообразнейших решениях

"Слона нарезают дольками", иначе говоря, один вопрос - один топик. Иначе тут будет каша, в которой сами потеряетесь.
Надёжность и удобство денег стоят. Есть разные уровни надёжности и удобства, различающиеся по стоимости на порядки.

Проще говоря, пример: взять два диска, закинуть на них инфу, один положить подальше в надёжное место, вторым пользоваться - обойдётся в 150-300 евро. Если же взять домашний NAS на 4 диска из топовых, у которых есть поддержка чего-то такого и вообще закроет все ваши вопросы по надёжности и удобству (какие нужно закрывать, например глупости про архивацию и MBR vs GPT это глупоти), а также сможет служить и для насущных целей помимо хранения архива, то это обойдётся в 1000-2000 евро и более (львиная доля цены приходится на диски, а туда хоть 16ТБ модели можно ставить).

Цитата:

Цитата Busla чтобы проверить целостность файла ручки и глазки не нужны »

Это токмо при наличии какой-то системы хранения, наподобие Вашего:

Цитата:

Цитата Busla всё это надо оборачивать метаданными с контрольными суммами и историей изменений сразу думайте, что вы потом делать будете с этим своим дублированием »

И не целостность, а неизменность файла. Вопрос-то изначально был другим.

Цитата:

Цитата Busla Каким волшебным образом вы без сетевого хранилища собираете синхронизировать три копии в разных географических точках - занимательный вопрос. »

Точно так же, как это всю жизнь делалось — приносилось и синхронизировалось. Речь шла про «хранить».

Цитата:

Цитата Busla этот символ обозначает повтор предыдущего текста к чему он здесь? »

Вы правы. Я уже потом сообразил, что тут простой прочерк нужен был.


А насколько оно годится для «больших» файлов, ну, например, образы виртуальных дисков или болванок (условно говоря)?

Систему с версионностью было бы хорошо пользовать, но тогда проще, думаю, взять какой-нибудь NAS с соответствующим свободным ПО, и не заморачиваться.

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

Большое спасибо всем участникам.
И в некотором роде верно, обсуждение потихоньку начало превращаться в кашу.

Некоторые уточнения:
0. Первично речь идет о сборном архиве крайне редко используемых данных и периодических бекапах. То есть операции сброса бекапов будут чаще, чем необходимость доступа к ним. Вопрос обеспечения автоматического архивирования меня также интересует для реализации определенных задач, но не в этой теме.
1. Про бедняжку вопрос 4. Возможно, вопрос был сформулирован не корректно. Так как архив содержит файлы за многие годы (больше 10 лет), теоретически, он уже может быть поврежден - по крайне мере при работе с файлами архива антивирусы ругались на древние зловреды, возможно, классические вирусы. И задача была бы именно просканировать его на уже битые файлы, а не обеспечить проверку сохранности в будущем. С этой задачей более-менее понятны пути решения.
2. Про группы и типы файлов. Это фотографии, видео, и рабочие файлы. Рабочие файлы - почтовые архивы, документы ворд и ексель. Бекапы - в основном ворд и эксель, немного фото. Первичный пак документов (без фото и видео) скорее всего будет весить около или более 1 ТБ. Файлы разделены по годам и закрытым проектам, необходимости в бекапе активного проекта в данной теме нет (это другая задача - вопрос там в вере в пряморукость других людей и их точке зрения на ценность тех или иных файлов). И так как многие российские компании очень упорно продолжают пользоваться форматом doc, вопрос архивации не настолько банален.
3. Про GPT и MBR - подоплека такого вопроса следующая - несколько лет назад столкнулся с поврежденными данными на диске в GPT и несколько первых попавшихся по руку программ отказались работать с GPT. Я слабо ориетируюсь в вопросе, возможно, разница в данный момент не существенна, в том числе с учетом вероятности покупки ЖД на 3 ТБ.

Подитог:
с учетом инф. выше предполагается схема двух жд на 2-3 ТБ с частичным резервированием на облаке последних рабочих бекапов, разделение жд по месту физического хранения. Предпосылки: адекватная для задачи отказостойкость, минимальная относительная цена, доступность последних бекапов в облаке. Опции: создание хеш сумм для бекапов бесплатными средствами. Минусы - низкое удобство в ручной синхронизации, необходимость в рабочей станции/ док станции, ИБП при операциях записи бекапов. Доп. опции или-или: Повышение цены (около 1.5 на ТБ) из-за более вместительного жд ИЛИ проверка на дублирование и ручная сортировка имеющихся данных.
Два жд 3 ТБ WD30EZRZ обойдутся в 12 тысяч. Док станция есть, ИБП есть, облачное хранилище оплаченное есть. Но теоретически это плюс 4-7 тысяч (для кого-то ИБП будет перестраховкой, у кого-то в каждом месте хранения есть рабочая станция, а не ноутбук, и желание подключать по сата, т.е. и док станция не обязательна). Стоимость 1 ТБ облака в год на onedrive в данном случае не существена при покупке семейной подписки офис 365. И все равно печалька в 12к+ и кучу времени.

Основной оставшийся вопрос - это что делать с кучей документов ворд /эксель устаревшего формата? Сжимать их группами в архив с инф. для восстановления? Сжать каждый файл в отдельный архив zip при помощи консольных команд чего-нибудь вроде 7-zip? Преобразовать их в новый формат? Оставить так и купить более емкие жд?

Скажите, вот у вас случилась болезнь, температура, рвота, понос. Вы врача вызовете или будете жрать первые попавшиеся под руку таблетки?
Выкинуть нахер. Или не выкинуть. Документы по сравнению с мультимедиа занимают крошечное место, на три порядка меньше. Короче, что хотите, то и делайте. Чот вспомнилась одна дура, рассылавшая свои дурные фотки через gmail, от чего лимит бесплатный переполнился. Стёр всё её говно нахер, возражений не последовало.

Ничего не делать. Держите их «как есть». Ну, не займут они у Вас сто гигабайт места.