Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на рабочей станции (Разное / Linux)
Изначальное сообщение		[ Отслеживать ]

"Хранение архивной информации"	+1 +/–
Сообщение от Isothiocyanate (ok), 20-Янв-19, 08:37
Доброго времени суток! Возник вопрос: как лучше хранить архивную информацию, на каком носителе и в каком формате? Информация: видео, фото, аудио, документы в pdf, doc, excel, djvu, txt, zip. Ежедневная запись/чтение не обязательна, информация архивного характера. Параметры храниения: 1. Интересуют долговечность носителя, качество и условия храниения, устойчивость к повреждающим факторам и тип повреждающих факторов, возможность чтения через длительное время. Важный параметр: цена за Гб. 2. Формат данных как-то влияет на сохранность информации? У winrar есть опция создания тома для восстановления или возможность указать % информации для восстановления. Насколько надежно хранить информацию в архивах, в частности rar, zip,tar.gz? Насколько надежно хранить информацию в зашифрованном виде, например том TrueCrypt? 3. Тип файловой системы носителя тоже важен для хранения архивных данных? 4. Варианты храниения по типу носителя: 1. Съемный hdd. 2. USB flash. 3. Лазерные DVD/CD диски. 4. Съемный ssd. 5. Облачные хранилища данных (например google disk, 15 Gb). Для себя сделал простой вывод, что информацию лучше дублировать hdd компьютера+съемный hdd+ облачное хранилище+ запись архивов на DVD Verbatium (единственные диски архивного качества, широкодоступные и по приемлемой цене) раз в квартал. Ссылки по теме: https://overclockers.ru/lab/show/83055/vybiraem-sposob-hrane... https://remontka.pro/keep-data/ http://prostocomp.net/bezopasnost/gde-xranit-dannye-na-kakie...
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Хранение архивной информации"	+/–
Сообщение от Isothiocyanate (ok), 20-Янв-19, 08:42
"Серебрянной пули" - нет : https://habr.com/ru/post/282085/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Хранение архивной информации"	+/–
Сообщение от Аноним (2), 20-Янв-19, 11:07
> 4. Варианты храниения по типу носителя: Храните на обычных (не-usb) HDD (минимум три экземпляра для действительно важных данных, в смысле оригинал и две копии на разных HDD). Желательно в географически разных местах. Дублирование на оптических дисках неуелесообразно из-за малого объема (DVD) и невысокой надежности (запись Blue-Ray в домашних условиях). Данных на flash-носителях имеют тенденцию к исчезновению без регулярной электрической подпитки. > 5. Облачные хранилища данных (например google disk, 15 Gb). Личную информацию - в облако? Даже не смешно. Только что-то маловажное + с двойным-тройиным шифрованием + это облако ваше собственное...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Хранение архивной информации"	+/–
	Сообщение от Isothiocyanate (ok), 21-Янв-19, 10:54
	https://www.digitaltrends.com/computing/keeping-data-safe-et.../ https://www.theguardian.com/technology/askjack/2018/apr/12/h... https://www.lifewire.com/ways-to-back-up-your-data-2640426 https://www.quora.com/What-is-the-best-way-to-store-digital-... Однозначного ответа на данный вопрос нет. Лучше хранить данные в открытых фрматах на разных носителях, по возможности географически удаленных, если данные не слишком важные - без шифрования и сжатия. Любой беакп лучше всего дублировать. И обновлять. Ну, чисто для прикола, отмечу , что в будущем можно будет хранить цифровые данные в виде последовательностей нуклеотидов синтетических ДНК. http://www.bbc.co.uk/guides/zt7tsg8 https://www.sciencemag.org/news/2017/03/dna-could-store-all-... https://en.wikipedia.org/wiki/DNA_digital_data_storage https://www.technologyreview.com/s/610071/storing-data-in-dn.../ https://www.ft.com/content/45ea22b0-cec2-11e7-947e-f1ea5435bcc7 https://www.wired.com/story/the-rise-of-dna-data-storage/ С учетом того, что ДНК можно извлечь из костей, хранящихся в сухих и прохладных условиях тысячелетия (например расшифровка генома неандертальца и денисовца - 50000 лет как минимум https://www.theguardian.com/science/2018/aug/22/offspring-of... https://edition.cnn.com/2018/08/22/health/neanderthal-deniso... https://annex.exploratorium.edu/evidence/lowbandwidth/INT_an... ), а современные технологии сиквенирования позволяют прочитать весь геном человека за 2-3 часа (Next Generation Sequencing  https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3841808/ ), то вполне возможно что это будет оптимальный вариант хранения архивных данных, придуманный самой природой. :)  (:
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	9. "Хранение архивной информации"	+/–
	Сообщение от Аноним (9), 21-Янв-19, 12:42
	> Однозначного ответа на данный вопрос нет. Ты себе совета спрашиваешь или просто недержание сознания? Что за мутный поток бессвязных ссылок?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	14. "Хранение архивной информации"	–1 +/–
	Сообщение от Isothiocyanate (ok), 23-Янв-19, 14:45
	>> Однозначного ответа на данный вопрос нет. > Ты себе совета спрашиваешь или просто недержание сознания? Что за мутный поток > бессвязных ссылок? И совета спросить - и ссылкой поделиться. Что плохо в том, если в этой ветке форума будет собрана подборка ссылок на полезную информацию? То, на что я ссылался - я прочитал, после затраченного времени на поиск. Тем, у кого возникнет аналогичный вопрос этот пост облегчит жизнь и стратегию выбора. Это просто проявление альтруизма к идущим следом. Реально ценную информацию лучше дублировать многократно на разных носителях (типах носителей), географически разделенных. Цифровые носители пока не отличаюся надежностью, сопоставимой с бумажными. Да, бумага горит и размокает, но и серверная стойка боится прорыва трубы или пожара. Так что тут паритет.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	24. "Хранение архивной информации"	+/–
	Сообщение от Аноним (24), 18-Ноя-19, 11:11
	А сегодняшнй геноцид людей скотом и быдлом с применением радиоактивных изотопов?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

