Re: DIR-300 даёт отлуп

2016-03-24 Пенетрантность Vasiliy P. Melnik 
заменить блок питания, если не поможет - пора купить новый, тем более
железка гораздо быстрее стоит сейчас копейти. Например тот же тплинк 841 ,
только брать два последних hwver - 10, 11

но лучше сразу купить

З.Ы. что касается того, что у кого-то до сих пор работает, то могу сказать
одно - под именем дир 300 было такое разное количество железяк, что в этом
нет ровно ничего удивительно


25 марта 2016 г., 6:16 пользователь Евгений Золотов 
написал:

> Друзья, нужен совет. Слегка оффтоп..
>
> Есть точка доступа Wi-Fi, на которой написано D-Link DIR-300. Задача:
> раздавать интернет по квартире. Настроек немного и всё, в общем,
> стандартно, перепроверено на сто раз.
> Проблема: попытка подключения к нему с различных устройств (в том
> числе с ноутбука под дебианом) часто приводит к ошибке "Не могу
> получить IP-адрес".
>
> Гуглил, но ничего полезного не нарыл: глупые советы вроде ограничить
> доступ по MAC-адресам, жёстко задать канал и т.п. Впрочем, на всякий
> случай всё пробовал, не помогает.
>
> Что сделать, куда посмотреть?
>
> Спасибо!
>
> С уважением, Е.
>

Re: DIR-300 даёт отлуп

2016-03-24 Пенетрантность Victor Wagner 
On Fri, 25 Mar 2016 09:16:46 +0500
Евгений Золотов  wrote:

> Друзья, нужен совет. Слегка оффтоп..
> 
> Есть точка доступа Wi-Fi, на которой написано D-Link DIR-300. Задача:

Лично я долго эксплуатировал Dir-300 и не имел с ней никаких проблем. 
(пока не захотелось гигабита и не забился нафиг 2.4ГГц диапазон в доме)
Но - как только мне от нее понадобилось что-то кроме собственно
бриджа для wifi, то есть функции гейтвея и dhcp-сервера, я туда вместо
родной прошивки DD-WRT поставил. Настроек сразу стало сильно больше.


> раздавать интернет по квартире. Настроек немного и всё, в общем,
в

-- 
   Victor Wagner

DIR-300 даёт отлуп

2016-03-24 Пенетрантность Евгений Золотов 
Друзья, нужен совет. Слегка оффтоп..

Есть точка доступа Wi-Fi, на которой написано D-Link DIR-300. Задача:
раздавать интернет по квартире. Настроек немного и всё, в общем,
стандартно, перепроверено на сто раз.
Проблема: попытка подключения к нему с различных устройств (в том
числе с ноутбука под дебианом) часто приводит к ошибке "Не могу
получить IP-адрес".

Гуглил, но ничего полезного не нарыл: глупые советы вроде ограничить
доступ по MAC-адресам, жёстко задать канал и т.п. Впрочем, на всякий
случай всё пробовал, не помогает.

Что сделать, куда посмотреть?

Спасибо!

С уважением, Е.

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Андрей Любимец 
24.03.2016 15:07, Artem Chuprina пишет:
> Андрей Любимец -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
> 13:26:26 +0600:
> 
>  >>  >>  >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех 
> винтов по
>  >>  >>  >>  >> полтерабайта сделает полтора?
>  >>  >>  >> 
>  >>  >>  >>  SBK> Места-то сколько надо?
>  >>  >>  >> 
>  >>  >>  >> Бэкап-сервер. Лучше больше.
>  >>  >> 
>  >>  >>  > Ну тогда все просто.  Больше чем raid5 вы не получите.
>  >>  >> 
>  >>  >> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью. 
>  В
>  >>  >> смысле, в случае вылета винта.
>  >>  АЛ> я за raid10 -- погугли "Why RAID 5 Sucks"
>  >> 
>  >> Погуглил.  Ничего внятного не увидел.
>  >> 
>  >> Можно пояснить?
>  АЛ> Дело в том, что деградировавший RAID5 до завершения ресинка становится по
>  АЛ> надёжности аналогичен RAID0. Ресинк же больших дисков может идти 
> достаточно
>  АЛ> долго. Если риск потерять данные в этот период не смущает, то ради 
> бога...
>  АЛ> Здесь подробнее https://geektimes.ru/post/78311/
> 
> А RAID10 в этом смысле чем-то лучше? Или, если уж говорить о 50% потере
> пространства, делать RAID6?
Я больше доверяю RAID10, мне он представляется более простым чем RAID6,
соответственно менее подверженным ошибкам
(https://www.opennet.ru/opennews/art.shtml?num=40412 ). И производительность
его повыше будет.
> 
> Вообще, жалко полтерабайта, оно лишним не будет...  И это все-таки
> бэкап, вторая копия данных.  Хотя там предусмотрено хранение прошлого.
> 
Как я Вас понимаю! нужно просто принять риск и быть к нему готовым (хотя бы
психологически, но можно распечатать и положить в сервер инструкцию по замене
диска). При том ваш RAID5 вполне может спокойно многие лета безпроблемно
работать.

Да, проблема не техническая, но,видимо, из области психологии: доверие,
принятие и тп ;)

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Melleus 
Oleksandr Gavenko  writes:

> Я перестал делать конспекты авторучкой - в некотрых записях паста выцвела или
> растворилась по бумаге. Теперь даже бабушкины рецепты в электронном виде.
>

Пастой пишет шариковая ручка, авторучка, же - имеет перо и пишет
чернилами. И если пометки, сделанные пастой, со временем выгорают, то
надписи чернилами могут сохранять читаемость весьма и весьма долго. А
еще письмо пером дарит неимоверные ощущения легкости и имеет
профилактический эффект от туннельного синдрома. Причем это не
обязательно должен быть Монблан. Можно попробовать хоть китайского Хера,
они бывают очень даже неплохи. Или бывают очень даже технологичные и
затейливые японские Пилоты, но они и подороже, конечно.

