date:20170626

On 06/26/17 16:18, Tim Sattarov wrote:
>
> Допилил: *https://github.com/stumyp/shoot/blob/master/shoot-s3***
что то пошло не так с линком :)
https://github.com/stumyp/shoot/blob/master/shoot-s3

Re: Сохранение скриншотов на гугл-драйв

2017-06-26 Пенетрантность Vasiliy P. Melnik

On 06/26/17 11:05, Tim Sattarov wrote:
> On 06/26/17 10:55, Grigory Fateyev wrote:
>> Добрый день!
>>
>> Там всё просто, адаптировал скрипт под новый API imgur:
>> https://github.com/greggy/shoot/blob/master/shoot
>>
>> попробуйте доработать под свои требования.
>>
> О, спасибо. буду пилить :)

Допилил: *https://github.com/stumyp/shoot/blob/master/shoot-s3***

Re: ZFS

>
> Внезапного выключения питания не бывает, если не сдохли аккумуляторы в ИБП.
>

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

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Mon, Jun 26, 2017 at 06:07:21PM +0300, Victor Wagner wrote:
> On Mon, 26 Jun 2017 17:50:01 +0300
> Sergey B Kirpichev  wrote:
> 
> > > Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти
> > > буковки и читает. А человеку выдает только "все в порядке" или
> > > "кошечка сдохла".  
> > 
> > Замечательно.  Т.е. в итоге, после "чтений" md5sum - вы таки признаете
> > необходимость пользователю открыть файл? ;)  Таки операций тогда
> > выйдет более одной...
> 
> Нет, зачем? Это же архив. При регулярных периодических проверках нет
> необходимости что-либо открывать. Мы либо убеждаемся что все в порядке,
> либо ищем на каком другом архивном носителе у нас есть копия этой
> кошечки и восстанавливаем оттуда (что происходит в сотни раз реже, чем
>  "убеждаемся, что все в порядке").

Сурово все это как-то.  Это мне носитель(и) подключить, пнуть
"проверялку" (ну, это еще как-то можно автоматизировать по plug-in,
хотя не факт), полюбоваться на ее вывод и "разрулить" ситуацию в
"сотни раз режном случае"...

На месте ТС я бы лучше позаботился об избыточности (хоть даже
с md-raid5, если на всякие btrfs - аллергия) и пусть data-scrubbing
"проверяет" носители, заодно автоматически восстанавливая "кошечек".

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

Это _может_ считаться другой задачей.

Re: Стратегия поддержания резервных копий. Деградация носителей.

2017-06-26 Пенетрантность Debian Webmaster

Sergey Matveev -> debian-russian@lists.debian.org  @ Mon, 26 Jun 2017 17:23:36 
+0300:

 >>Хотя идея, что для хранения данных _на диске_
 >>нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что
 >>для хранения кошечек это, пожалуй, overkill.

 > На гиге ZFS работать будет. Чисто для хранения/чтения подойдёт. У нас
 > тут упоминалось по пять гигов на терабайт -- это если дедупликация нужна.

Ну, тут кто-то на прямой вопрос сказал, что для сервера с
4-терабайтником лучше 8 гигабайт RAM...

Validation failed

*** Errors validating
/srv/www.debian.org/www/international/l10n/po/en_CA.ru.html: ***
Line 183, character 374:  "128513" is not a character number in the
document character set
*** Errors validating
/srv/www.debian.org/www/international/l10n/po/en_GB.ru.html: ***
Line 118, character 351:  "128513" is not a character number in the
document character set
Line 311, character 337:  "128513" is not a character number in the
document character set
Line 1319, character 241:  "128513" is not a character number in the
document character set

--
 You received this mail for the language code ru.
 Please edit webwml/english/devel/website/validation.data if this is not 
accurate
 Please also update webwml/english/devel/website/ with the new coordinator(s) 
data

Re: Стратегия поддержания резервных копий. Деградация носителей.

2017-06-26 Пенетрантность Victor Wagner

On Mon, 26 Jun 2017 17:50:01 +0300
Sergey B Kirpichev  wrote:

> > Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти
> > буковки и читает. А человеку выдает только "все в порядке" или
> > "кошечка сдохла".  
> 
> Замечательно.  Т.е. в итоге, после "чтений" md5sum - вы таки признаете
> необходимость пользователю открыть файл? ;)  Таки операций тогда
> выйдет более одной...