3. "Хранение архивной информации"	+/–
Сообщение от NAI (ok), 21-Янв-19, 10:54
> Доброго времени суток! > Возник вопрос: как лучше хранить архивную информацию, на каком носителе и в > каком формате? А какие стартовые условия? Для дома, для SOHO, для Ынтерпрайза? В случае факапа как быстро потребуются данные? ПД есть(данные попадают под какой-нибудь ФЗ)? >Облачные хранилища данных (например google disk, 15 Gb). Вообще то для таких вещей необходимо использовать немного другие сервисы, например Amazon Glacier, У меня около 80 Гб выходит ~0.5$\мес. (пятьдесят центов). Плюсы: 1)сервис для бэкапов - куча девяток по надежности и прочий маркетинговый буллшит. 2)низкая цена хранения. Минусы: 1)Интерфейс и ПО. Надо разбираться и привыкать. 2)Оперативность доступа и цена - в месяц можно скачать 10% данных бесплатно. Если потребуются все данные то надо будет заплатить, если данные потребуются все и срочно, то платить придется много, если "АААА надо чтобы прям сейчас!!!" то платить придется ОЧЕНЬ много. И это все не отменяет NAS. На работе все проще - ежедневный бэкап на второй\диск\сервер + репликация на другую площадку (другое здание) + раз в две недели бэкап на отключаемый HDD. Естественно, все это автоматом делается.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Хранение архивной информации"	+/–
	Сообщение от Isothiocyanate (ok), 21-Янв-19, 10:58
	> А какие стартовые условия? Для дома, для SOHO, для Ынтерпрайза? В случае > факапа как быстро потребуются данные? ПД есть(данные попадают под какой-нибудь ФЗ)? Данные для дома и с рабочего ПК. >[оверквотинг удален] > Минусы: > 1)Интерфейс и ПО. Надо разбираться и привыкать. > 2)Оперативность доступа и цена - в месяц можно скачать 10% данных бесплатно. > Если потребуются все данные то надо будет заплатить, если данные потребуются > все и срочно, то платить придется много, если "АААА надо чтобы > прям сейчас!!!" то платить придется ОЧЕНЬ много. > И это все не отменяет NAS. > На работе все проще - ежедневный бэкап на второй\диск\сервер + репликация на > другую площадку (другое здание) + раз в две недели бэкап на > отключаемый HDD. Естественно, все это автоматом делается. В моем случае 2 рабочих ПК и домашний ноутбук - можно и ручками, ручками :)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Хранение архивной информации"	+/–
	Сообщение от NAI (ok), 21-Янв-19, 11:59
	> Данные для дома и с рабочего ПК. > В моем случае 2 рабочих ПК и домашний ноутбук - можно и > ручками, ручками :) В ряде случаем руками плохо, очень плохо т.к. высока вероятность "забыть"\"забить"\"лень сегодня". Я бы наверное сделал так - usb-sata-стакан + 3.5 HDD (какой-нибудь WD RED, ну или по вкусу) подключенный к домашнему роутеру в качестве NAS. На роутере VPN для доступа с работы (тут конечно вопрос в объемах и скоростях) + бэкап на Glicer. Хард меняем раз в 3-4 года (ну там по SMART или просто по КД), раз в полгода тестирование. Итого получаем: 1. территориально разнесенные бэкапы. - защита от пожара, потопа, изъятия. 2. один из бэкапов по сути в оффлайне (амазон) - защита от шифровальщиков работающих с SMB. 3. Данные хранятся в 3-х копиях. (ПК + USB-HDD + амазон). 4. Мониторинг. Если ХДД выйдет из строя вы это заметите и можно предпринять меры. USB-HDD ессно лучше держать включенным (и использовать в том числе и для мультимедиа нужд). DVD - эпизодически надо всеж вставлять и проверять на читаемость. 1 диск не вопрос, но когда их штук 20 - это занятие на полдня. 5. Обновляемость. Если интерфейсы(SATA\USB) поменяются(исчезнут) то нет проблем с заменой оборудования. Апгрейд съест не так много денег. Если же DVD вымрут, то найти привод к дискам может стать проблемой (это примерно как сейчас найти FDD на 3.5") P.s. как вариант NAS от synology он умеет и репликацию и бэкапы в облачные сервисв (google drive\onedrive и пр.) и тот же амазон поддерживает. Но ... железка с хардами выйдет тонн в 20.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Хранение архивной информации"	+/–
	Сообщение от Isothiocyanate (ok), 21-Янв-19, 12:14
	Если же DVD вымрут, > то найти привод к дискам может стать проблемой (это примерно как > сейчас найти FDD на 3.5") > P.s. как вариант NAS от synology он умеет и репликацию и бэкапы > в облачные сервисв (google drive\onedrive и пр.) и тот же амазон > поддерживает. Но ... железка с хардами выйдет тонн в 20. Спасибо большое за совет! Вот тут то и дело, что стоимость железки может быть очень высока. Хороший вариант USB-IDE-SATA переходник с БП и разьемами для запитки диска. И стоит он не дорого, около 20 usd. Адаптер Viewcon USB2.0-IDE/SATA (VE 158) https://sven.dp.ua/Viewcon_VE158_USB2_0_IDE-SATA_c https://rozetka.com.ua/viewcon_usb2_ide_sata_ve_158/p280870/ Это я про вариант со съемным диском для бекапа. К нему же можно подключать обычный CD/DVD дисковод так же, как и hdd 3.5/2.5 - тут на формат пофиг, думаю 3.5 5400 будут лучше 7200 так как о них даже пишут что для данных. А хранить диск лучше в паралоне в герметичном пищевом контейнере с влагопоглощающим силикогелем в пакетике, в темном и прохладном, сухом месте, подальше от источников электромагнитных полей.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Хранение архивной информации"	+1 +/–
	Сообщение от Аноним (9), 21-Янв-19, 12:40
	> Хороший вариант USB-IDE-SATA переходник с БП и разьемами для запитки диска. Плохой вариант. Говорю как пользователь нескольких подобных девайсов. > И стоит он не дорого, около 20 usd. Г#вна он не стоит. Работает через два раза на третий, диски теряет на ходу. Про скорость ни слова, чтобы не впасть в тривиальность.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	10. "Хранение архивной информации"	+/–
	Сообщение от Isothiocyanate (ok), 21-Янв-19, 16:20
	> Г#вна он не стоит. > Работает через два раза на третий, диски теряет на ходу. > Про скорость ни слова, чтобы не впасть в тривиальность. А как тогда бекапить? Только по сети на файлопомойку + VPN?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Хранение архивной информации"	+/–
	Сообщение от Аноним (2), 21-Янв-19, 19:20
	> А как тогда бекапить? Только по сети на файлопомойку + VPN? Ты так рассуждаешь, словно интерфейсы будут вымирать по чьему-то щелчку пальцами - внезапно и одновременно по всему миру. Вот есть сейчас sata/sas - ими и пользуйся. Пока что нет никаких данных о том, что в следующем году их уже не будет. А как появятся такие данные - тогда и альтернативы появятся, и не сразу ВМЕСТО, а ВМЕСТЕ С. Доброй ночи.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Хранение архивной информации"	+/–
	Сообщение от NAI (ok), 22-Янв-19, 11:50
	> Плохой вариант. > Говорю как пользователь нескольких подобных девайсов. >> И стоит он не дорого, около 20 usd. > Г#вна он не стоит. Х.з. у нас стоит 2 шт. AgeStar каких-то на 2 диска - работают без проблем, скорость ок, дает даже разметку на дисках делать (не все контроллеры это поддерживают). Год полет нормальный, без сбоев. Косяки со скоростью бывают если воткнуты 2 диска и идет параллельная работа (копирование\форматирование) - но тут скорее потолок из-за USB.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	13. "Хранение архивной информации"	+/–
	Сообщение от Аноним (9), 22-Янв-19, 13:45
	> Х.з. у нас стоит 2 шт. AgeStar каких-то на 2 диска - > работают без проблем, Попалось сразу два некосячных экземпляра, повезло вдвойне. В разное время покупали эти переходники по 5-7шт - редко когда хоть один из 5 работал более-менее нормально.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Хранение архивной информации"	+/–
Сообщение от DiabloPC (ok), 10-Ноя-19, 11:42
> Мой пользовательский опыт подсказывает, что. лучше всего хранить информацию в облаке. > Научен горьким опытом, когда HDD выходит из строя или носитель теряется. > Плюсы облака: > - Синхронизация; > - Доступность на разных платформах; > - Быстрый доступ через интернет отовсюду; > - Относительно низкие цены. Минусов у облака не меньше чем плюсов и самый большой минус это хранение своей информации непонятно где и непонятно у кого. Какова гарантия сохранности информации там тоже до конца не ясно, но ИМХО явно не выше чем на собственном RAID1, который ко всему ещё и локально доступен, так что исчезает привязка к каналу интернета. Из минусов своего рейда только возможность выхода БП с выжиганием всех дисков, но здесь есть два момента: 1 - нечего покупать питальники которые стоят дешевле чашки кофе, 2 - а что мешает синкать нужную инфу между двумя машинами в локальной сети? В таком развале шансы на потерю инфы стремятся к полному нулю, т.к каковы шансы того что пара дисков умрёт одновременно да ещё и в разных железяках? Ну да, диски ес-сно не по типу гринов брать нужно, а хоть что-то более-менее серьёзное.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Хранение архивной информации"	+/–
	Сообщение от Licha Morada (ok), 12-Ноя-19, 01:57
	> ... на собственном RAID1, который ко всему ещё и > локально доступен, так что исчезает привязка к каналу интернета. "Локально" это там, где дом/оффис, или там, где вы? А если в критичный момент времени это не одно и то же? > Из минусов > своего рейда только возможность выхода БП с выжиганием всех дисков Нет, не только. Ещё есть варианты "затопили", "сожгли", "украли", "полетел один диск и оказалось что второй скрывал терминаьную болезнь" и т.д. Это несколько узкий подход, он, в приципе, мало чем отличается от "только облака, остальное ересь". Имеет смысл дополнять одни решения другими, в рамках размунмости.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	21. "Хранение архивной информации"	+/–
	Сообщение от DiabloPC (ok), 14-Ноя-19, 12:57
	> "Локально" это там, где дом/оффис, или там, где вы? А если в > критичный момент времени это не одно и то же? Для таких случаев у меня всё железо доступно online, соответственно я могу выдернуть любую инфу в любой момент времени, не зависимо от моего местоположения. > Нет, не только. Ещё есть варианты "затопили", "сожгли", "украли", "полетел один диск > и оказалось что второй скрывал терминаьную болезнь" и т.д. > Это несколько узкий подход, он, в приципе, мало чем отличается от "только > облака, остальное ересь". Имеет смысл дополнять одни решения другими, в рамках > размунмости. Ну если смотреть с этой стороны - я скорее добавлю ещё один такой-же рейд территориально отдаленный от первого и буду синкать данные между ними. Итого 4 диска, с 4-я копиями да ещё и в разных точках. Что ещё нужно? А всяким облакам ну не доверяю я ;)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Хранение архивной информации"	+/–
	Сообщение от Licha Morada (ok), 15-Ноя-19, 02:05
	>> "Локально" это там, где дом/оффис, или там, где вы? А если в >> критичный момент времени это не одно и то же? > Для таких случаев у меня всё железо доступно online, соответственно я могу > выдернуть любую инфу в любой момент времени, не зависимо от моего > местоположения. Замечателньно, правильное решение. Только тогда "привязка к каналу интернета", о которой вы говорили в пользу локального хранилища, никуда не исчезает. >> Нет, не только. Ещё есть варианты "затопили", "сожгли", "украли", "полетел один диск >> и оказалось что второй скрывал терминаьную болезнь" и т.д. >> Это несколько узкий подход, он, в приципе, мало чем отличается от "только >> облака, остальное ересь". Имеет смысл дополнять одни решения другими, в рамках >> размунмости. > Ну если смотреть с этой стороны - я скорее добавлю ещё один > такой-же рейд территориально отдаленный от первого и буду синкать данные между > ними. Итого 4 диска, с 4-я копиями да ещё и в > разных точках. Что ещё нужно? А всяким облакам ну не доверяю > я ;) Я от вас ничего не требую. Более того, отчасти солидарен с вашим недоверием. Но вторую, территориально отдаленную площадку строить дорого. Иногда это оправданно, но, чаще всего, нет. Добиться снижения риска за приемлемую цену можно с помощью облака. А можно и не добиться, или за неприемлемую цену, зависит от того, как готовить. Напомню, мой тезис в том, что разумно дополнять одни решения другими. Облачные локальными, или наоборот. IMHO, вы необоснованно приуменьшили минусы и преувеличили плюсы хранения информации на своём рейде, с которым ничего не случится.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