И чернила можно архивные подобрать, чтобы пра-пра-правнукам письма
писать. Бумага, она такая, что может и отключение света вынести лет на
1000 и еще много чего. А вот вынесет ли это электронный носитель?- тот
еще вопрос.

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Artem Chuprina 
Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
17:52:45 +0200:

 >> Но общий принцип прост: чексумма должна храниться, и должна быть такой,
 >> чтобы при повреждении данных их можно было восстановить.  По
 >> документации, этим свойством обладает, например, RAID-Z у zfs.  Он не
 >> только вылет диска переживает, но и битый бит может восстановить.  zfs
 >> сама по себе проверяет чексуммы (и при чтении тоже), но понятно, что
 >> узнать "данные побились" и восстановить данные - не одно и то же.
 >>
 >> В качестве более простого и надежного решения - база md5sum (если речь
 >> не идет о намеренном вторжении, то md5 достаточно), и более одной копии
 >> архива (тут уже речь идет скорее об архиве, а не о бэкапе).  Каковые
 >> копии никогда не втыкаются в один комп (что подразумевает физически
 >> разные носители).
 >>
 >> И, соответственно, если регулярная проверка одной копии показала
 >> несовпадение md5, эти данные восстанавливаются из другой копии.

 OG> Не сильно улавливаю разницу между бекапом и архивом. Речь о домашних 
медийных
 OG> данных, нужно обеспечить их сохранность пока я жив.

 OG> Непрерывность доступа не нужна. Раз в пол года втыкаю внешний накопитель. 
Т.е.
 OG> даже демон не нужен.

Это скорее архив, если ты их не пересматриваешь регулярно.

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

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

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Artem Chuprina 
Dmitry E. Oboukhov -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
18:35:57 +0300:

  В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
  блоками. При текущей плотности записи этого не изсежать. Используются 
  коды с
  обнаружением/корекцией ошибок. Со временем диск деградирует и 
  предусмотренна
  даже "свободная" область, куда со временем перемещаются данные из 
  ненадежных
  областей. Когда область заканчивается контролер диска по SMART скажет что 
  он
  сдох.
 MAA>>> Хранить на рейде не предлагать?

 >> До внуков?  Ни в коем разе.

 DEO> именно на рейде и хранить.
 DEO> просто до внуков множество рейдов сменится.

 DEO> а так чтобы "записал и до внуков" такого носителя сейчас нет и никогда
 DEO> (в обозримые 100 лет) не будет.
 DEO> ибо через 10 лет врядли найдется куда воткнуть то на что сегодня
 DEO> запишете данные.
 DEO> а через 20 уж тем паче.

 DEO> то есть каждые n лет по любому придется данные копировать на более
 DEO> новый носитель. это во первых.
 DEO> во вторых в течение этих n лет данные тоже как бы нужны бывают (я вот
 DEO> смотрю на то видео которое снимал 2 года назад иногда)

 DEO> соответственно RAID + домашний сервак с ним (+ бакап тоже на RAID) -
 DEO> ваще как бы маст хэв.

Понятно, что сменится много носителей.  Но рейд не заменяет бэкапа, а
бэкап в таком раскладе как раз заменяет рейд.

Хинт: второй носитель с бэкапом вообще-то хранится в выключенном
состоянии, подключаясь только на время обновления, и дешевле всего
держать его в виде винчестера с USB-интерфейсом.

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Oleksandr Gavenko 
On 2016-03-24, Dmitry E. Oboukhov wrote:

> именно на рейде и хранить.
> просто до внуков множество рейдов сменится.
>

> а так чтобы "записал и до внуков" такого носителя сейчас нет и никогда
> (в обозримые 100 лет) не будет.

Я перестал делать конспекты авторучкой - в некотрых записях паста выцвела или
растворилась по бумаге. Теперь даже бабушкины рецепты в электронном виде.

C CD/DVD была эпопея 7-10 лет назад. У меня некоторые DVD диски с бекапами и
CD-R c raw аудио переставали читаться спустя 3-5 лет.

Находил статьи когда некий айтишный журнал записывал диски в начале 2000 и
пробовал из читать спустя 10 лет - положительных считываний мало.

Тут авторитетно долгоживучесть лазерных диски рассматривается:

  http://www.cd-info.com/archiving/

По итогу не удобно мучится в кучей дисков. DVD ридер уже лет 5 как выключеный,
хотя и вкручен...

Я коствеено видел что до сих пор https://en.wikipedia.org/wiki/Tape_library в
использовании и никто не может перебить отношение цены к обьему. Надежность
решения не ясна.

> ибо через 10 лет врядли найдется куда воткнуть то на что сегодня
> запишете данные.
> а через 20 уж тем паче.
>
> то есть каждые n лет по любому придется данные копировать на более
> новый носитель. это во первых.

Согласен. Так с ATA интерфейса мигрировал на SATA.

Перенос на современные носители и географическое ращнесение хранилищь не
отменяется.

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

Я ощущаю что наколеночное решение будет отлично работать.

> во вторых в течение этих n лет данные тоже как бы нужны бывают (я вот
> смотрю на то видео которое снимал 2 года назад иногда)
>
У меня пока данные влазят в ПК, задачи выность редко используемые данные в
архив нету.

> соответственно RAID + домашний сервак с ним (+ бакап тоже на RAID) -
> ваще как бы маст хэв.

Я держу архивы на HDD, которое включаются только на время создания очередной
копии. Остальное время HDD обесточен и в мягкой коробочке.

-- 
http://defun.work/

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Sergey B Kirpichev 
On Thu, Mar 24, 2016 at 06:39:05PM +0300, dimas wrote:
> а потом внуки спросят "а че за файлы такие - точка джыпэгэ, и чем это все
> открыть?")))