Нет, зачем? Это же архив. При регулярных периодических проверках нет
необходимости что-либо открывать. Мы либо убеждаемся что все в порядке,
либо ищем на каком другом архивном носителе у нас есть копия этой
кошечки и восстанавливаем оттуда (что происходит в сотни раз реже, чем
 "убеждаемся, что все в порядке").

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

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Mon, Jun 26, 2017 at 05:28:11PM +0300, Artem Chuprina wrote:
> Что у меня странное? Попробовать ZFS на логическом томе, наверное,
> можно, но судя по тому, что говорят в соседних тредах, выглядеть это
> будет неадекватно.

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

> рейд поверх LVM, скорее всего, тоже означает
> просаживание производительности.

Вряд-ли серьезно.

Тем более, что непонятно как вам поможет тут существование разделов
на диске.  Если вы не можете/хотите весь диск добавить в рейд (видимо,
новый диск - меньше) - что изменилось бы, создай вы раньше на первом
диске разделы?

> А если весь диск отведен под LVM, и на нем система, то ужать LVM и на
> освободившемся месте сделать что-то другое... Можно убрать лишние LV и
> ужать PV, а дальше что? Раздел уже не ужать, ибо LVM не на разделе, а на
> всем диске...

Ну, если с вариантом "ужать LVM" - то, пожалуй, имеет смысл таки
разбивать диск, но с одной большой партицией.

Re: Сохранение скриншотов на гугл-драйв

On 06/26/17 10:55, Grigory Fateyev wrote:
> Добрый день!
>
> Там всё просто, адаптировал скрипт под новый API imgur:
> https://github.com/greggy/shoot/blob/master/shoot
>
> попробуйте доработать под свои требования.
>
О, спасибо. буду пилить :)

Re: Сохранение скриншотов на гугл-драйв

2017-06-26 Пенетрантность Grigory Fateyev

Добрый день!

Там всё просто, адаптировал скрипт под новый API imgur:
https://github.com/greggy/shoot/blob/master/shoot

попробуйте доработать под свои требования.

26 июня 2017 г., 17:46 пользователь Tim Sattarov  написал:

> On 06/26/17 09:01, Bogdan wrote:
> > Привет!
> >
> > Хочется инструмент для сохранения скриншотов на гугул-драйв. Т.е.
> > выделенная область загружается в гугл, каталогизируется и шарится
> > согласно неким дефолтным настройкам, а в буфер копируется ссылка на файл.
> > Если кто-то видел такое - как называется?
> Плюсую вопрос, только хочу копировать на AWS S3.
> Смотрел на shutter, у него вроде как есть плагины и можно свои на перле
> дописать, но как то руки не дошли разобраться.
>
>

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Mon, Jun 26, 2017 at 05:19:58PM +0300, Artem Chuprina wrote:
> Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Mon, 26 Jun 2017 
> 16:01:52 +0300:
> 
>  >>  > Я повторю в чем разница, если вы не поняли до сих пор.  В современной
>  >>  > файловой системе - достаточно просто прочитать файл, чтобы узнать о
>  >>  > проблемах в нем.  Чем вы это делаете - без разницы, хоть cat,
>  >>  > хоть LibreOffice.  Вы же предлагаете куда более навороченый способ
>  >>  > действий: перед чтением файла - проверить еще его целостность с md5sum.
>  >> 
>  >> Почему перед? Это одна операция. Файл читает md5sum, и больше никто.
> 
>  > Я вас удивлю, но большинство людей совершенно не интересует то,
>  > что там начитал md5sum.  Картинка любимой кошечки нужна, понимаете,
>  > а не непонятные буковки, которые там md5sum насчитает.
> 
> Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти
> буковки и читает. А человеку выдает только "все в порядке" или "кошечка
> сдохла".

Замечательно.  Т.е. в итоге, после "чтений" md5sum - вы таки признаете
необходимость пользователю открыть файл? ;)  Таки операций тогда
выйдет более одной...

> Другие задачи она решает лучше, что да, то да. В том числе те, которые
> md5sum не решает вообще. Хотя идея, что для хранения данных _на диске_
> нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что
> для хранения кошечек это, пожалуй, overkill.

Ну так может у BTRFS не все так печально?