18. "Хранение архивной информации"	+/–
Сообщение от Аноним (18), 11-Ноя-19, 15:08
По цене и будущей совместимости однозначно BD-R. 1 копию держать у себя дома, 1 на дачу или в гараж. 120 р. на архив 25 ГБ, со сроком хранения в 10 лет, получается 50 коп. за гигабайт в год. Чтобы диски меньше деградировали, пакуйте их в ящики, герметизируйте и храните под слоем земли в погребе или подполе, где температура низкая и стабильная. В таких условиях должны неплохо храниться даже обычные диски, не хуже специальных архивных. Чтобы уменьшить риск потери данных, храните их не сжатыми. Это резко повышает шансы прочитать хотя бы часть данных, если носитель деградировал или был поврежден. Шифрования лучше избегать, либо накладывать на уровне отдельных файлов. Никаких криптоконтейнеров. Никаких образов ФС. Не полагайтесь на программные продукты. Вы можете оказаться в ситуации, когда обещанная функциональность не выполнила свои задачи в полном объеме (процент данных на восстановление и прочая маркетинговая лапша) или вы не можете запустить программу на современной ОС и ваш компьютер не поддерживает работу старой. В идеале софт не должен требоваться вовсе, но если требуется, он должен быть свободным и широкораспространенным. tar используется 40 лет и скорее всего не выйдет из употребления в следующие 10-20, в отличие от хипстерской системы с шифрованием, заточенной под Windows. Вы не просто копируете куда-то данные, а создаете процедуры помещения данных в архив и возвращения их оттуда. Процедура возвращения должна быть настолько простой, насколько это возможно. В описанной схеме - снять диск с полочки, скопировать, вернуть на полочку. Либо - приехать на дачу, выкопать ящик с дисками, достать нужный, привезти домой, вставить, скопировать данные, отвезти диск обратно и закопать все как было, до следующего раза. Архивация тоже не особо сложная - вы пишете на 2 диска новые файлы и ставите один на полку, а второй диск отвозите на дачу, когда едете на нее в следующий раз. Единственная сложность - не лениться это делать регулярно, не жопить деньги на целый BD ради 5 ГБ данных и т.п.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Хранение архивной информации"	+/–
	Сообщение от Licha Morada (ok), 12-Ноя-19, 02:03
	Всё правильно вы написали, вот прямо каждый абзац. Не хватило только одного. Прикинуть стоимость всего этого, в деньгах, времени и душевных силах: диски, поддержка доступности оборудования, на дачу - с дачи, выкпать - закопать, не забыть, не лениться... И спросить себя, а может лучше нафиг, сразу в /dev/null?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