Если мат на новгородских берестах понятен сейчас тамошним
прапраправнукам - с чего вдруг внуки с жипегом не разберутся?

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

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Fedor Zuev 
On Thu, 24 Mar 2016, Oleksandr Gavenko wrote:

OG>В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
OG>блоками. При текущей плотности записи этого не изсежать. Используются коды с
OG>обнаружением/корекцией ошибок. Со временем диск деградирует и предусмотренна
OG>даже "свободная" область, куда со временем перемещаются данные из ненадежных
OG>областей. Когда область заканчивается контролер диска по SMART скажет что он
OG>сдох.
OG>
OG>Не знаю на сколько это правда. Также не знаю кто происходит во флеше, но
OG>парочку сдохших имею.
OG>
OG>Раз данные постоянно портяться на носиталях важно не только сохранить в 
бекапе
OG>но и контролировать целостность.
OG>
OG>Т.е.
OG>
OG>  $ cp -al /old /new
OG>  $ rsync /data /new
OG>
OG>в случае выхода из строя /data или "rm -r /data/random/dir" позволит
OG>восстановить данные. Но никакой гарантии целосности данных не дает.
OG>
OG>Чем дополнить приведенные выше строчки что бы фоточки дожили до внуков без
OG>битых битов?

apt-cache show par2 

.

Description-en: PAR 2.0 compatible file verification and repair tool 
par2cmdline is a command line utility for creating and using PAR2 
files to detect and repair damage in data files. It is most commonly 
used as part of backup systems as well as on Usenet. . In case files 
in a recovery set get damaged (e.g. while transmitted over a network 
or stored on a faulty disk) the program can read the damaged files 
and the (possibly damaged) PAR2 files, and regenerate the original 
input files.

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Oleksandr Gavenko 
On 2016-03-24, Artem Chuprina wrote:

> За целостностью данных у нас следят простые intrusion detection systems.
> В твоем случае, возможно, сгодится fcheck.
>

  $ cat /etc/fcheck/fcheck.cfg
  Directory   = /etc/
  DataBase= /var/lib/fcheck/fcheck.dbf
  $Signature  = /usr/bin/sha256sum
  Logger  = /usr/bin/logger -tfcheck

  $ cat /var/lib/fcheck/fcheck.dbf
  ...
  
1845266!33188!1!0!0!637!1448875975!/etc/default/apache2!5f5748b1d5ce1adb2304cecf4cf25908f0a8163666d3fb53830e91b7368e306f
  ...

Гавкает наверно по указанному в Logger. Я почти о таком думал. Только вещь
нужна "пасивная". Не гарачие бекапы а скорее как сказано ниже - архивы...

> Но общий принцип прост: чексумма должна храниться, и должна быть такой,
> чтобы при повреждении данных их можно было восстановить.  По
> документации, этим свойством обладает, например, RAID-Z у zfs.  Он не
> только вылет диска переживает, но и битый бит может восстановить.  zfs
> сама по себе проверяет чексуммы (и при чтении тоже), но понятно, что
> узнать "данные побились" и восстановить данные - не одно и то же.
>
> В качестве более простого и надежного решения - база md5sum (если речь
> не идет о намеренном вторжении, то md5 достаточно), и более одной копии
> архива (тут уже речь идет скорее об архиве, а не о бэкапе).  Каковые
> копии никогда не втыкаются в один комп (что подразумевает физически
> разные носители).
>
> И, соответственно, если регулярная проверка одной копии показала
> несовпадение md5, эти данные восстанавливаются из другой копии.

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

Непрерывность доступа не нужна. Раз в пол года втыкаю внешний накопитель. Т.е.
даже демон не нужен.

Ранее был отформатирован в NTFS (использовалось не только как архив, но и как
средство переноса данных). В основном хранил 2 копии и в момент бекапа удалял
старее, записывав новее. Но позавчера перевел в ext4, т.к.:

* на каталогах и файлах были странные метки времени (rsync предлагал менять
  все на все - потому работал с обычным копированием)
* нет хардлинков, я использовал 2 каталога попеременно, потому короткая
  история, а обычно по неосторожности удаляется файл и длинная история
  пригодилась бы
* ntfsfix(8) сказал нужно подключить провериться в Windows ((

В использовании NTFS были плюсы - читается в любой OC и монтируется от
определенного пользователя, после единственной настройки usbmount не
требовались права root.

Меня раздражает хранение прав доступа и бессмысленость uid/gid при переносе
носителя в другую систему...

Когда то писал на DVD-R, но спустя 3 года уже ничего не читалось )) так что
заявления производителей про тесты под высокой температурой для эмуляции
деградации со временем - чушь.



Я уж думаю что можно просто в каждом каталоге самому нагенерить чексумы,
только вместе с именем еще сохранять метку времени и размер файла - эти данные
как раз использует rsync для быстрой проверки. И пересчитывать сумму только
для изменившихся имени файла, метки времени модификации / размера.

Тогда средства резервирования и контроля целосности будут перпендикулярны.

В fcheck мне не по нраву общая база - мультимедийные данные сгрупированы по
каталогам и перестраиватся будут по каталогам. В общем удобней скопировать
подкаталог с контрольными суммами чем отдельным шагом их извлекать из общей
базы.

Мне кажется возможным на Perl/Python накропать свой обход каталогов с
высчитыванием md5sum и сохранением меток времени файлов.



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

В общем полезно не только архивировать, но и перечитывать архивы ))

-- 
http://defun.work/

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность dimas 
а потом внуки спросят "а че за файлы такие - точка джыпэгэ, и чем это все
открыть?")))