AFAIK, reiserfs4 начал поддерживать чексумминг данных, до
некоторой степени.

Re: Сохранение скриншотов на гугл-драйв

On 06/26/17 09:01, Bogdan wrote:
> Привет!
>
> Хочется инструмент для сохранения скриншотов на гугул-драйв. Т.е.
> выделенная область загружается в гугл, каталогизируется и шарится
> согласно неким дефолтным настройкам, а в буфер копируется ссылка на файл.
> Если кто-то видел такое - как называется?
Плюсую вопрос, только хочу копировать на AWS S3.
Смотрел на shutter, у него вроде как есть плагины и можно свои на перле
дописать, но как то руки не дошли разобраться.

Re: Стратегия поддержания резервных копий. Деградация носителей.

2017-06-26 Пенетрантность Sergey Matveev

*** Artem Chuprina  [2017-06-26 17:21]:
>Хотя идея, что для хранения данных _на диске_
>нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что
>для хранения кошечек это, пожалуй, overkill.

На гиге ZFS работать будет. Чисто для хранения/чтения подойдёт. У нас
тут упоминалось по пять гигов на терабайт -- это если дедупликация нужна.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Стратегия поддержания резервных копий. Деградация носителей.

Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Mon, 26 Jun 2017 
16:06:27 +0300:

 >> Но вообще - чтобы оставить себе пространство для маневра, например. Весь
 >> диск под LVM - это уже ограничение выбора. Захочется, например,
 >> поэкспериментировать с ZFS или воткнуть второй винт и сделать RAID1 - ан
 >> в лучшем случае просядет производительность

 > Вообще-то - экспериментировать лучше на экспериментальном диске :)  А
 > еще лучше - на экспериментальной системе.

 > Но попробовть ZFS на логическом томе, а тем более добавить
 > диск для raid1 - LVM вам точно мешать не должен, тут у вас что-то
 > странное.

Что у меня странное? Попробовать ZFS на логическом томе, наверное,
можно, но судя по тому, что говорят в соседних тредах, выглядеть это
будет неадекватно. рейд поверх LVM, скорее всего, тоже означает
просаживание производительности. Я же, обратите внимание, сказал
"добавить диск и сделать рейд", а не "добавить диск в рейд". Это значит,
что до того диск был один, и рейда не было.

Поверх LVM можно строить файловую систему (в классическом понимании). А
рейд или ZFS - вряд ли хорошая идея.

А если весь диск отведен под LVM, и на нем система, то ужать LVM и на
освободившемся месте сделать что-то другое... Можно убрать лишние LV и
ужать PV, а дальше что? Раздел уже не ужать, ибо LVM не на разделе, а на
всем диске...

Re: Стратегия поддержания резервных копий. Деградация носителей.

Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Mon, 26 Jun 2017 
16:01:52 +0300:

 >>  > Я повторю в чем разница, если вы не поняли до сих пор.  В современной
 >>  > файловой системе - достаточно просто прочитать файл, чтобы узнать о
 >>  > проблемах в нем.  Чем вы это делаете - без разницы, хоть cat,
 >>  > хоть LibreOffice.  Вы же предлагаете куда более навороченый способ
 >>  > действий: перед чтением файла - проверить еще его целостность с md5sum.
 >> 
 >> Почему перед? Это одна операция. Файл читает md5sum, и больше никто.

 > Я вас удивлю, но большинство людей совершенно не интересует то,
 > что там начитал md5sum.  Картинка любимой кошечки нужна, понимаете,
 > а не непонятные буковки, которые там md5sum насчитает.

Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти
буковки и читает. А человеку выдает только "все в порядке" или "кошечка
сдохла".

 >>  > Уже просто законы Мерфи за то, что на систематическую проверку
 >>  > целостности забъют болт.
 >> 
 >> Для этого настраивают робота.

 > Для этого - делают удобные инструменты, которые собственно выше
 > и были рекомендованы, а не изобретают свой трехколесный велосипед.

Я вот тут как раз гляжу в сторону ZFS и задаю вопросы по сути. Так
вот. Для проверки целостности ZFS - из пушки по воробьям. Сетапить нужно
намного дольше, квалификация нужна намного выше, и комп намного мощнее.