23. "Хранение архивной информации"	+1 +/–
Сообщение от Аноним (24), 18-Ноя-19, 11:09
Для дома, только в некоммерческих целях можешь использовать этот скрипт: https://www.linux.org.ru/forum/admin/15041201?cid=15051206 https://www.linux.org.ru/forum/admin/15041201?cid=15052218 В той теме даны ответы на все вопросы. Кому надо бекапить в коммерческий целлях оставьте здесь свои контакты.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Хранение архивной информации"	+/–
	Сообщение от Аноним (18), 19-Ноя-19, 16:44
	> Для дома, только в некоммерческих целях можешь использовать этот скрипт: > https://www.linux.org.ru/forum/admin/15041201?cid=15051206 > https://www.linux.org.ru/forum/admin/15041201?cid=15052218 > В той теме даны ответы на все вопросы. > Кому надо бекапить в коммерческий целлях оставьте здесь свои контакты. Решена надуманная проблема - возможной подмены диска с бэкапом. Именно ради этого пляски с подписями и хэшами. В реальности такие шпионские страсти не случаются совершенно никогда. Если злоумышленник может незаметно подменить физический носитель бэкапа, значит их надо шифровать (возможна кража данных), а этого сделано не было. Получается, что здесь или оверинжиниринг, или неполноценное решение, не соответствующее задачам. Зависит от конкретной модели угроз. Для серьезных коммерческих задач эта полепка из глины и веток не годится. Не занимайтесь спамом. Метаданные вроде хэшей и подписей надо хранить отдельно. Вместе с информацией, на каком диске что лежит.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	26. "Хранение архивной информации"	+/–
	Сообщение от Аноним (26), 21-Ноя-19, 13:24
	В темах по ссылках скрипт идет как бонус к общей информации о организации бекапа длительного хранения. Конкретно этот скрипт предполагает что данные не личные, не секретные или хранятся в физически защищенном месте. Предназначен для хранения репозиториев, документации, исходников которыми могут пользоваться много людей и при желании верифицировать их целостность. Я и личные фото с отдыха им бекаплю. Предлагаемый скрипт есть пример. Для тех кому надо обеспечить кроме целостности, также приватность данных и сами одну строчку в скрипт добавить не могут есть расширенная версия. Задача скрипта как раз и есть в создании индекса что и где лежит. Индекс расширен размером и хешами для контроля целостности файлов, а подпись индекса гарантирует его целостность. Индекс диска хранитса на каждом диске, кроме того создается общий отдельный индекс всего архива, который надо хранить отдельно. Публичный ключ предлагается хранить на каждом диске, вместе с общим индексом и в распечатанном на бумаге виде. Создаются и подписанные хеши дисков для печати. Секретный ключ уничтожается для гарантии неизменности архива. Формат создаваемого индексного файла Manifest изменять нельзя, это открытый стандарт читаемый разным ПО.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Хранение архивной информации"	+/–
	Сообщение от Аноним (18), 21-Ноя-19, 18:46
	> В темах по ссылках скрипт идет как бонус к общей информации о > организации бекапа длительного хранения. > Конкретно этот скрипт предполагает что данные не личные, не секретные или хранятся > в физически защищенном месте. Предназначен для хранения репозиториев, документации, исходников > которыми могут пользоваться много людей и при желании верифицировать их целостность. > Я и личные фото с отдыха им бекаплю. Для проверки целостности не нужна подпись списка хэшей. > Предлагаемый скрипт есть пример. Для тех кому надо обеспечить кроме целостности, также > приватность данных и сами одну строчку в скрипт добавить не могут > есть расширенная версия. Ох, вам лишь бы продать что-то ненужное. > Задача скрипта как раз и есть в создании индекса что и где > лежит. Индекс расширен размером и хешами для контроля целостности файлов, а > подпись индекса гарантирует его целостность. Индекс диска хранитса на каждом диске, > кроме того создается общий отдельный индекс всего архива, который надо хранить > отдельно. Публичный ключ предлагается хранить на каждом диске, вместе с общим > индексом и в распечатанном на бумаге виде. Создаются и подписанные хеши > дисков для печати. Секретный ключ уничтожается для гарантии неизменности архива. Если индекс лежит вместе с данными, он бесполезен. Гарантия неизменности либо не нужна, либо недостаточна, об этом уже писал. > Формат создаваемого индексного файла Manifest изменять нельзя, это открытый стандарт читаемый > разным ПО. Это надуманное требование.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	30. "Хранение архивной информации"	+/–
	Сообщение от Аноним (30), 22-Ноя-19, 12:54
	> Для проверки целостности не нужна подпись списка хэшей. Для __гарантии__ возможности проверки целостности бекапа наличие подписи хешей необходимо и достаточно! Это азы, стыдно не знать. > Ох, вам лишь бы продать что-то ненужное. Тебе не нужно, не бери. > Если индекс лежит вместе с данными, он бесполезен. Гарантия неизменности либо не нужна, либо недостаточна, об этом уже писал. Наличие в доступе ПОДПИСАННОГО индекса, гарантирует возможность проверки целостности бекапа, это необходимое и достаточное условие гарантирующие возможность проверки целосности бекапа. Лучшая доступность это когда ПОДПИСАННЫЙ индекс идет вместе с бекапом! Стыдно такого не знать, это как 2+2. Скрипт может создавать и общий индекс для всех томов бекапа, если кому надо. > Это надуманное требование. Требование к формату индекса: " The Manifest2 file is a plain text file. Each line of the file has the following format: <type> <filename> <size> <hash-type> <hash> [<hash-type> <hash> ...] " обусловлено наличием разного ПО которое с индексами в этом формате умеет работать. Если смените формат индекса, то существующие ПО не сможет его обрабатывать. Цели шифровать бекап небыло. В этом виде скрипт предназначен для публичных бекапов, возможно в сети инет или в виде библиотеки в организации. Один человек сбекапил, другие пользуются. В РФ сегодня с приватностью строго, могут 5 лет дать: https://www.linux.org.ru/forum/security/15350457?cid=15357489 А что ты такое секретное на бекапа собираешься шифрованием прятать?  Порнуху от родителей?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	33. "Хранение архивной информации"	+/–
	Сообщение от Аноним (18), 22-Ноя-19, 14:31
	>> Для проверки целостности не нужна подпись списка хэшей. > Для __гарантии__ возможности проверки целостности бекапа наличие подписи хешей необходимо > и достаточно! Это азы, стыдно не знать. Нет. Для гарантии нужно окропить бэкап святой водой и прочитать молитву. Подпись в вашем кейсе гарантирует только целостность списка хэшей. Я могу его подменить вместе с диском, сделав другую подпись и для ваших гипотетических пользователей ничего не изменится. > Тебе не нужно, не бери. Здесь не барахолка, а форум по администрированию. Рекламируйте свои услуги в специальном разделе. >> Если индекс лежит вместе с данными, он бесполезен. Гарантия неизменности либо не нужна, либо недостаточна, об этом уже писал. > Наличие в доступе ПОДПИСАННОГО индекса, гарантирует возможность проверки целостности > бекапа, это необходимое и достаточное условие гарантирующие возможность проверки целосности > бекапа. Лучшая доступность это когда ПОДПИСАННЫЙ индекс идет вместе с бекапом! > Стыдно такого не знать, это как 2+2. Ничего оно не гарантирует. Представьте, что не прочиталась ваша подпись. Или файлик с хэшами. Или злобный хакер подменил весь диск, сделал новый список хэшей и подпись. > Скрипт может создавать и общий индекс для всех томов бекапа, если кому > надо. А если никому не надо? :) >> Это надуманное требование. > Требование к формату индекса: > " > The Manifest2 file is a plain text file. Each line of the > file has the following format: > <type> <filename> <size> <hash-type> <hash> [<hash-type> <hash> ...] > " > обусловлено наличием разного ПО которое с индексами в этом формате умеет работать. > Если смените формат индекса, то существующие ПО не сможет его обрабатывать. Требование к обработке архива разнообразным ПО - ваше, топикстартер его не вводил. > Цели шифровать бекап небыло. В этом виде скрипт предназначен для публичных бекапов, > возможно в сети инет или в виде библиотеки в организации. Один > человек сбекапил, другие пользуются. > В РФ сегодня с приватностью строго, могут 5 лет дать: https://www.linux.org.ru/forum/security/15350457?cid=15357489 Плохим специалистам всегда больше интересна политика, чем их профильная область. > А что ты такое секретное на бекапа собираешься шифрованием прятать?  Порнуху > от родителей? Если для вас защита данных ограничивается сокрытием порнографии, что вы делаете на форуме по администрированию. Вам надо идти на один из форумов, где малолетки обмениваются картинками с хентаем. Вы будете там уместны.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	34. "Хранение архивной информации"	+/–
	Сообщение от Аноним (34), 23-Ноя-19, 09:11
	> Подпись в вашем кейсе гарантирует только целостность списка хэшей. Я могу его подменить вместе с диском, сделав другую подпись и для ваших гипотетических пользователей ничего не изменится. >Или злобный хакер подменил весь диск, сделал новый список хэшей и подпись. У пользователя есть публичный ключ полученный из доверительного источника, например от руководителя при устройстве на работу. В том числе хранятся бумажные копии публичного ключа с которыми можно сверится. Этим публичным ключом проверяется подпись индексного файла Manifest с хешами. По этому подменить индексный файл или изменить в нем хеши невозможно. А надежное уничтожение секретного ключа, сразу после подписания индексов Manifest, дает гарантию невозможности подделки архива. > Ничего оно не гарантирует. Представьте, что не прочиталась ваша подпись. Или файлик с хэшами. Данные с носителя могут перестать считыватся со временем. Для этого создают копии бекапа и хранят их в разных местах. Скрипт кроме подписанного индекса Manifest, который хранится на носителе вместе с данными, может, по запросу, создавать и подписанный индекс с хешами всех томов архива. Который физически хранится на другом носителе. > Требование к обработке архива разнообразным ПО - ваше, топикстартер его не вводил. Был вопрос о организации архива. Это значит что архив надо сначала создать, а потом с ним работать. > Плохим специалистам всегда больше интересна политика, чем их профильная область. Хороший специалист всегда должен присматривать за законодательством в профильной области.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	37. "Хранение архивной информации"	+/–
	Сообщение от Аноним (37), 26-Ноя-19, 16:51
	> Я могу его подменить вместе с диском, сделав другую подпись и для ваших гипотетических пользователей ничего не изменится. > Или злобный хакер подменил весь диск, сделал новый список хэшей и подпись. Публичный ключ сразу раздали всем пользователям архива. Пользовались подписали публичный ключ архива своими секретными ключами. Если архив подменили целиком то изменился публичный ключ. Это станет всем всюду заметно. Данный том архива пометят как скомпроментированный.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	27. "Хранение архивной информации"	+/–
	Сообщение от Аноним (26), 21-Ноя-19, 13:53
	>> Для дома, только в некоммерческих целях можешь использовать этот скрипт: >> https://www.linux.org.ru/forum/admin/15041201?cid=15051206 >> https://www.linux.org.ru/forum/admin/15041201?cid=15052218 >> В той теме даны ответы на все вопросы. >> Кому надо бекапить в коммерческий целлях оставьте здесь свои контакты. > Получается, что здесь или оверинжиниринг, или неполноценное решение, не соответствующее задачам. Зависит от конкретной модели угроз. Эфективно и экономно решена задача гарантии целостности публичного бекапа. От пользователя публичного бекапа требуется только получение публичного ключа от доверительного источника. Сам бекапа или его частичную копию (диск) можно получать от недоверительного источника. Зачем это? Для организации публичного бекапа реп, док, сорцов, данных...
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	29. "Хранение архивной информации"	+/–
	Сообщение от Аноним (18), 21-Ноя-19, 18:55
	> Эфективно и экономно решена задача гарантии целостности публичного бекапа. От пользователя > публичного бекапа требуется только получение публичного ключа от доверительного источника. > Сам бекапа или его частичную копию (диск) можно получать от недоверительного > источника. Зачем это? Для организации публичного бекапа реп, док, сорцов, данных... Публичный бэкап - это что-то новенькое. У вас библиотека, куда любой может прийти, взять напрокат диск с бэкапом, ну конечно же. То, что вы описываете - это какая-то сеть дистрибуции, но никак не бэкап.   Почитайте литературу, тот же Backup & Recovery. Разберетесь с терминами хотя бы. На лоре еще никто не стал экспертом в администрировании линуксов, уверяю вас. Еще вам стоит русский подтянуть. Очень-очень-очень плохой русский.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	31. "Хранение архивной информации"	+/–
	Сообщение от Аноним (30), 22-Ноя-19, 13:09
	Прочел твои "экспертные" коментарии и думаю что литературой по бекапам, необходимым и достаточным условиям гарантии возможности проверки целостности бекапа, стоит прочесть именно тебе! Хеши подписанные цифровой подписью используются много десятилетий, это стандарт который просто стыдно не знать! Ты когда свою первую ISO-шку с GNU/Linux скачал разве не скачивал лежащий рядом файл с подписанными к этой исошке хешами? Подпись файла с хешами не проверял? Хеши ISO-шки не сверял? Ты просто троль виндузятник ниразу не видивший *NIX.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	32. "Хранение архивной информации"	+1 +/–
	Сообщение от Аноним (18), 22-Ноя-19, 14:14
	> Прочел твои "экспертные" коментарии и думаю что литературой по бекапам, необходимым и > достаточным условиям гарантии возможности проверки целостности бекапа, стоит прочесть > именно тебе! Для проверки целостности хватит списка имен файлов и их хэшей в файлике, и чексуммы самого файлика. Подпись нужна для того, чтобы подтвердить аутентичность этого файлика. Вот тут ваша практика уходит от нормальной. Вы используете какие-то одноразовые ключи. Подпись ничего не аутентифицирует и фактически выполняет роль чексуммы! > Хеши подписанные цифровой подписью используются много десятилетий, это стандарт который > просто стыдно не знать! Ты когда свою первую ISO-шку с GNU/Linux > скачал разве не скачивал лежащий рядом файл с подписанными к этой > исошке хешами? Подпись файла с хешами не проверял? Хеши ISO-шки не > сверял? Хэши с цифровой подписью используются, но не так, как это делаете вы. > Ты просто троль виндузятник ниразу не видивший *NIX. Начинается. Я свою точку зрения аргументирую и вашу жизненную историю не трогаю (хотя мог бы :). Не надо съезжать на троллинг. Это не троллинг. Отвечайте за свой "товар".
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	35. "Хранение архивной информации"	+/–
	Сообщение от Аноним (34), 23-Ноя-19, 09:45
	> Для проверки целостности хватит списка имен файлов и их хэшей в файлике, и чексуммы самого файлика. > Подпись нужна для того, чтобы подтвердить аутентичность этого файлика. Вот тут ваша практика уходит от нормальной. Вы используете какие-то одноразовые ключи. Подпись ничего не аутентифицирует и фактически выполняет роль чексуммы! Моя математическая модель ДАЕТ ГАРАНТИЮ возможности проверки целосности архива. К сожалению твое сегодняшние образование не позволяет тебе это понять. > Хэши с цифровой подписью используются, но не так, как это делаете вы. Я абсолютно ничего нового не добавил. Патент на алгоритм подписи файла с использованием секретного и публичного ключа был выдан еще в прошлом тысячелетии и его строк действия истек в нулевых. Сегодня любой, без каких либо патентных отчислений может создать индекс с хешими файлов архива, пару секретный и публичный ключ, подписать индекс секретным ключом и для дачи гарантии неизменности индекса надежно уничтожить секретный ключ. Публичный ключ разгласить среди пользователей и распечатать. Для проверки целостности индексного файла с хешами необходимо и достаточно только публичного ключа. Так учили меня и так делают все с кем я общался, пока кроме тебя. Вас удивляет уничтожение секретного ключа? Надежное хранение секретного ключа ОЧЕНЬ дорого. А компроментация секретного ключа значит компроментация всего архива. Секретный ключ уничтожается сразу после подписания индексов с хешами (Manifest) для дачи гарантий их неизменности, снижения цены владения архивом и исключения человеческого фактора: про*рать секретный ключ. А технология "совершенной прямой секретности" (PFS) тебя не смущает?  Там также, для гарантий целостности и приватности передаваемых в сети данных, используются подписанные временные ключи, которые уничтожаются.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	36. "Хранение архивной информации"	+/–
	Сообщение от Аноним (34), 23-Ноя-19, 10:10
	> Вот тут ваша практика уходит от нормальной. Вы используете какие-то одноразовые ключи. Кажись я понял суть проблемы. Вы или вообще ничего не знаете или читали плохой учебник. Я предполагал что вы ничего не знаете. Но так как вы, наверно, читали учебник на русском, предположу что плохой учебник. В учебниках которые читал я написано что секретный ключ, после использования подлежит немедленному уничтожению!!! В крайних случаях, если в будущем планируется его повторное использование, допускается хранение ключа на сьемном носителе. Хранить секретные ключи в работающей системе категорически запрещено. Теперь сверим наши учебники. Для примера возьмем тему подписание модулей ядра Линукс при их установки. Что в вашем учебнике рекомендуют делать с файлом ключа: certs/signing_key.pem ? В моем - надежно удалять сразу после подписания модулей!!! В крайнем случае хранить только на сьемном носителе для подписания возможных обновлений модулей.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема