[artenaki]

рар архивирования с данными для восстановления? »

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

[Iska]

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

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

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

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

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

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

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

7. —//—

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

9. —//—

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

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

WinRAR может восстановить 5% повреждений в виде непрерывного куска, а если повреждений больше? »

Тады — «Ой».

Или сохранение в rar, но без компрессии »

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

[dan_p]

Iska,

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

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

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

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

Цитата artenaki: Или сохранение в rar, но без компрессии » Вот уж бессмысленное действие. »

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

[artenaki]

бессмысленное действие »

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

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

[Anton04]

1. Как разобраться с дублированием/ пересечением? Все скопировать в одно место, потом сравнивать в Тотал Коммандере? Или есть спец. заточенные под это программы? »

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

4. Чисто теоретически - есть ли какая-либо возможность проверить файлы (хотя бы какие-нибудь форматы) на "битость" - то есть этот документ не массив битов, поврежденный по тем или иным причинам, а тот, который можно открыть? »

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

9. Есть ли смысл делать MBR вместо GPT для повышения шансов восстановления ЖД после отказа? А если жд потребуется в итоге по общему весу файлов больше 2 Тб? »

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

11. Есть ли какие-либо другие способы повышения надежности/ защиты от утери »

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

[Iska]

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

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

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

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

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

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

Теоретически могут предположить одну из причин применения такого метода… »

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

[Busla]

1. Как разобраться с дублированием/ пересечением? Все скопировать в одно место, потом сравнивать в Тотал Коммандере? Или есть спец. заточенные под это программы? »

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

Достаточным вариантом по надежности будет два жд (по 1 или 2 ТБ или 3 ТБ, как получится) под архив с дублированием файлов на каждый »

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

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

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

Практически этого никто никогда не делает, потому что это требует ру́́чек и гла́́зок. »

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

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

7. —//— »

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

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

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

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

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

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

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

[Jula0071]

И за длиннопост »

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

балансу цена-надежность-удобство доступа. С небольшим уклоном в надежность. »

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

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

[Iska]

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

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

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

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

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

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

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

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

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

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

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