2016-084 18:35 Dmitry E. Oboukhov  wrote:
> именно на рейде и хранить.
> просто до внуков множество рейдов сменится.
> 
> а так чтобы "записал и до внуков" такого носителя сейчас нет и никогда
> (в обозримые 100 лет) не будет.
> ибо через 10 лет врядли найдется куда воткнуть то на что сегодня
> запишете данные.
> а через 20 уж тем паче.
> 
> то есть каждые n лет по любому придется данные копировать на более
> новый носитель. это во первых.
> во вторых в течение этих n лет данные тоже как бы нужны бывают (я вот
> смотрю на то видео которое снимал 2 года назад иногда)
> 
> соответственно RAID + домашний сервак с ним (+ бакап тоже на RAID) -
> ваще как бы маст хэв.

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Dmitry E. Oboukhov 
>>> В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
>>> блоками. При текущей плотности записи этого не изсежать. Используются коды с
>>> обнаружением/корекцией ошибок. Со временем диск деградирует и предусмотренна
>>> даже "свободная" область, куда со временем перемещаются данные из ненадежных
>>> областей. Когда область заканчивается контролер диска по SMART скажет что он
>>> сдох.
MAA>> Хранить на рейде не предлагать?

> До внуков?  Ни в коем разе.

именно на рейде и хранить.
просто до внуков множество рейдов сменится.

а так чтобы "записал и до внуков" такого носителя сейчас нет и никогда
(в обозримые 100 лет) не будет.
ибо через 10 лет врядли найдется куда воткнуть то на что сегодня
запишете данные.
а через 20 уж тем паче.

то есть каждые n лет по любому придется данные копировать на более
новый носитель. это во первых.
во вторых в течение этих n лет данные тоже как бы нужны бывают (я вот
смотрю на то видео которое снимал 2 года назад иногда)

соответственно RAID + домашний сервак с ним (+ бакап тоже на RAID) -
ваще как бы маст хэв.
-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Artem Chuprina 
Mikhail A Antonov -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
15:20:26 +0300:

 >> В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
 >> блоками. При текущей плотности записи этого не изсежать. Используются коды с
 >> обнаружением/корекцией ошибок. Со временем диск деградирует и предусмотренна
 >> даже "свободная" область, куда со временем перемещаются данные из ненадежных
 >> областей. Когда область заканчивается контролер диска по SMART скажет что он
 >> сдох.
 MAA> Хранить на рейде не предлагать?

До внуков?  Ни в коем разе.

[DONE] wml://events/2003/{1018-lit-dresden,0509-ifit}-report.wml

2016-03-24 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/events/2003/0509-ifit-report.wml  2011-05-26 16:05:31.0 
+0600
+++ russian/events/2003/0509-ifit-report.wml2016-03-24 18:19:31.889361896 
+0500
@@ -1,71 +1,72 @@
- -#use wml::debian::template title="IFIT 2003 -- Report"
+#use wml::debian::template title="IFIT 2003 -- Отчёт"
 # $Id: 0509-ifit-report.wml,v 1.8 2011/05/26 10:05:31 rhonda Exp $
+#use wml::debian::translation-check translation="1.8" maintainer="Lev Lamberov"
 
- -Panel Discussion
+Пленарное заседание
 
- -This Informationday Free Information Technology (IFIT) is the first
- -such conference that was organised by the department of science and
- -responsibility (WuV) of the University of Innsbruck.  Many people have
- -helped create this conference by working on small bits, just as if it
- -was Free Software.  Even though IFIT was meant as a one day conference
- -a panel discussion took place on Friday evening already.
- -
- -A panel discussion normally is interesting to watch since normally
- -there are experts who discuss issues.  However, this time, there were
- -three politicians (a fourth canceled his attendance).  The discussion
- -started with an introduction into Open Source and was more like a quiz
- -"find the first hundred bugs".  This was really hard to stand.  She
- -mixed up everything she could.
- -
- -It was a good idea, though, to include the audience into the
- -discussion and give them a chance to ask questions to the panel
- -members.  Only the ambassador of one party (The Greens) seemed to
- -understand the issues and gave clear statements pro Open Source and
- -contra software patents.  The others mixed that up and even admired
- -patents.
- -
- -A small buffet provided space for additional discussions between
- -speakers, visitors and officials.  After the university was closed
- -discussions were continued in a hotel nearby almost until dawn.  Even
- -though, this is quite common for conferences covering Free Software,
- -it seemed to be totally uncommon to the conference officials.
+Эта конференция Informationday Free Information Technology 
(IFIT) является
+первой подобной конференцией, 
организуемой департаментом науки
+и ответственности (WuV) Университета 
Инсбрука.  Многие помогали
+в создании этой конференции, будто это было
+свободное ПО.  Даже несмотря на то, что IFIT 
задумывалась как однодневная конференция,
+в пятницу вечером провели пленарное 
заседание.
+
+Обычно пленарное заседание очень 
интересно, поскольку обычно
+там присутствуют различные эксперты.  Тем 
не менее, в этот раз там
+было три политика (четвёртый отменил своё 
участие).  Обсуждение
+началось с введение в идеи ПО с открытым 
исходным кодом, и представляло собой что-то 
вроде
+теста найди первые сто ошибок.  Это 
было трудно выдержать.  Всё, что
+можно было спутать, было спутано.
+
+Хотя, включить аудиторию в обсуждение и 
дать всем шанс задавать вопросы
+участникам пленарного заседания, было 
отличной
+идеей.  Представитель только одной партии 
(Зелёные), как кажется,
+понимал проблемы и ясно высказался в 
пользу ПО с открытым исходным кодом и
+против патентов на ПО.  Другие же всё 
спутали и даже восхищались
+патентами.
+
+В небольшом буфере между выступающими, 
посетителями и официальными лицами
+прошли дополнительные обсуждения.  После 
закрытия университета
+обсуждения были продолжены в близлежащем 
отеле вплоть до рассвета.  Хотя
+это вполне обычно для конференций, 
посвящённых свободному ПО,
+это очень необычно для официальных 
представителей конференции.
 
 Informationday Free Information Technology
 
- -The conference consists of talks and workshops as well as a small
- -information lounge in which the Debian project, the Verein zur
- -Förderung Freier Software (FFS) of Austria and the Linux User Group Tirol 
were

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Коротаев Руслан 
В сообщении от [Чт 2016-03-24 13:11 +0200]
Oleksandr Gavenko  пишет:

> В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
> блоками. При текущей плотности записи этого не изсежать. Используются коды с
> обнаружением/корекцией ошибок. Со временем диск деградирует и предусмотренна
> даже "свободная" область, куда со временем перемещаются данные из ненадежных
> областей. Когда область заканчивается контролер диска по SMART скажет что он
> сдох.
> 
> Не знаю на сколько это правда. Также не знаю кто происходит во флеше, но
> парочку сдохших имею.
> 
> Раз данные постоянно портяться на носиталях важно не только сохранить в бекапе
> но и контролировать целостность.

При создании таких бекапов нужно добавлять определенную избыточность на
случай порчи носителя. Можно воспользоваться утилитой par2 (или pypar2 с
графическим интерфейсом), она может гарантировать целостность в пределах
избыточности которою вы задали. Есть ещё dvdisaster [1], тоже самое,
только заточено под DVD.

[1]: https://ru.wikipedia.org/wiki/Dvdisaster

-- 
Коротаев Руслан
http://blog.kr.pp.ru

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Mikhail A Antonov 
24.03.2016 14:11, Oleksandr Gavenko пишет:
> В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
> блоками. При текущей плотности записи этого не изсежать. Используются коды с
> обнаружением/корекцией ошибок. Со временем диск деградирует и предусмотренна
> даже "свободная" область, куда со временем перемещаются данные из ненадежных
> областей. Когда область заканчивается контролер диска по SMART скажет что он
> сдох.
Хранить на рейде не предлагать?


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Oleksandr Gavenko 
On 2016-03-24, Eugene Berdnikov wrote:

>> Какой софт высчитывает/сохраняет/проверяет контрольные суммы при создании
>> снапшотов?
>
>  Насчёт снапшотов не знаю, а rync имеет ключик -c и ещё несколько
>  связанных с деталями вычисления чексумм.

  -c, --checksum

 This changes the way rsync checks if the files have been changed and are
 in need of a transfer. Without this option, rsync uses a "quick check"
 that (by default) checks if each file’s size and time of last
 modification match between the sender and receiver. This option changes
 this to compare a 128-bit checksum for each file that has a matching
 size. Generating the checksums means that both sides will expend a lot of
 disk I/O reading all the data in the files in the transfer (and this is
 prior to any reading that will be done to transfer changed files), so
 this can slow things down significantly.

Это означает что синхронизация выполняется на основании:

For protocol 30 and beyond (first supported in 3.0.0), the checksum used
is MD5. For older protocols, the checksum used is MD4.