Другие задачи она решает лучше, что да, то да. В том числе те, которые
md5sum не решает вообще. Хотя идея, что для хранения данных _на диске_
нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что
для хранения кошечек это, пожалуй, overkill.

Re: Стратегия поддержания резервных копий. Деградация носителей.


Sergey B Kirpichev  писал(а) в своём письме Mon, 26 Jun 
2017 16:26:32 +0300:


On Mon, Jun 26, 2017 at 03:17:06PM +0300, Михаил Касаджиков wrote:

Но не нужно высокомерных заявлений о «трёхколёсных велосипедах».


Это констатация факта, а не заявление.


Заметно.


Ну а чтобы оценить "трехколесность" - можно взглянуть на
ваше решение по автоматизации проверки md5?


Нельзя. Но оно по сути ничем не отличается от «ищем все файлы и читаем их» с 
отправкой результатов на почту.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Mon, Jun 26, 2017 at 03:17:06PM +0300, Михаил Касаджиков wrote:
> Но не нужно высокомерных заявлений о «трёхколёсных велосипедах».

Это констатация факта, а не заявление.

Ну а чтобы оценить "трехколесность" - можно взглянуть на
ваше решение по автоматизации проверки md5?

Re: Стратегия поддержания резервных копий. Деградация носителей.

2017-06-26 Пенетрантность Иван Лох

On Mon, Jun 26, 2017 at 04:01:52PM +0300, Sergey B Kirpichev wrote:
> Я вас удивлю, но большинство людей совершенно не интересует то,
> что там начитал md5sum.  Картинка любимой кошечки нужна, понимаете,
 а не непонятные буковки, которые там md5sum насчитает.

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

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Mon, Jun 26, 2017 at 03:41:36PM +0300, Artem Chuprina wrote:
> Но вообще - чтобы оставить себе пространство для маневра, например. Весь
> диск под LVM - это уже ограничение выбора. Захочется, например,
> поэкспериментировать с ZFS или воткнуть второй винт и сделать RAID1 - ан
> в лучшем случае просядет производительность

Вообще-то - экспериментировать лучше на экспериментальном диске :)  А
еще лучше - на экспериментальной системе.

Но попробовть ZFS на логическом томе, а тем более добавить
диск для raid1 - LVM вам точно мешать не должен, тут у вас что-то
странное.

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Mon, Jun 26, 2017 at 03:32:34PM +0300, Artem Chuprina wrote:
>  > Я повторю в чем разница, если вы не поняли до сих пор.  В современной
>  > файловой системе - достаточно просто прочитать файл, чтобы узнать о
>  > проблемах в нем.  Чем вы это делаете - без разницы, хоть cat,
>  > хоть LibreOffice.  Вы же предлагаете куда более навороченый способ
>  > действий: перед чтением файла - проверить еще его целостность с md5sum.
> 
> Почему перед? Это одна операция. Файл читает md5sum, и больше никто.

Я вас удивлю, но большинство людей совершенно не интересует то,
что там начитал md5sum.  Картинка любимой кошечки нужна, понимаете,
а не непонятные буковки, которые там md5sum насчитает.

>  > Уже просто законы Мерфи за то, что на систематическую проверку
>  > целостности забъют болт.
> 
> Для этого настраивают робота.

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

Сохранение скриншотов на гугл-драйв

2017-06-26 Пенетрантность Bogdan

Привет!

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

Спасибо.

-- 
WBR,  Bogdan B. Rudas

Re: Стратегия поддержания резервных копий. Деградация носителей.

Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Mon, 26 Jun 2017 
12:57:13 +0300:

 >> Это понятно. Важно, что его не требуется выделять заранее, на этапе
 >> разбиения на диска разделы, как в случае с LVM.

 > А зачем с LVM вы вообще заморачиваетесь на тему "разделов"?  В 99%
 > случаев (разве что если диск загрузочный и grub древний) - вообще
 > разбивать ничего не надо.

Ок, пусть будет "на этапе разметки диска". Задействовать диск целиком -
это тоже разметка.

Но вообще - чтобы оставить себе пространство для маневра, например. Весь
диск под LVM - это уже ограничение выбора. Захочется, например,
поэкспериментировать с ZFS или воткнуть второй винт и сделать RAID1 - ан
в лучшем случае просядет производительность, а в худшем вообще не
получится. Поэтому я практикую схему "раздел под систему, раздел под
своп, остальное под остальное".

Re: Стратегия поддержания резервных копий. Деградация носителей.

Sergey B Kirpichev -> Михаил Касаджиков  @ Mon, 26 Jun 2017 14:58:42 +0300:

 >> >>Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
 >> >>сильно большая разница между чтением с проверкой целостности средствами
 >> >>самой ФС и «md5sum -c».
 >> >
 >> >Действительно, какая разница - возвращает тебе система ошибку чтения
 >> >или просто отдает с диска мусор вместо данных.
 >> 
 >> Что за глупость??? «Достаточно чтения» — это про btrfs и ZFS, с проверкой
 >> целостности на лету, а не про вообще любые ФС.
 >> Отмотайте нить обсуждения, мы там именно про это говорили.

 > Так вроде там как раз и обсуждалось использование конкретно btrfs,
 > заместо трехколесных поделок с md5sum.

 > Я повторю в чем разница, если вы не поняли до сих пор.  В современной
 > файловой системе - достаточно просто прочитать файл, чтобы узнать о
 > проблемах в нем.  Чем вы это делаете - без разницы, хоть cat,
 > хоть LibreOffice.  Вы же предлагаете куда более навороченый способ
 > действий: перед чтением файла - проверить еще его целостность с md5sum.

Почему перед? Это одна операция. Файл читает md5sum, и больше никто.

 > Уже просто законы Мерфи за то, что на систематическую проверку
 > целостности забъют болт.

Для этого настраивают робота.

Re: Стратегия поддержания резервных копий. Деградация носителей.

Sergey B Kirpichev  писал(а) в своём письме Mon, 26 Jun 
2017 14:58:42 +0300:

On Mon, Jun 26, 2017 at 01:33:46PM +0300, Михаил Касаджиков wrote:

Sergey B Kirpichev  писал(а) в своём письме Mon, 26 Jun 
2017 13:13:47 +0300:
>On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:
>>Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
>>сильно большая разница между чтением с проверкой целостности средствами
>>самой ФС и «md5sum -c».
>
>Действительно, какая разница - возвращает тебе система ошибку чтения
>или просто отдает с диска мусор вместо данных.

Что за глупость??? «Достаточно чтения» — это про btrfs и ZFS, с проверкой
целостности на лету, а не про вообще любые ФС.
Отмотайте нить обсуждения, мы там именно про это говорили.

Так вроде там как раз и обсуждалось использование конкретно btrfs,
заместо трехколесных поделок с md5sum.

Я повторю в чем разница, если вы не поняли до сих пор.  В современной
файловой системе - достаточно просто прочитать файл, чтобы узнать о
проблемах в нем.  Чем вы это делаете - без разницы, хоть cat,
хоть LibreOffice.  Вы же предлагаете куда более навороченый способ
действий: перед чтением файла - проверить еще его целостность с md5sum.

Если вы до сих пор не поняли, не все современные ФС умеют проверять целостность 
данных на лету. спорить же о том какая ФС считается кем-то там современной, а 
какая нет — не имею ни малейшего желания. Мне и ext2 не натирает использовать 
там где её использование вполне уместно, и NTFS на переносных накопителях.

Моя мысль предельно проста: на btrfs/ZFS достаточно просто прочитать файл, на 
ext4 — нужно самостоятельно проверить md5/sha1/etc. Всё. Если лично вам не 
нравится использование «внешних» инструментов для проверки контрольных сумм — 
на здоровье, используйте ФС со встроенной проверкой. Но не нужно высокомерных 
заявлений о «трёхколёсных велосипедах». Это глупо и превращает беседу в срач.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Стратегия поддержания резервных копий. Деградация носителей.


Sergey Matveev  писал(а) в своём письме Mon, 26 Jun 
2017 14:43:23 +0300:


*** Oleksandr Gavenko  [2017-06-26 14:11]:

Или поступать как с лентами - попеременно между лентами гонять данные, что бы
освежать намагниченность?


Мне кажется что этот вариант хорош. Чисто чтобы поддерживать намагниченность.


Полностью согласен. В качестве бюджетного решения — вполне себе.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Стратегия поддержания резервных копий. Деградация носителей.

2017-06-26 Пенетрантность Oleksandr Gavenko