Но после синхронизации информация о контрольных суммах пропадает ((

-- 
http://defun.work/

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Sergey B Kirpichev 
On Thu, Mar 24, 2016 at 02:33:33PM +0300, Eugene Berdnikov wrote:
> On Thu, Mar 24, 2016 at 01:11:05PM +0200, Oleksandr Gavenko wrote:
> > Какой софт высчитывает/сохраняет/проверяет контрольные суммы при создании
> > снапшотов?
> 
>  Насчёт снапшотов не знаю, а rync имеет ключик -c и ещё несколько
>  связанных с деталями вычисления чексумм.

Это бред.  Ключик -c - имеет отношение к копированию данных, а не к
их целостности как таковой.  Т.е. просто обяжет rsync учитывать
содержимое файла при синхронизации, а не разные там метаданные.
Вот он скопирует вам в точности кривые байтики на диске, и чо?

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Artem Chuprina 
Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
13:11:05 +0200:

 OG> В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
 OG> блоками. При текущей плотности записи этого не изсежать. Используются коды 
с
 OG> обнаружением/корекцией ошибок. Со временем диск деградирует и 
предусмотренна
 OG> даже "свободная" область, куда со временем перемещаются данные из 
ненадежных
 OG> областей. Когда область заканчивается контролер диска по SMART скажет что 
он
 OG> сдох.

 OG> Не знаю на сколько это правда. Также не знаю кто происходит во флеше, но
 OG> парочку сдохших имею.

 OG> Раз данные постоянно портяться на носиталях важно не только сохранить в 
бекапе
 OG> но и контролировать целостность.

 OG> Т.е.

 OG>   $ cp -al /old /new
 OG>   $ rsync /data /new

 OG> в случае выхода из строя /data или "rm -r /data/random/dir" позволит
 OG> восстановить данные. Но никакой гарантии целосности данных не дает.

 OG> Чем дополнить приведенные выше строчки что бы фоточки дожили до внуков без
 OG> битых битов?

 OG> Обсчитывать md5sum и периодически проверять? Можно еще подписать ключем 
хеши.

 OG> Для целосности выходит что rsync не совсем годен, если для старых копий 
можно
 OG> держать хардлинки, то для новых файлов желательно просчитать новую 
контрольную
 OG> сумму.

За целостностью данных у нас следят простые intrusion detection systems.
В твоем случае, возможно, сгодится fcheck.

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

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

И, соответственно, если регулярная проверка одной копии показала
несовпадение md5, эти данные восстанавливаются из другой копии.

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Artem Chuprina 
Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
12:45:36 +0200:

 >> Надо сказать, что у меня в ноутбуке SSD довольно быстро вымер
 >> (симптоматика - бьются некоторые файлы на ровном месте), и я его
 >> отключил.
 >>
 OG> Производители заявляют что SSD надежнее HDD:

Я рад за них, но мне еще не попадался винчестер, который начал бы
глючить так быстро.  Хотя по SSD у меня статистики нет, есть один
экземпляр.  Но я на него (экземпляр) обиделся.

У меня было в свое время поползновение поиграться с SSD, но цена
остановила.

 >> Но anyway, тот SSD стоит настолько дороже винчестера, что для целей
 >> бэкап-сервера (небыстрая в норме работа, но места надо много), если уж
 >> покупать, то покупать не SSD, а винты в разы большей емкости.

 OG> Конешно. Я показал пример почему беcсмысленно избегать RAID 5 в свете SSD. 
Не
 OG> будете вы ждать дни пока восстановится RAID и скорость работы не 
деградирует.

 OG> По ценам на бытовые SSD / HDD разняться в 2-4 раза за GiB по ценникам
 OG> ближайшего магазина.

Мой point был в том, что RAID10 или RAID6 на HDD за те же деньги дадут
заметно больший объем, чем RAID5 на SSD.

 OG> Производители заявляют что enterprise хранилище на SSD уже дешевле чем на 
HDD:

 OG> 
http://itblog.sandisk.com/the-accelerating-economics-of-flash-and-the-retreat-of-hard-disk-drives/

Когда у тебя начинают более чем линейно расти расходы на питание и
охлаждение - верю.  Ну, или при оптовых ценах и/или распайке SSD прямо
на плату, без корпуса.  А до тех пор - подождем...

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Eugene Berdnikov 
On Thu, Mar 24, 2016 at 01:11:05PM +0200, Oleksandr Gavenko wrote:
> Какой софт высчитывает/сохраняет/проверяет контрольные суммы при создании
> снапшотов?

 Насчёт снапшотов не знаю, а rync имеет ключик -c и ещё несколько
 связанных с деталями вычисления чексумм.
-- 
 Eugene Berdnikov

Re: Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Sergey B Kirpichev 
On Thu, Mar 24, 2016 at 01:11:05PM +0200, Oleksandr Gavenko wrote:
> Обсчитывать md5sum и периодически проверять?

btrfs/zfs с чексуммами данных.

Как **надежно** сожранить данные?

2016-03-24 Пенетрантность Oleksandr Gavenko 
В районе 2010 писалось что производители выпускают HDD с заведомо "битыми"
блоками. При текущей плотности записи этого не изсежать. Используются коды с
обнаружением/корекцией ошибок. Со временем диск деградирует и предусмотренна
даже "свободная" область, куда со временем перемещаются данные из ненадежных
областей. Когда область заканчивается контролер диска по SMART скажет что он
сдох.

Не знаю на сколько это правда. Также не знаю кто происходит во флеше, но
парочку сдохших имею.

Раз данные постоянно портяться на носиталях важно не только сохранить в бекапе
но и контролировать целостность.

Т.е.

  $ cp -al /old /new
  $ rsync /data /new

в случае выхода из строя /data или "rm -r /data/random/dir" позволит
восстановить данные. Но никакой гарантии целосности данных не дает.

Чем дополнить приведенные выше строчки что бы фоточки дожили до внуков без
битых битов?

Обсчитывать md5sum и периодически проверять? Можно еще подписать ключем хеши.

Для целосности выходит что rsync не совсем годен, если для старых копий можно
держать хардлинки, то для новых файлов желательно просчитать новую контрольную
сумму.

Какой софт высчитывает/сохраняет/проверяет контрольные суммы при создании
снапшотов?

Hg/Git почти подходят под эту роль, хотя с эфективностью хранения,
использованием хардлинков и уничтожением старой истории не все так гладко...

Т.е. проекты хранить в Hg/Git не проблема и у еня они растыканы по куче
носителей. Я даже не замарачиваюсь с резервированием.


А вот колекции медийных файлов - уже не прикольно держать в Hg/Git т.к. они
порядка размера носителей.


-- 
http://defun.work/

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Eugene Berdnikov 
On Thu, Mar 24, 2016 at 12:45:36PM +0200, Oleksandr Gavenko wrote:
> Конешно. Я показал пример почему беcсмысленно избегать RAID 5 в свете SSD. Не
> будете вы ждать дни пока восстановится RAID и скорость работы не деградирует.

 Для бэкапного сервера ни время ребилда, ни скорость работы дисков обычно
 не являются критичными. И завершения бэкапа, если он делается по крону,
 обычно никто не ждёт. За исключением клинических случаев, когда бэкап
 делается с выключением боевого сервиса, но просто не нужно так делать.
-- 
 Eugene Berdnikov

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Oleksandr Gavenko 
On 2016-03-24, Artem Chuprina wrote:

> Надо сказать, что у меня в ноутбуке SSD довольно быстро вымер
> (симптоматика - бьются некоторые файлы на ровном месте), и я его
> отключил.
>
Производители заявляют что SSD надежнее HDD:

http://www.seagate.com/gb/en/do-more/how-to-choose-between-hdd-storage-for-your-laptop-master-dm/

  Reliability

  Failure rates on SSD, HDD and SSHD technologies have very similar ratings.
  SSHD has benefits because it uses both the SSD and HDD portions more
  efficiently than if they were separate.

  Durability

  SSDs are viewed as more durable simply because of their solid state design.
  Without moving parts, they can withstand higher extremes of shock, drop and
  temperature.

Это конечно рекламные заявления, у меня устаревшая цифра в среднем 3 года
живучести.

Хотя об отношении надежность / цена смотрю на хостеров - SSD предложения не
дороже HDD при одинаковых заявлениях о непрерывности работы.


> Но anyway, тот SSD стоит настолько дороже винчестера, что для целей
> бэкап-сервера (небыстрая в норме работа, но места надо много), если уж
> покупать, то покупать не SSD, а винты в разы большей емкости.

Конешно. Я показал пример почему беcсмысленно избегать RAID 5 в свете SSD. Не
будете вы ждать дни пока восстановится RAID и скорость работы не деградирует.

По ценам на бытовые SSD / HDD разняться в 2-4 раза за GiB по ценникам
ближайшего магазина.

Производители заявляют что enterprise хранилище на SSD уже дешевле чем на HDD:

http://itblog.sandisk.com/the-accelerating-economics-of-flash-and-the-retreat-of-hard-disk-drives/


-- 
http://defun.work/

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Artem Chuprina 
Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
12:00:20 +0200:

 >>  АЛ> я за raid10 -- погугли "Why RAID 5 Sucks"
 >> 
 >> Погуглил.  Ничего внятного не увидел.

 >> Здесь подробнее https://geektimes.ru/post/78311/

 OG> От туда:

 >> Когда RAID-5 появился, в 1987 году, типичный жесткий диск был размером 
 >> 21MB, и
 >> имел скорость вращения 3600 RPM. Сегодня типичный диск SATA это 1TB, то есть
 >> прирост емкости составил 50 тысяч раз! Но скорость вращения при этом
 >> увеличилась всего вдвое.

 OG> Лукавит:

 OG> * возросла плотнось записи (можно не разготяться)
 OG> * появились ssd

 OG> Тут: http://www.storagereview.com/ssd_vs_hdd

 OG>  price/GiB  Write

 OG> SSD$0.10200-550 MB/s
 OG> HDD$0.0650–120 MB/s

 OG> В рекламном буклете: http://ocz.com/consumer/ssd-guide/ssd-vs-hdd как раз
 OG> хвастаются 550 MB/s - видно современный предел комерчекого предложения.

 OG> Итого в статье ругаются что восстановление занимает 1 день. SSD сейчас 
таких
 OG> же обьемов и быстрее в 5 раз. Итого 5 часов восстановления.

 OG> **Но главное** проблем с деградацией производительности в момент 
востановления
 OG> не будет - SSD держит 100'000 IO/s против проблемных 300 IO/s в HDD.

 OG> Интересно используют ли эту особенность RAID контроллеры или софтверные 
RAID?

Надо сказать, что у меня в ноутбуке SSD довольно быстро вымер
(симптоматика - бьются некоторые файлы на ровном месте), и я его
отключил.

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

А в моем случае есть то, что есть.

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Oleksandr Gavenko 
On 2016-03-24, Андрей Любимец wrote:
> 23.03.2016 18:51, Artem Chuprina пишет:
>  АЛ> я за raid10 -- погугли "Why RAID 5 Sucks"
> 
> Погуглил.  Ничего внятного не увидел.

> Здесь подробнее https://geektimes.ru/post/78311/

От туда:

> Когда RAID-5 появился, в 1987 году, типичный жесткий диск был размером 21MB, и
> имел скорость вращения 3600 RPM. Сегодня типичный диск SATA это 1TB, то есть
> прирост емкости составил 50 тысяч раз! Но скорость вращения при этом
> увеличилась всего вдвое.

Лукавит:

* возросла плотнось записи (можно не разготяться)
* появились ssd

Тут: http://www.storagereview.com/ssd_vs_hdd

 price/GiB  Write

SSD$0.10200-550 MB/s
HDD$0.0650–120 MB/s

В рекламном буклете: http://ocz.com/consumer/ssd-guide/ssd-vs-hdd как раз
хвастаются 550 MB/s - видно современный предел комерчекого предложения.

Итого в статье ругаются что восстановление занимает 1 день. SSD сейчас таких
же обьемов и быстрее в 5 раз. Итого 5 часов восстановления.

**Но главное** проблем с деградацией производительности в момент востановления
не будет - SSD держит 100'000 IO/s против проблемных 300 IO/s в HDD.

Интересно используют ли эту особенность RAID контроллеры или софтверные RAID?

-- 
http://defun.work/

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Eugene Berdnikov 
On Wed, Mar 23, 2016 at 10:51:26PM +0300, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
> 20:37:44 +0300:
> 
>  >> >  Интересно, для чего может понадобиться снапшот свежего бэкапа?
>  >> 
>  >> Я понял так, что просто делается синхронизация rsync, а потом
>  >> получившееся состояние запоминается с помощью снапшота.
>  >> 
>  >> А вы что подумали?)
> 
>  EB>  Я подумал, что проще и эффективнее "cp -al", а затем на полученной копии
>  EB>  "rsync --delete". Это даёт инкрементальный бэкап (эквивалентный полному)
>  EB>  и не требует поддержки снапшотов.
> 
> Не требует.  Я дома так и делаю.  Но если снапшоты все равно в комплекте?

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

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Artem Chuprina 
Андрей Любимец -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 13:26:26 
+0600:

 >>  >>  >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех 
 >> винтов по
 >>  >>  >>  >> полтерабайта сделает полтора?
 >>  >>  >> 
 >>  >>  >>  SBK> Места-то сколько надо?
 >>  >>  >> 
 >>  >>  >> Бэкап-сервер. Лучше больше.
 >>  >> 
 >>  >>  > Ну тогда все просто.  Больше чем raid5 вы не получите.
 >>  >> 
 >>  >> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью.  В
 >>  >> смысле, в случае вылета винта.
 >>  АЛ> я за raid10 -- погугли "Why RAID 5 Sucks"
 >> 
 >> Погуглил.  Ничего внятного не увидел.
 >> 
 >> Можно пояснить?
 АЛ> Дело в том, что деградировавший RAID5 до завершения ресинка становится по
 АЛ> надёжности аналогичен RAID0. Ресинк же больших дисков может идти достаточно
 АЛ> долго. Если риск потерять данные в этот период не смущает, то ради бога...
 АЛ> Здесь подробнее https://geektimes.ru/post/78311/

А RAID10 в этом смысле чем-то лучше? Или, если уж говорить о 50% потере
пространства, делать RAID6?

Вообще, жалко полтерабайта, оно лишним не будет...  И это все-таки
бэкап, вторая копия данных.  Хотя там предусмотрено хранение прошлого.

[DONE] wml://{security/2016/dsa-3527.wml}

2016-03-24 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3527.wml2016-03-24 13:01:34.0 
+0500
+++ russian/security/2016/dsa-3527.wml  2016-03-24 13:04:43.245155398 +0500
@@ -1,20 +1,21 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -It was discovered that inspircd, an IRC daemon, incorrectly handled
- -PTR lookups of connecting users. This flaw allowed a remote attacker
- -to crash the application by setting up malformed DNS records, thus
- -causing a denial-of-service,
+Было обнаружено, что inspircd, служба IRC, 
некорректно обрабатывает
+поиск PTR подключённых пользователей. Эта 
уязвимость позволяет удалённому 
злоумышленнику
+вызывать аварийную остановку приложения 
путём установки специально сформированных 
записей DNS, что
+приводит к отказу в обслуживании,
 
- -For the oldstable distribution (wheezy), this problem has been fixed
- -in version 2.0.5-1+deb7u2.
+В предыдущем стабильном выпуске (wheezy) эта 
проблема была исправлена
+в версии 2.0.5-1+deb7u2.
 
- -For the stable distribution (jessie), this problem has been fixed in
- -version 2.0.17-1+deb8u1.
+В стабильном выпуске (jessie) эта проблема 
была исправлена в
+версии 2.0.17-1+deb8u1.
 
- -For the testing (stretch) and unstable (sid) distributions, this
- -problem has been fixed in version 2.0.20-1.
+В тестируемом (stretch) и нестабильном (sid) 
выпусках эта
+проблема была исправлена в версии 2.0.20-1.
 
- -We recommend that you upgrade your inspircd packages.
+Рекомендуется обновить пакеты inspircd.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW85+4AAoJEF7nbuICFtKlUU4QAKEKk5FVRjSGKRRKJZpOTtfm
E4JZkwSWCCUNrIw/vfjSF6EJpWReF/LVtZl7LkaC4jlhvyKx7jdAwA/TtSst63lE
ZHvmKJKFIC3uXVXy08JGU7BkADUgbMKUX/dgqloQBufdKK2yYcToX64EggWubzMH
d2S2rbJhinBBWLwnPSAL1Fl4ZeSXfVqUnbNgol4mY8UVLionQUTkI0QXhfe1ji5J
qHpvgUSFe1hbZFRA9nT3uhErcTHl7meZ2W7ORp2NinECBeNQ4KE0cCrBjBNuOq4a
tGTHYfFhC4xoma1XLYd0ZzGQNy+wGxZY+BoGyfznpuir9YRFImmDMWOf306eMKVR
gQeExAXslmQdQN+IBWxCgo6CRq9FiWoyCKBE9wV18eyF7yERN2tAOv8sevIkccpJ
WQWYVIQf4WxpkjITy+XtHe0+gdYEQe1XwxAYMsvGrSnDOMAX07mPLXdZeewvHmkm
OalLAIIdW87j4txcXgiFLzOLpjGB2Ef/GbV8FmMQygOwEDOYYMAU0aRwFI6EhORO
dbkg4toMgt4kd2XGEzUhWBiluKLbwGtP8zD+gkl0JSMRK7afGc2O7i5pO7/iV558
bz1jHScbN46IIFhvnr/2/CWCFMUnqt5jINfRgCoTikvGdoh1vwGFSS6+RoKhNalQ
al9c9bt9VpIYG5o3RkGQ
=x2Wx
-END PGP SIGNATURE-

Re: software raid для бэкап-сервера?

2016-03-24 Пенетрантность Андрей Любимец 
23.03.2016 18:51, Artem Chuprina пишет:
> Андрей Любимец -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
> 17:49:52 +0600:
> 
>  >>  >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех 
> винтов по
>  >>  >>  >> полтерабайта сделает полтора?
>  >>  >> 
>  >>  >>  SBK> Места-то сколько надо?
>  >>  >> 
>  >>  >> Бэкап-сервер. Лучше больше.
>  >> 
>  >>  > Ну тогда все просто.  Больше чем raid5 вы не получите.
>  >> 
>  >> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью.  В
>  >> смысле, в случае вылета винта.
>  АЛ> я за raid10 -- погугли "Why RAID 5 Sucks"
> 
> Погуглил.  Ничего внятного не увидел.
> 
> Можно пояснить?
Дело в том, что деградировавший RAID5 до завершения ресинка становится по
надёжности аналогичен RAID0. Ресинк же больших дисков может идти достаточно
долго. Если риск потерять данные в этот период не смущает, то ради бога...
Здесь подробнее https://geektimes.ru/post/78311/
> 
> Ну, я понимаю, что RAID 5 не переживет вылет любых двух дисков, в то
> время как RAID 10 - только половину вариантов.  За это в случае четырех
> дисков RAID 10 по сравнению с RAID 5 теряет треть пространства. В моем
> случае вылет сразу или почти сразу двух представляется маловероятным, а
> полтерабайта лишними, пожалуй, не будут.
> 
> Еще?
> 
Сам ни разу не  терял данные на RAID5, но пару раз достаточно тривиальные
операции по замене диска (для RAID1 или RAID10) приводили к неприятным
потерям времени и нервов, типа случая описанного здесь --
https://www.opennet.ru/base/sys/raid5_sync.txt.html (автор конечно ССЗБ, но
честно пишет, что ему повезло)

В соседней ветке уже написали про потерю данных из-за выхода второго диска во
время восстановления массива.

Здесь (https://lists.altlinux.org/pipermail/sysadmins/2015-May/037194.html)
пишут :

>>Ну и для RAID5 хорошо известен эффект double fault, когда
>>следующий в очереди на вылетание диск под повышенной нагрузкой
>>при resync не успевает отдать все данные.
> 
> для массивов еще хорошо известен занятный эффект "не тот диск
> вынул при замене". я как-то раз по большой внимательности
> наступил на эти грабли, полчаса вытряхивал потом кирпичи из
> порток :)

Кстати, лайфхак: если нет корзины полезно наклеить на торец винчестера
серийник или WWN, что бы облегчить  идентификацию дисков
 ls -l /dev/disk/by-id/ | grep sda
 ata-ST1000NM0033-9ZM173_Z1W2GVEM -> ../../sda
 wwn-0x5000c500677aa9f2 -> ../../sda