On Mon, Jun 26, 2017 at 01:33:46PM +0300, Михаил Касаджиков wrote:
> Sergey B Kirpichev  писал(а) в своём письме Mon, 26 Jun 
> 2017 13:13:47 +0300:
> >On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:
> >>Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
> >>сильно большая разница между чтением с проверкой целостности средствами
> >>самой ФС и «md5sum -c».
> >
> >Действительно, какая разница - возвращает тебе система ошибку чтения
> >или просто отдает с диска мусор вместо данных.
> 
> Что за глупость??? «Достаточно чтения» — это про btrfs и ZFS, с проверкой
> целостности на лету, а не про вообще любые ФС.
> Отмотайте нить обсуждения, мы там именно про это говорили.

Так вроде там как раз и обсуждалось использование конкретно btrfs,
заместо трехколесных поделок с md5sum.

Я повторю в чем разница, если вы не поняли до сих пор.  В современной
файловой системе - достаточно просто прочитать файл, чтобы узнать о
проблемах в нем.  Чем вы это делаете - без разницы, хоть cat,
хоть LibreOffice.  Вы же предлагаете куда более навороченый способ
действий: перед чтением файла - проверить еще его целостность с md5sum.

Уже просто законы Мерфи за то, что на систематическую проверку
целостности забъют болт.

Re: Стратегия поддержания резервных копий. Деградация носителей.

2017-06-26 Пенетрантность Sergey Matveev

*** Oleksandr Gavenko  [2017-06-26 14:11]:
>Или поступать как с лентами - попеременно между лентами гонять данные, что бы
>освежать намагниченность?

Мне кажется что этот вариант хорош. Чисто чтобы поддерживать намагниченность.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Стратегия поддержания резервных копий. Деградация носителей.

On 2017-06-26, Михаил Касаджиков wrote:

> Это уже другая тема. И remap происходит при записи. При невозможности чтения
> мы просто получим ошибку чтения, какая-то там ATA_ERROR.

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

Я к тому имеет смысл переписывать с одного носителя на другой (магнитные
диски) или подержал 3 года носитель, перенес на другой и про первый забыл?

Или поступать как с лентами - попеременно между лентами гонять данные, что бы
освежать намагниченность?

-- 
http://defun.work/

Re: Стратегия поддержания резервных копий. Деградация носителей.


Sergey B Kirpichev  писал(а) в своём письме Mon, 26 Jun 
2017 13:13:47 +0300:


On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:

Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
сильно большая разница между чтением с проверкой целостности средствами
самой ФС и «md5sum -c».


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


Что за глупость??? «Достаточно чтения» — это про btrfs и ZFS, с проверкой 
целостности на лету, а не про вообще любые ФС. Отмотайте нить обсуждения, мы 
там именно про это говорили.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Стратегия поддержания резервных копий. Деградация носителей.

Oleksandr Gavenko писал(а) в своём письме Sun, 25 Jun 2017
23:22:16 +0300:

On 2017-06-25, Михаил Касаджиков wrote:

Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не сильно
большая разница между чтением с проверкой целостности средствами самой ФС и
«md5sum -c».

Повторюсь с вопросом, а то фокус сдвинулся. Только прочитать достаточно?

Проверка «md5sum -c file.md5» прочитает весь файл и проверит его контрольную
сумму.
Для проверки средствами самой ФС мы просто читаем файл «cat file >/dev/null».
В обоих случаях мы полностью читаем данные с диска и одновременно считаем (и
проверяем) контрольную сумму.

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

Это уже другая тема. И remap происходит при записи. При невозможности чтения мы
просто получим ошибку чтения, какая-то там ATA_ERROR.

Немножко размыто понятие между бекапом и архивом. Есть поговорка "Backups are
for recovery; archives are for discovery".

Фоточки смотрятся раз в 5 лет, а потерять до смерти жалко. Пополняються не
часто и дублируються изредка на внешние носители инкриментно. Не похоже на
бекап, т.к. не регулярно переношу. Не похоже на архив, т.к. оригинал не
удаляю.

Ну, для домашнего компа и ноута я не храню архив разделов долго. Месяца два,
исключительно как защита от умирания SSD и последствий своих каких-нить
косяков. Архив системы 5-и летней давности мне и даром не нужен. Всё хранится
на домашнем NAS с RAID5.

На работе то же самое. ОС на серверах меняется/обновляется не часто, да и
выкатывается всё шефом. А вот хранить несколько лет нужно CDR, некоторые логи и
периодические копии «горячей БД». И вот это дело пакуется ежедневно (только
новые файлы) и складируется на отдельный сервер с большим разделом. Оттуда
хозяева площадки архивы ежедневно забирают и хранят где-то у себя. Получаем
два, а может и больше, экземпляра.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Sun, Jun 25, 2017 at 04:37:40PM +0300, Михаил Касаджиков wrote:
> Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не
> сильно большая разница между чтением с проверкой целостности средствами
> самой ФС и «md5sum -c».

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

Re: ZFS


Artem Chuprina  писал(а) в своём письме Sun, 25 Jun 2017 
15:56:32 +0300:


artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 13:59:32 +0300:

 >> Я бы поспуил следующим образом
 >> 1) выделить на каждом диске раздел в начала 80 гигов
 >> 2) создать второй раздел
 >> 3) создать рейд1 и в него включить этих три раздела.
 > Зачем?
 > Ради защиты от падения ОС?
 > А выделить под ОС, например SSD?

Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
нормальном винте такой же раздел с копией. После того, как у меня пару
раз на ровном месте побились существеные для работы системы файлы, я SSD
из употребления вывел. И затаил...


Я года три назад прочитал статью про «петабайтный тест» и купил Corsair Neutron 
GTX на 240 гиг, ровно такой же как и в статье, на замену HDD в ноуте. Даже не 
смотря на SATA2 работа с диском стала заметно шустрее. Защиту от падения SSD 
возложил на ежедневное резервное копирование всех разделов на домашний NAS, 
1-го числа полный архив и ежедневная разница. Работает и не жужжит, помирать 
пока не собирается.

smartctl:
Device Model: Corsair Neutron GTX SSD
Serial Number:1420791600010079006A
Firmware Version: M312
User Capacity:240 057 409 536 bytes [240 GB]
…
SMART Attributes Data Structure revision number: 0
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED  
WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000e   166   156   006Old_age   Always   
-   0
  5 Reallocated_Sector_Ct   0x0032   098   098   036Old_age   Always   
-   291
  9 Power_On_Hours  0x0032   076   076   000Old_age   Always   
-   21273
 12 Power_Cycle_Count   0x0032   100   100   000Old_age   Always   
-   728
171 Unknown_Attribute   0x0032   253   253   000Old_age   Always   
-   0
172 Unknown_Attribute   0x0032   100   100   000Old_age   Always   
-   300
181 Program_Fail_Cnt_Total  0x0032   253   253   000Old_age   Always   
-   0
182 Erase_Fail_Count_Total  0x0032   100   100   000Old_age   Always   
-   300
194 Temperature_Celsius 0x0002   035   000   000Old_age   Always   
-   35 (Min/Max 16/57)
201 Unknown_SSD_Attribute   0x000e   039   001   000Old_age   Always   
-   1126
204 Soft_ECC_Correction 0x000e   100   100   000Old_age   Always   
-   0
231 Temperature_Celsius 0x0033   092   092   010Pre-fail  Always   
-   9
234 Unknown_Attribute   0x0032   100   100   000Old_age   Always   
-   123974
241 Total_LBAs_Written  0x0032   100   100   000Old_age   Always   
-   4315
242 Total_LBAs_Read 0x0032   100   100   000Old_age   Always   
-   17351
250 Read_Error_Retry_Rate   0x0032   100   100   000Old_age   Always   
-   341633

231-й а атрибут — состояние в %, сейчас 92%.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Стратегия поддержания резервных копий. Деградация носителей.

On Sun, Jun 25, 2017 at 04:03:54PM +0300, Artem Chuprina wrote:
> Это понятно. Важно, что его не требуется выделять заранее, на этапе
> разбиения на диска разделы, как в случае с LVM.

А зачем с LVM вы вообще заморачиваетесь на тему "разделов"?  В 99%
случаев (разве что если диск загрузочный и grub древний) - вообще
разбивать ничего не надо.

Re: ZFS

On Sun, Jun 25, 2017 at 12:30:07PM +0300, Sergey Matveev wrote:
> Btrfs не умеет аналогов RAID5/RAID6 (в ZFS RAIDZ1/2/3)

Умеет, но говорят что больно бажное.

Re: ZFS