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

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

On 06/07/17 05:33 PM, Vasiliy P. Melnik wrote:
> Такое впечатление, что у всех отсутствует возможность поставить себе
> виртуальную машину и протестировать.
>
Ты прав, возможность есть, даже время запланировано. Приблизительно на
следующей неделе.
До той поры пытаюсь ответить на вопросы, которые буду задавать себе во
время теста.

На самом деле спасибо вам, ребята, что рассказываете про свой опыт. Это
очень полезно.

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

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

7 июля 2017 г., 0:19 пользователь Tim Sattarov  написал:

> On 06/07/17 04:43 PM, Sergey Matveev wrote:
> > *** Tim Sattarov  [2017-07-06 23:04]:
> >> сейчас я вижу требование о равных размерах томов и пересборке vdev.
> > Не равных, а не меньших. И статья о том чтобы увеличить размер VDEV-а,
> > сделать expand. Если в VDEV-е два терабайтных диска, то один можно
> > заменить на 2TB, но размер VDEV останется всё-равно 1TB. Но если
> > второй диск заменить на 2, то только тогда VDEV станет равным 2TB. В
> > статье и говорится что нужно поочерёдно каждый диск в VDEV заменить на
> > большего размера и только тогда место станет доступно.
> >
> А если там был RAIDZ ? и я в группу из 1ТБ дисков добавляю ещё один 2ТБ
> Будет ли весь объём использован ?
> Или, будет ли у меня возможность добавить две партиции по 1ТБ на этом
> диске ?
> не очень красиво, но по крайней мере функционально :)
>
>

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

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

*** Tim Sattarov  [2017-07-07 00:20]:
>А если там был RAIDZ ? и я в группу из 1ТБ дисков добавляю ещё один 2ТБ
>Будет ли весь объём использован ?

Будет использован 1TB из него. Когда все диски будут заменены на 2TB, то
тогда станет доступно по 2TB со всех сразу.

>Или, будет ли у меня возможность добавить две партиции по 1ТБ на этом
>диске ?

Будет. ZFS пофиг что добавляется: диск ли это (sda) или партиция (sda1)
или там какой-нибудь iSCSI или вообще просто путь до файла, который
будет как-бы жёстким диском.

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

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

On 06/07/17 04:43 PM, Sergey Matveev wrote:
> *** Tim Sattarov  [2017-07-06 23:04]:
>> сейчас я вижу требование о равных размерах томов и пересборке vdev.
> Не равных, а не меньших. И статья о том чтобы увеличить размер VDEV-а,
> сделать expand. Если в VDEV-е два терабайтных диска, то один можно
> заменить на 2TB, но размер VDEV останется всё-равно 1TB. Но если
> второй диск заменить на 2, то только тогда VDEV станет равным 2TB. В
> статье и говорится что нужно поочерёдно каждый диск в VDEV заменить на
> большего размера и только тогда место станет доступно.
>
А если там был RAIDZ ? и я в группу из 1ТБ дисков добавляю ещё один 2ТБ
Будет ли весь объём использован ?
Или, будет ли у меня возможность добавить две партиции по 1ТБ на этом
диске ?
не очень красиво, но по крайней мере функционально :)

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

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

*** Tim Sattarov  [2017-07-06 23:04]:
>это может быть я выдаю желаемое за действительное, но моё понимание
>было, что ZFS работает с JBOD на бэкенде и собирает массивы дисков, так
>же как LVM.

Что-то типа того.

>сейчас я вижу требование о равных размерах томов и пересборке vdev.

Не равных, а не меньших. И статья о том чтобы увеличить размер VDEV-а,
сделать expand. Если в VDEV-е два терабайтных диска, то один можно
заменить на 2TB, но размер VDEV останется всё-равно 1TB. Но если
второй диск заменить на 2, то только тогда VDEV станет равным 2TB. В
статье и говорится что нужно поочерёдно каждый диск в VDEV заменить на
большего размера и только тогда место станет доступно.

>делаю я ноду в AWS, скажем с четырьмя терабайтными дисками и страйпом.
>вопрос номер раз: как делать страйп ? все диски в один VDEV ? или лучше
>каждый диск в свой VDEV и потом его в страйп на уровне zpool ?

Pool это, грубо говоря, RAID0, stripe. Каждый VDEV это stripe элемент.
Поэтому сделать stripe можно только добавив каждый диск как отдельный
VDEV. Из коробки это собственно и делается проще всего:
zpool create mypool da0 da1 da2 da3 -- stripe из четырёх дисков.
Внутри VDEV-а можно сделать только mirror или raidz.

>Хочу ускорить доступ к данным и пользоваться ephemeral SSD, напрямую
>подсоединенному к хосту (супротив остальных дисков, которые HDD и вообще
>говоря сетевые). В силу эфемерности SSD диска, каждая холодная
>перезагрузка (power cycle) его обнуляет.
>Где хранится информация, что /dev/xvdf надо использовать как кэш ?
>на самом диске или вне его ?
>насколько просто и быстро добавить обнулённый диск, нужна ли какая то
>инициализация ?

РАз ускорить и использовать SSD, то это значит добавление cache диска,
L2ARC, в терминах ZFS. Вот насчёт таких кэшей не знаю точно, вряд ли тут
особенность, но в ZFS полностью вся конфигурация хранится на самих
дисках, на всех членах pool-а. Сам не делал, но думаю что после
перезагрузки zpool status скажет что один из дисков, который cache,
недоступен. По идее достаточно будет сделать zpool replace mypool
blablabla-diskid /dev/xvdv -- то есть сказать чтобы он заменил
отсутствующий диск. Раз это кэш, то никакого resilvering не надо и он
сразу должен быть в строю. Отсутствующий диск в зеркале или raidz
заменяется этой же командой, но для них уже делается resilvering,
который равносилен переносу всех полезных данных на новый диск.

>Когда я решу увеличить размер пула, можно ли просто добавить весь набор
>новых дисков ? То есть были 4 по терабайту, добавляю 4 по 2 ТБ и после
>синхронизации удаляю старые 1ТБ.

Да, это делается без проблем. Причём добавить их можно сразу все пачкой,
не дожидаясь resilvering-а на каждый по отдельности последовательно.
Одно но: zpool по-умолчанию имеет (в FreeBSD, по крайней мере)
zpool set autoexpand=off и после добавления дисков, zpool status покажет
в столбце EXPANDSZ размер до которого можно expand-ить pool. Expand,
судя по man, делается zpool online -e командой, но я, если честно, уже
забыл как точно, ибо делал один раз.

>Куда лучше добавлять, в существующий VDEV или создавать новый ? А если
>каждый диск был отдельным VDEV ?

Создать новый VDEV можно только добавив его в pool. А это равносильно
добавлению stripe диска. VDEV из pool-а невозможно "вытащить", так же
как и диск из RAID0! Если вы сделаете zpool add, то ни старый диск, ни
новый уже нельзя будет достать. Я так один раз (по незнанию) вместо
zpool attach сделал zpool add и пришлось zfs send-ом сбрасывать все
данные на третий диск и с нуля создавать массив, zfs recv-ом
восстанавливая данные. Тут только zpool attach-ем можно делать. Если
каждый диск был отдельным VDEV, то значит каждый новый диск добавить по
одному к своему VDEV-у. То есть должно получится 4 VDEV-а, как и прежде,
в каждом из которых по два диска. После resilvering-а, каждый старый
диск можно из каждого VDEV-а zpool detach-ем убрать.

zpool add -- добавление stripe VDEV-а
zpool create mypool da0 da1 -- создание mypool с stripe из двух дисков

zpool attach -- добавление зеркала в текущий vdev
zpool create mypool mirror da0 da1 mirror da2 da3 -- создание mypool с
stripe из двух зеркал (da0+da1 и da2+da3)

zpool create mypool raidz1 da0 da1 da2 raidz2 da3 da4 da5 da6 mirror da7 da8 
da9--
создание mypool с stripe из трёх элементов: raidz1 с тремя дисками
(0/1/2), с raidz2 с четыремя (3/4/5/6) и зеркалом из трёх дисков.

Добавлять VDEV в zpool можно и позже, когда угодно.

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

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

On 06/07/17 03:18 PM, Sergey Matveev wrote:
> *** Tim Sattarov  [2017-07-06 21:21]:
>>> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
>>> опасности, вставьте диск чтобы на него произошёл resilvering и не было
>>> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает,
>>> то в системе, с точки зрения user-space, абсолютно ничего не происходит,
>>> всё прозрачно и никто кроме zpool не знает что что-то не так.
>> А как это соотносится с вот таким взглядом на "удобства" ZFS ?
>>
>> http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html
> А что тут про соотношение? Статья по ссылке расказывает про то, как
> увеличить место в pool-е, как добавлять жёсткие диски к нему. У меня
> написано про замену дисков в pool-е, когда они выходят из строя -- там
> можно добавлять какой угодно диск, лишь бы был не меньшего размера, а
> resilvering на него пройдёт.
я пытаюсь понять все за и против,
это может быть я выдаю желаемое за действительное, но моё понимание
было, что ZFS работает с JBOD на бэкенде и собирает массивы дисков, так
же как LVM.
сейчас я вижу требование о равных размерах томов и пересборке vdev.

Может было бы проще озвучить своё понимание и сценарий который у меня в
голове :)

делаю я ноду в AWS, скажем с четырьмя терабайтными дисками и страйпом.
вопрос номер раз: как делать страйп ? все диски в один VDEV ? или лучше
каждый диск в свой VDEV и потом его в страйп на уровне zpool ?

Вопрос номер два:
Хочу ускорить доступ к данным и пользоваться ephemeral SSD, напрямую
подсоединенному к хосту (супротив остальных дисков, которые HDD и вообще
говоря сетевые). В силу эфемерности SSD диска, каждая холодная
перезагрузка (power cycle) его обнуляет.
Где хранится информация, что /dev/xvdf надо использовать как кэш ?
на самом диске или вне его ?
насколько просто и быстро добавить обнулённый диск, нужна ли какая то
инициализация ?

Ну и вопрос намбер три:
Когда я решу увеличить размер пула, можно ли просто добавить весь набор
новых дисков ? То есть были 4 по терабайту, добавляю 4 по 2 ТБ и после
синхронизации удаляю старые 1ТБ.
Куда лучше добавлять, в существующий VDEV или создавать новый ? А если
каждый диск был отдельным VDEV ?

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

>
> В статье сказано всё верно. В ваших руках компромисс между теряемым
> местом в пределах одного VDEV (сколько дисков вы хотите за "раз"
> объединить в один RAIDZ) и количеством VDEV-ов внутри одного pool. Вы
> можете сделать pool с 1 vdev-ом RAIDZ из 8 дисков, либо pool из 2-х
> vdev-ов, в каждом из которых по четыре диска. В первом случае, как в
> статье сказано, вам нужно будет заменить все 8 дисков, чтобы увеличить
> место, а во втором достаточно только половину, чтобы увеличить один из
> vdev-ов. Позже всегда можно будет заменить диски внутри и второго vdev-а.
>
> vdev это один "уровень" RAID, а объединение vdev-ов в pool это второй,
> striping. Это если в терминах классических RAID-ов. ZFS получается из
> коробки сразу же двухуровневый RAID.
>
Спасибо
Тимур

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

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

*** Tim Sattarov  [2017-07-06 21:21]:
>> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
>> опасности, вставьте диск чтобы на него произошёл resilvering и не было
>> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает,
>> то в системе, с точки зрения user-space, абсолютно ничего не происходит,
>> всё прозрачно и никто кроме zpool не знает что что-то не так.
>А как это соотносится с вот таким взглядом на "удобства" ZFS ?
>
>http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html

А что тут про соотношение? Статья по ссылке расказывает про то, как
увеличить место в pool-е, как добавлять жёсткие диски к нему. У меня
написано про замену дисков в pool-е, когда они выходят из строя -- там
можно добавлять какой угодно диск, лишь бы был не меньшего размера, а
resilvering на него пройдёт.

В статье сказано всё верно. В ваших руках компромисс между теряемым
местом в пределах одного VDEV (сколько дисков вы хотите за "раз"
объединить в один RAIDZ) и количеством VDEV-ов внутри одного pool. Вы
можете сделать pool с 1 vdev-ом RAIDZ из 8 дисков, либо pool из 2-х
vdev-ов, в каждом из которых по четыре диска. В первом случае, как в
статье сказано, вам нужно будет заменить все 8 дисков, чтобы увеличить
место, а во втором достаточно только половину, чтобы увеличить один из
vdev-ов. Позже всегда можно будет заменить диски внутри и второго vdev-а.

vdev это один "уровень" RAID, а объединение vdev-ов в pool это второй,
striping. Это если в терминах классических RAID-ов. ZFS получается из
коробки сразу же двухуровневый RAID.

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

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

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

On 24/06/17 05:28 AM, Sergey Matveev wrote:
>
> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
> опасности, вставьте диск чтобы на него произошёл resilvering и не было
> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает,
> то в системе, с точки зрения user-space, абсолютно ничего не происходит,
> всё прозрачно и никто кроме zpool не знает что что-то не так.
А как это соотносится с вот таким взглядом на "удобства" ZFS ?

http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html

> Now it's very important to understand that you /cannot add hard drives
to a VDEV/.

> This is the key limitation of ZFS as seen from the perspective of home
NAS builders.

> To expand the storage capacity of your pool, you need to add extra
VDEVs. And because each VDEV needs to take care of its own redundancy,
you also need to buy extra drives for parity.

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

On 2017-06-23, Oleksandr Gavenko wrote:

> Флешки тоже дохнут. Стандартные заявления - 10 лет заряд стекает с
> транзистора.

Полезное видео про SSD носители, MLC, TLC и over provisioning:

  https://www.youtube.com/watch?v=-XZNr7mS0iw

Вывод - нужно держать минимум 10% места свободным на носителе. А лучше 20%.

-- 
http://defun.work/

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

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

On 2017-06-29, Fedor Zuev wrote:

>   badblocks -n ?

Интересно, но не развернутой FS:

  -n

  Use non-destructive read-write mode. By default only a non-destructive
  read-only test is done. This option must not be combined with the -w option,
  as they are mutually exclusive.

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

А вот перед началом использования чистого раздела - вполне можно замарочиться.

-- 
http://defun.work/

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

2017-06-29 Пенетрантность Fedor Zuev

On Mon, 26 Jun 2017, Oleksandr Gavenko wrote:

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

badblocks -n ?

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

2017-06-27 Пенетрантность Savitskiy EM

А может есть смысл воспользоваться чем-то тапа par2?

Да это в среднем на 10% увеличит размер архива, но будет возможность не только 
удостовериться,
что данные в архиве повреждены (проверив crc/md5), но и восстановить утраченное 
в архиве?


On Fri, Jun 23, 2017 at 11:11:14PM +0300, Oleksandr Gavenko wrote:
> On 2017-06-23, Sergey Matveev wrote:
> 
> > Передёргивать нужно не только на чтение, но, в идеале, ещё и на запись.
> 
> Это потому что нету гарантий производителя?
> 
> Современные роботизированые type library просто переодически перезаписывают
> данные на новую бобину. Производитель обеспокоился, пользователи не
> замарачиваються.
> 
> У нас же наоборот дешовенькие диски (с кодами контроля ошибок и избыточностью)
> и дорогие твердотельные, которые скорее всего даже без четности, не говоря об
> избыточности...
> 
> Я не представляю как архивы кто либо переписывает на регулярной основе в
> одного массива на другой на предприятии...
> 
> Когда бос спросит админа что он делает - ответ "переливаю из пустого в
> порожнее" не впечатлит ((
> 
> Архивы есть? Что жы ты делаешь?
> 
> Есть конечно понятная практика - попытка восстановления из архива, что бы
> навыки не потерять и быстро реагировать + проблемы посторонние выявить до дня
> X. Но совсем не похоже на "переливание".
> 
> Я работал как то в банке и слышал про очень дорогие шкафы, в которых диски
> просто перевтыкаешь и оно там "само все делает". Помигивает когда хочет
> внимания.
> 
> А как поступают в конторках с меньшим числом денег? Или как получают гарантии
> в облаке?
> 
> Выходит что проще с архивами поступать как с бекапами - переписывать на новый
> носитель с ротациями и проверкой целосности. Или периодически реплицировать по
> сети с проверкой целосности...
> 
> -- 
> http://defun.work/
> 
>

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

2017-06-27 Пенетрантность Михаил Касаджиков

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

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,
хотя не факт), полюбоваться на ее вывод и "разрулить" ситуацию в
"сотни раз режном случае"...

Вообще-то, проверка резервных архивов и заключается, как минимум, в «подключить 
и прочитать».

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

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: Стратегия поддержания резервных копий. Деградация носителей.

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

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

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

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

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 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: Стратегия поддержания резервных копий. Деградация носителей.

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 насчитает.

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

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

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: Стратегия поддержания резервных копий. Деградация носителей.

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

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

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

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

2017-06-25 Пенетрантность Yurkin Evgeny

В письме от воскресенье, 25 июня 2017 г. 16:57:47 +07 пользователь Sergey 
Matveev 
написал:
> *** alexander barakin  [2017-06-25 16:50]:
> >а оно простым смертным разве продаётся? гуглояндекс ничего мне не
> >рассказал по этому поводу.
> 
> Я покупал две такие железки в компании ETegro Technologies много лет
> назад, но такой компании уже не нет. Физическим лицами они продавали
> без проблем. Я к тому, что такие железки существуют.
вот пример подобных железяк, стоят не дорого, их как грязи в продаже
по крайней мере gen8


https://www.hpe.com/ru/ru/product-catalog/servers/proliant-servers/pip.specifications.hpe-proliant-microserver-gen8.5379860.html

https://www.hpe.com/ru/ru/product-catalog/servers/proliant-servers/pip.specifications.hpe-proliant-microserver-gen10.1009955118.html


-- 
С уважением,
Юркин Евгений
Siberian Health Inc

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

2017-06-25 Пенетрантность Artem Chuprina

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 
23:22:16 +0300:

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

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

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

 > Потому как если без перечитывания или даже без перезаписи упускаеться
 > надежность стает вопрос в целесообразности инкрементного копирования. Когда
 > нужно полное для перечитывание / копирование с проверкой целосности.

Инкрементное копирование нужно тогда, когда узкое место — канал передачи
с источника на приемник. Грубо говоря, в наше время при копировании с
винта на винт по USB 3.0 или гигабитной сети cp может оказаться
эффективнее rsync. Оный rsync, правда, тоже читит — если он видит, что
inode не менялся, по умолчанию он содержимое файла не проверяет.

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

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

Уважающий себя архив существует более чем в одной копии.

А разницу между бэкапом и архивом я провожу по сроку хранения. Хотя,
конечно, при инкрементальном бэкапе с историей в несколько лет вопрос
деградации носителя тоже встает. Ибо хотя логически бэкап хранится,
допустим, месяц, но за счет инкрементальности легко может оказаться, что
90% логически свежего бэкапа годами переносились из одного в другой
линковкой, а реально на диск они были записаны тогда, когда этот диск
был впервые вставлен в этот компьютер.

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

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

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

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

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

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

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

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

-- 
http://defun.work/

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

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

*** alexander barakin  [2017-06-25 16:50]:
>а оно простым смертным разве продаётся? гуглояндекс ничего мне не
>рассказал по этому поводу.

Я покупал две такие железки в компании ETegro Technologies много лет
назад, но такой компании уже не нет. Физическим лицами они продавали
без проблем. Я к тому, что такие железки существуют.

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

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

2017-06-25 Пенетрантность alexander barakin

On Sat, Jun 24, 2017 at 10:53:13PM +0300, Sergey Matveev wrote:
> *** Oleksandr Gavenko  [2017-06-24 22:49]:
> >Что можно себе дома поставить?
> 
> Лично у меня две вот таких железки дома:
> http://netberg.ru/products/netberg-demos-p200-m3/

а оно простым смертным разве продаётся? гуглояндекс ничего мне не
рассказал по этому поводу.

-- 
wbr, alexander barakin aka sash-kan.
-- 
i will be very thankful to you if you will use order,
that natural for the human:
first question, then the answer.


signature.asc
Description: Digital signature

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

2017-06-25 Пенетрантность Михаил Касаджиков

Sergey B Kirpichev  писал(а) в своём письме Sat, 24 Jun 
2017 08:41:12 +0300:

On Fri, Jun 23, 2017 at 12:57:38PM +0300, Михаил Касаджиков wrote:

Sergey B Kirpichev  писал(а) в своём письме Fri, 23 Jun 
2017 11:20:45 +0300:

> On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> > тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> > считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
> > если ты не опасаешься подделок данных со стороны серьезных
> > спецслужб. Я думаю, даже CRC32 хватило бы.
>
> А разве не 21-й век на дворе, вроде всякие BTRFS есть уже с
> хешированием данных?

Но это ведь не отменяет того что данные всё равно необходимо прочитать. А кто
именно посчитает контрольную сумму — второй вопрос.

Действительно, какая разница...  Можно ручками md5sum натравливать,
а можно получить контроль целостности автоматический.

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

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

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

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

*** Artem Chuprina  [2017-06-25 16:05]:
>Это понятно. Важно, что его не требуется выделять заранее, на этапе
>разбиения на диска разделы, как в случае с LVM.

Не, не, не, боже упаси эти snapshot сравнивать с LVM-ными :-)! Эти
снапшоты идентичны по сути созданию тэга в Git-е. Вы находитесь на
каком-то коммите (каком-то состоянии текущем ФС) и делаете git tag --
замороженное текущее состояние данных (и snashot ZFS это просто снимок,
замороженное представление).

Ещё есть клоны: тоже самое что и snapshot-ы, но на них можно писать.
Это уже аналог git branch команды.

>При этом, если несколько последовательных снапшотов, и я удаляю
>промежуточный, оно может освободиться, а может перераспределиться на
>предыдущий? Или там промежуточный удалить вообще нельзя?

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

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

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

2017-06-25 Пенетрантность Artem Chuprina

Sergey Matveev -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 22:56:35 
+0300:

 > *** Artem Chuprina  [2017-06-24 22:49]:
 >>Я правильно понимаю, что для создания снапшота ей не нужно отдельного
 >>незадействованного места на диске, как LVM?

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

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

 >>А оно умеет показывать, желательно быстро, сколько места занимает
 >>снапшот? В смысле, сколько места освободится, если я вот этот вот
 >>снапшот удалю?

 > Моментально:

 > # zfs list -t snap
 > NAME   USED  AVAIL  REFER  MOUNTPOINT
 > secure@backup 26.0M  -   117M  -
 > stcvol@backup   55K  -   175M  -
 > stcvol/remote@backup  16.3M  -   412M  -
 > zroot@backup  7.10M  -  5.95G  -
 > zroot/home@backup 45.4M  -  7.03G  -

 > Колонка USED говорит сколько затрачено места именно для хранения дельты.
 > То есть то, что освободится после удаления snapshot.

При этом, если несколько последовательных снапшотов, и я удаляю
промежуточный, оно может освободиться, а может перераспределиться на
предыдущий? Или там промежуточный удалить вообще нельзя?

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

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

>
> Я правильно понимаю, что для создания снапшота ей не нужно отдельного
> незадействованного места на диске, как LVM?
>

да

А оно умеет показывать, желательно быстро, сколько места занимает
> снапшот? В смысле, сколько места освободится, если я вот этот вот
> снапшот удалю?
>

и да и нет - это справедливо только если снапшот один, потому как снапшот
делается к предыдущему снапшоту.

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

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

*** Tim Sattarov  [2017-06-25 07:21]:
>Параллельный вопрос - умеет ли оно кэшировать на более быстрые
>устройства (типа основные данные на HDD, а кэш на SSD) ?
>как те же bcache или dm-cache ?

Да, умеет. Называется это L2ARC (layer 2 adaptive replacement cache).
Абсолютно (ну с точки зрения пользователя) аналогично flashcache в Linux.
У меня один знакомый который это применил -- IOPS-ы зашкалили. В
блогпостах людей тоже видел что помогает отлично. Делается, примерно,
очень просто: zpool add mypool cache sdc (добавить sdc диск как кэш к
mypool). Если добавить несколько, то будут в stripe-е. По сути это
просто вынос части ARC (кэша ZFS) на диск.

Кстати, если памяти для дедупликации не хватает, то именно L2ARC может
вы этом помочь: дедупликационные данные будут хранится на этом носителе.
Хотя, конечно же, и существенно медленнее (RAM vs SSD).

Если в системе есть большая активность на запись с fsync-ом, которая
заставляет сразу же записывать ZIL (участок памяти где агрегируются все
записи) на диск, то существенно можно увеличить производительность
добавив выделенный диск для intent log-а, так называемого. Само собой
это должен быть SSD, если основные диски HDD. Тогда ZIL пишется на этот
SSD и каждые 1-5 секунд checkpoint делается уже с него. Это должно
помогать хорошо или почтовым серверам (Postfix любит fsync) или СУБД.

>сомневаюсь в необходимости, но почему бы и нет...

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

>А инкремент от `0' или от другого инкремента ?

От другого/предыдущего snapshot-а. Тут вопрос в том как вы это будете
восстанавливать. Если сделать так:

# zfs snap mypool@backup-20170101
# zfs send mypool@backup-20170101 > backup-20170101.zfs

# zfs snap mypool@backup-20170102
# zfs snap -i backup-20170101 mypool@backup-20170102  > backup-20170102.zfs

# zfs snap mypool@backup-20170103
# zfs snap -i backup-20170102 mypool@backup-20170103  > backup-20170103.zfs

то, backup-20170103.zfs это инкремент от инкрмента. Но никто не мешает
при его создании указать -i backup-20170101 чтобы получить инкремент от
самого первого (0). Восстанавливать это нужно в соответствующем порядке:

# zfs recv mypool < backup-20170101.zfs
# zfs recv mypool < backup-20170102.zfs
# zfs recv mypool < backup-20170103.zfs

>> Кроме того, масса мелочей из серии:
>>
>> * включить/отключить atime -- zfs set atime=... mypool/fs, включить
>>   отключить sync или перевести в режим бОльшего кэширования -- опять же,
>>   один zfs set. Никаких редактирований fstab и перемонтирований.
>
>ну можно и перемонтировать на лету
>mount -oremount,noatime /
>а редактирование fstab даёт уверенность в однозначности конфигурации и
>что никакой умник втихую не поменяет настройки

Я понимаю что можно перемонтировать, понимаю что сделать dd+losetup. В
ZFS даже подключение разделов делается не из серии mount -t zfs
/dev/sda, а просто zpool import mypool -- он просканирует все блочные
устройства в /dev и по метаинформации на них поймёт кто тут mypool,
какие устройства к нему относятся (чтобы массив воссоздать, кэш
устройства добавить, hotspare, итд). Оно менее UNIX-way-но. Но всё-равно
приятно работать не задумываясь об этих мелочах. Меня они конечно не
напрягали никогда, но всё же.

fstab в ZFS вам не придётся редактировать *совсем* вся конфигурация, все
настройки (atime, sync даже) хранятся в самом ZFS в виде zfs set/get
аттрибутов.

Если вам хочется разрешить какому-то пользователю делать snapshot-ы и их
дампить на своей домашней директории, но больше ничего, то в ZFS есть
система прав:

# zfs allow vpupkin snapshot,send mypool/home/vpupkin

Любые изменения в ФС сделанные через zfs set, allow и тому прочее:
журналируются на диске.

>не хочу звучать параноиком, но что-то как-то многовато для ФС, автор не
>Поттеринг случаем ? (здесь картинка тролля)

Я абсолютно прекрасно вас понимаю! ZFS действительно штука которая
совсем не UNIX-way и... я бы впервые тоже покривил лицом услывал про
такой комбайн. Сам я Поттеринга, мягко говоря, не перевариваю и если
есть что-то к чему он притронулся, то 100% использовать не буду. Но ZFS
всё же вынуждена так много всего заменить (mdadm+LVM+ФС) потому-что это
решает вот 100500 проблем которые могут быть решены только если
низлежащие уровни работающие с дисками будут осведомлены о данных
находящихся на самом верху (ФС). По другому просто никак. Ну и всякие
штуки типа NFS, iSCSI, SMB заключаются просто в том что демону mountd,
например, передаётся не только /etc/exports, но и /etc/zfs/exports файл,
в который при zfs set sharenfs="..." просто добавляется строчка "..." с
нужным путём и

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

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

On 2017-06-24, Sergey Matveev wrote:

> Лично у меня две вот таких железки дома:
> http://netberg.ru/products/netberg-demos-p200-m3/

Посмотрел на современное железо, не понятно что с поддержкой на "серверных
материнках" интерфейсов M.2 NVMe:

https://en.wikipedia.org/wiki/M.2
https://en.wikipedia.org/wiki/NVM_Express

Мне машинка под разработку/компилирование и носители на этом интерфейсе -
самое оно, вот цифирки:

1,775/560 MB/s and 128.5K/128K IOPS

http://ark.intel.com/products/94924/Intel-SSD-600p-Series-512GB-M_2-80mm-PCIe-3_0-x4-3D1-TLC
https://www.amazon.com/dp/B01K375CDY

-- 
http://defun.work/

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

2017-06-24 Пенетрантность Tim Sattarov

On 06/24/17 05:22, Sergey Matveev wrote:
> *** Tim Sattarov  [2017-06-24 01:18]:
>> У меня сейчас одна задача с большим количеством (несколько терабайт)
>> мелких и уже сжатых файлов: это ElasticSearch
>> причём в AWS. где диски можно подобрать разные, но они все "сетевые"
>> (EBS), то есть есть некоторая задержка в доступе.
>> Там же важна скорость чтения.
> Мне кажется что тут стоит попробовать ZFS. С мелкими файлами, как и в
> XFS, проблем нет. Если это, кстати, сжатые .gz/whatever файлы, то на ZFS
> можно включить прозрачное сжатие zlib и тогда на ФС будут хранится
> просто файлы, без архивов, но на самом деле сжатые. Просто удобна
> прозрачность.
сжатие файлов не отключается, это ES... и там свои алгоритмы, я не вникал

Параллельный вопрос - умеет ли оно кэшировать на более быстрые
устройства (типа основные данные на HDD, а кэш на SSD) ?
как те же bcache или dm-cache ? Я понимаю, что по хорошему надо бы
почитать самому, просто пока руки не дошли.

>> А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь,
>> реально интересно.
> Ммм, не хочу чтобы ответ показался грубым, 
отнюдь
> но какой смысл не держать ZFS
> если есть возможность :-)? Как-минимум:
>
> * snapshot-ы. 
ага, про них слышал
> * удобство backup-ов, которое тут обсуждают.
Ок. тоже интересно
> * <сжатие>
сомневаюсь в необходимости, но почему бы и нет...
> * я очень переживаю за целостность данных. ОЧЕНЬ. с ZFS и его zfs scrub,
>   который мне каждый байтик напротив Skein (раньше напротив SHA256)
>   проверит -- убирает психологическое напряжение полностью. 
Вот меня больше всего привлекла именно эта фича.
> У меня в
>   cron стоит раз в 4-часа создание очередного snapshot, генерирование
>   инкрементального бэкапа 
А инкремент от `0' или от другого инкремента ?

> и отсылка его в сжатом и зашифрованном виде
>   (всё красиво через | xz -0 | gpg -r backup -e | nncp-file - делается)
>   в NNCP который раскидывает на две машины. Когда прихожу домой, то
>   прозрачно у меня на домашний сервер сбрасываются все недоброшенные
>   4-часовые слепки всех данных (из них можно *полностью* восстановить
>   всё состояние диска), когда прихожу домой, то прозрачно добрасываются
>   на рабочий компьютер. Если внезапно SSD/whatever упадёт, то у меня
>   мизерной ценой (а не обмазками всюду shell-скриптами) везде полные
>   компактные копии данных. И не надо думать где размещать
>   checksum.sha512 или что-то подобное и как его считать. Вся эта
>   головная боль убрана.
И правда красиво, вопрос теперь как это повторить :)
> * в домашнем сервере используется зеркало ZFS-ное. Это конечно мелочь,
>   но приятно что я могу просто взять и достать диск, протереть от пыли,
>   пропылесосить, вставить, сделать resilvering, который мне покажет что
>   "ok, синхронизировал 6 MiB данных, зеркало снова *полностью* в строю",
>   потом достать второй диск и всё то же самое. С RAID/LVM это
>   невозможно, потому-что они обязаны будут полностью переrebuild-ить все
>   эти 3 TB данных. Плюс у меня третий диск есть, в шкафчике, который я
>   раз в месяц добавляю, он делает resilvering (не трёх терабайт, а
>   только diff-а), убираю снова в шкафчик, зная что там у меня есть
>   offline архивная копия всех данных
Звучит вкусно, спасибо за подробный разбор.
У меня сейчас в домашнем медиацентре три зеркальных тома на LVM, надо
будет как то перевести их на ZFS аккуратно...
> Если коротко, то я бы это мог сравнить со своими ощущения перехода от
> Subversion к Git. Я не понимал чем он лучше, пока не попробовал. Сейчас
> SVN/CVS я использую только в страшном сне. ZFS на HDD на машине с 4 GB
> памяти действительно работает помедленнее, но я бы докупил память -- оно
> стоит того.
>
Вздрогнул от "CVS" :)
Памяти у меня на машинах вроде хватает: домашний медиа центр 16GB,
рабочий лаптоп-workstation вообще с двумя SSD и 32GB.
надо начать её использовать.

> Кроме того, масса мелочей из серии:
>
> * включить/отключить atime -- zfs set atime=... mypool/fs, включить
>   отключить sync или перевести в режим бОльшего кэширования -- опять же,
>   один zfs set. Никаких редактирований fstab и перемонтирований.

ну можно и перемонтировать на лету
mount -oremount,noatime /
а редактирование fstab даёт уверенность в однозначности конфигурации и
что никакой умник втихую не поменяет настройки

> * хочется расшарить директорию/ФС по NFS: zfs set sharenfs= Не надо
>   вспоминать по какому там пути, редактировать exports, передёргивать
>   mountd.
не хочу звучать параноиком, но что-то как-то многовато для ФС, автор не
Поттеринг случаем ? (здесь картинка тролля)
> * надо сделать образ диска для виртуалки из серии dd if=/dev/zero of=hdd
>   bs=1M count=1024 && losetup ... -- делается zfs create -V 1G
>   mypooo/fs/hdd и сразу же будет сделан блочный loopback. Причём со
>   всеми фишками типа возможности snapshot-ов или, в данном случае
>   clone-ов.

А как оно с шифрованием ?
мне если делать такие тома то часто нужны временные шифрованные диски.

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

*** Artem Chuprina  [2017-06-24 22:49]:
>Я правильно понимаю, что для создания снапшота ей не нужно отдельного
>незадействованного места на диске, как LVM?

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

>А оно умеет показывать, желательно быстро, сколько места занимает
>снапшот? В смысле, сколько места освободится, если я вот этот вот
>снапшот удалю?

Моментально:

# zfs list -t snap
NAME   USED  AVAIL  REFER  MOUNTPOINT
secure@backup 26.0M  -   117M  -
stcvol@backup   55K  -   175M  -
stcvol/remote@backup  16.3M  -   412M  -
zroot@backup  7.10M  -  5.95G  -
zroot/home@backup 45.4M  -  7.03G  -

Колонка USED говорит сколько затрачено места именно для хранения дельты.
То есть то, что освободится после удаления snapshot.

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

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

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

*** Oleksandr Gavenko  [2017-06-24 22:49]:
>Какие физические интерфейсы поддерживают - вынять/вставить?

Обычный SATA. Только backplane (в который диск вставляется) должен это
поддерживать. Ну и салазки для диска соответствующие. Как во всех
серверах.

>Что можно себе дома поставить?

Лично у меня две вот таких железки дома: 
http://netberg.ru/products/netberg-demos-p200-m3/

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

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

2017-06-24 Пенетрантность Artem Chuprina

Sergey Matveev -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 12:22:04 
+0300:

 > * snapshot-ы. Если нужно быстренько что-то проверить/сделать, и при этом
 >   откатить назад файлы, то можно сделать snapshot (за секунду
 >   выполняется) а потом его откатить (снова секунда). Знаю что многие
 >   люди говорят что я и без этого жил, но это точно так же как
 >   пользователь CVS или Subversion скажет что ему бранчи не нужны, но
 >   когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.
 >   Или вот например у меня была система где я rsync-ал репозиторий с RPM
 >   пакетами, которые могли ломаться время от времени. Так там каждый день
 >   делался snapshot и я к нему мог обратить по
 >   /path/to/fs/.zfs/2017-04-05/ пути где полная ФС на тот день. Это очень
 >   удобно. С LVM не сравниться, потому-что LVM это блочное устройство
 >   ничего не знающее про ФС на нём, и нужно предпринимать особые действия
 >   чтобы, во-первых, сделать снимок (например xfs_freeze) безопасно,
 >   во-вторых восстановить его, в-третьих, обратиться к предыдущим его
 >   версиям. В ZFS это либо ровно одна команда на всё, либо обращение
 >   просто по особому пути ФС

Я правильно понимаю, что для создания снапшота ей не нужно отдельного
незадействованного места на диске, как LVM?

А оно умеет показывать, желательно быстро, сколько места занимает
снапшот? В смысле, сколько места освободится, если я вот этот вот
снапшот удалю?

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

2017-06-24 Пенетрантность Artem Chuprina

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 
15:38:16 +0300:

 >> Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с
 >> целостностью всё ok и прозрачно продолжил работу.

 > Какие физические интерфейсы поддерживают - вынять/вставить?

 > Что можно себе дома поставить?

 > Я работал по старинке - ATX размера коробка или лаптоп. Туда хотплаг только 
 > по
 > USB ))

 > Сейчас есть e-SATA, я не сильно понимаю на сколько оно полезно для 
 > накопителей
 > и вроде питание не передает интерфейс...

SATA на практике (ну, современная) вполне переживает
вынуть-вставить. Мне казалось, что она изначально была на это
рассчитана, ибо сразу целилась в тот сегмент, где винчестеры суют в
rack-mount.

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

On 2017-06-24, Sergey Matveev wrote:

> Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с
> целостностью всё ok и прозрачно продолжил работу.

Какие физические интерфейсы поддерживают - вынять/вставить?

Что можно себе дома поставить?

Я работал по старинке - ATX размера коробка или лаптоп. Туда хотплаг только по
USB ))

Сейчас есть e-SATA, я не сильно понимаю на сколько оно полезно для накопителей
и вроде питание не передает интерфейс...

-- 
http://defun.work/

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

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

On 2017-06-24, Sergey Matveev wrote:

>   пользователь CVS или Subversion скажет что ему бранчи не нужны, но
>   когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.

В современном SVN бранчи удобные если извращенные воркфловы не делать.

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

-- 
http://defun.work/

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

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

*** Sergey Matveev [2017-06-24 12:22]:
>Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
>если есть возможность :-)? Как-минимум:

Кроме того, масса мелочей из серии:

* включить/отключить atime -- zfs set atime=... mypool/fs, включить
отключить sync или перевести в режим бОльшего кэширования -- опять же,
один zfs set. Никаких редактирований fstab и перемонтирований.
* хочется расшарить директорию/ФС по NFS: zfs set sharenfs= Не надо
вспоминать по какому там пути, редактировать exports, передёргивать
mountd.
* надо сделать образ диска для виртуалки из серии dd if=/dev/zero of=hdd
bs=1M count=1024 && losetup ... -- делается zfs create -V 1G
mypooo/fs/hdd и сразу же будет сделан блочный loopback. Причём со
всеми фишками типа возможности snapshot-ов или, в данном случае
clone-ов.

Всё это можно сделать и так и руками по старинке. Но их довольно много,
а количество переходит в качестве -- в удобство работы.

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

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

>
> Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
> если есть возможность :-)? Как-минимум:
>

Пробовал бтрфс - дико тормозная штука, там где зфс без проблем справляется,
бтрфс просто убивает сторедж.

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

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

*** Артём Н.  [2017-06-24 11:39]:
>Я так понимаю, ZFS может быть установлен на связке дисков (у него всякие там 
>RAIDZ есть, но дальше я не интересовался)?
>И что будет, если один диск из связки вылетит?
>Данные по остальным дискам будут восстановлены (вообще, что произоидёт, и 
>остановится ли система)?

Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
опасности, вставьте диск чтобы на него произошёл resilvering и не было
страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает,
то в системе, с точки зрения user-space, абсолютно ничего не происходит,
всё прозрачно и никто кроме zpool не знает что что-то не так.

Есть очень крутая, по моему, особенность. Я нечаянно, когда был молодым
и неопытным, сделал stripe вместо зеркала, при добавлении диска.
Испугался и диск достал (я ещё не понял что сделал stripe). В случае с
классическим RAID0, это было бы фатально -- никто не знает как
синхронизировать данные назад, никто не знает где данным можно доверять.
Массив и данные потеряны. В ZFS по-умолчанию массив переводится в режим
когда все чтения/записи с него просто блокируются/останавливаются. Я
достал диск -- весь IO встал. Я вставил диск -- он моментально понял что
с целостностью всё ok и прозрачно продолжил работу. В ZFS всё-всё-всё
сделано в виде криптографически связанных деревьев, как в Git, поэтому
он и понимает насколько диск зеркала "отстал" от основного, всё ли в
порядке со stripe-ом, итд.

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

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

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

*** Tim Sattarov  [2017-06-24 01:18]:
>У меня сейчас одна задача с большим количеством (несколько терабайт)
>мелких и уже сжатых файлов: это ElasticSearch
>причём в AWS. где диски можно подобрать разные, но они все "сетевые"
>(EBS), то есть есть некоторая задержка в доступе.
>Там же важна скорость чтения.

Мне кажется что тут стоит попробовать ZFS. С мелкими файлами, как и в
XFS, проблем нет. Если это, кстати, сжатые .gz/whatever файлы, то на ZFS
можно включить прозрачное сжатие zlib и тогда на ФС будут хранится
просто файлы, без архивов, но на самом деле сжатые. Просто удобна
прозрачность.

>А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь,
>реально интересно.

Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
если есть возможность :-)? Как-минимум:

* snapshot-ы. Если нужно быстренько что-то проверить/сделать, и при этом
  откатить назад файлы, то можно сделать snapshot (за секунду
  выполняется) а потом его откатить (снова секунда). Знаю что многие
  люди говорят что я и без этого жил, но это точно так же как
  пользователь CVS или Subversion скажет что ему бранчи не нужны, но
  когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.
  Или вот например у меня была система где я rsync-ал репозиторий с RPM
  пакетами, которые могли ломаться время от времени. Так там каждый день
  делался snapshot и я к нему мог обратить по
  /path/to/fs/.zfs/2017-04-05/ пути где полная ФС на тот день. Это очень
  удобно. С LVM не сравниться, потому-что LVM это блочное устройство
  ничего не знающее про ФС на нём, и нужно предпринимать особые действия
  чтобы, во-первых, сделать снимок (например xfs_freeze) безопасно,
  во-вторых восстановить его, в-третьих, обратиться к предыдущим его
  версиям. В ZFS это либо ровно одна команда на всё, либо обращение
  просто по особому пути ФС
* удобство backup-ов, которое тут обсуждают. Сделали snapshot, а дальше
  zfs send snapshot@name и у вас полная копия всех данных/метаданных со
  всеми настройками ФС в удобном stdout-е, который можно на лету сжать,
  зашифровать и передать куда надо. Восстановление -- одна команда zfs
  recv. Нужны инкрементальные backup-ы? Просто указываете что хотите
  дельту вместо полного дампа. Это приятно всё тем, что даже не надо
  думать а сохраняться ли все права или флаги на файлах при
  использовании tar, а какие опции для этого нужны, итд, итд.
* мне например приходилось работать с большими PostgreSQL и MongoDB
  данными. MongoDB хранит всё в JSONB, который очень хорошо сжимается
  даже LZ4. БД например должна занимать 60 GiB диска, но с LZ4 сжатием
  прозрачным, которое на CPU вообще не заметно, оно сокращалось до 20
  GiB. Плюс так как в ZFS свой собственный кэш ФС используется, то и в
  памяти будут кэшироваться именно эти 20 GiB, а не разжатые части 60-ти.
  А у меня 100 GB SSD, где сэкономленные десятки гигабайт это очень приятно.
* я очень переживаю за целостность данных. ОЧЕНЬ. с ZFS и его zfs scrub,
  который мне каждый байтик напротив Skein (раньше напротив SHA256)
  проверит -- убирает психологическое напряжение полностью. У меня в
  cron стоит раз в 4-часа создание очередного snapshot, генерирование
  инкрементального бэкапа и отсылка его в сжатом и зашифрованном виде
  (всё красиво через | xz -0 | gpg -r backup -e | nncp-file - делается)
  в NNCP который раскидывает на две машины. Когда прихожу домой, то
  прозрачно у меня на домашний сервер сбрасываются все недоброшенные
  4-часовые слепки всех данных (из них можно *полностью* восстановить
  всё состояние диска), когда прихожу домой, то прозрачно добрасываются
  на рабочий компьютер. Если внезапно SSD/whatever упадёт, то у меня
  мизерной ценой (а не обмазками всюду shell-скриптами) везде полные
  компактные копии данных. И не надо думать где размещать
  checksum.sha512 или что-то подобное и как его считать. Вся эта
  головная боль убрана.
* в домашнем сервере используется зеркало ZFS-ное. Это конечно мелочь,
  но приятно что я могу просто взять и достать диск, протереть от пыли,
  пропылесосить, вставить, сделать resilvering, который мне покажет что
  "ok, синхронизировал 6 MiB данных, зеркало снова *полностью* в строю",
  потом достать второй диск и всё то же самое. С RAID/LVM это
  невозможно, потому-что они обязаны будут полностью переrebuild-ить все
  эти 3 TB данных. Плюс у меня третий диск есть, в шкафчике, который я
  раз в месяц добавляю, он делает resilvering (не трёх терабайт, а
  только diff-а), убираю снова в шкафчик, зная что там у меня есть
  offline архивная копия всех данных

Если коротко, то я бы это мог сравнить со своими ощущения перехода от
Subversion к Git. Я не понимал чем он лучше, пока не попробовал. Сейчас
SVN/CVS я использую только в страшном сне. ZFS на HDD на машине с 4 GB
памяти действительно работает помедленнее, но я бы докупил память -- оно
стоит того.

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

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

2017-06-24 Пенетрантность Артём Н .


On 24.06.2017 01:17, Tim Sattarov wrote:

On 06/23/17 17:41, Sergey Matveev wrote:

*** Tim Sattarov  [2017-06-24 00:21]:

не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
в RAIDz ?

Так просто не скажешь.



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

У меня сейчас одна задача с большим количеством (несколько терабайт)
мелких и уже сжатых файлов: это ElasticSearch
причём в AWS. где диски можно подобрать разные, но они все "сетевые"
(EBS), то есть есть некоторая задержка в доступе.
Там же важна скорость чтения.

 На своём ноутбуке с 4 GB памяти
я не замечал разницы в производительности с переходом от XFS к ZFS,

А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь,
реально интересно.

я потенциально думаю заменить мои LVM тома на ZFS в домашнем хранилище,
но ещё не уверен... жду волшебного пенделя :)


Я так понимаю, ZFS может быть установлен на связке дисков (у него всякие там 
RAIDZ есть, но дальше я не интересовался)?
И что будет, если один диск из связки вылетит?
Данные по остальным дискам будут восстановлены (вообще, что произоидёт, и 
остановится ли система)?

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

On 2017-06-24, Sergey B Kirpichev wrote:

> ext2 не может защитить даже от порчи метаданных, не говоря уж о данных.

Для архивов это ж неважно? Если чек-сума не сошлась, восстанавливаем с
предыдущего носителя, а текущий выкидываем. Ну и делает еще одну копию...

-- 
http://defun.work/

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

2017-06-23 Пенетрантность Sergey B Kirpichev

On Fri, Jun 23, 2017 at 02:26:55PM +0300, Artem Chuprina wrote:
> Если я правильно понимаю, btrfs из-за своей сложности - больший риск
> потери данных, чем банальный ext2 (для архивного носителя, не путать с
> бэкапным, даже возможности ext4 не требуются).

Мда, летайте на "Фарманах", друзья...  Фанерка и примитивный движок - что
может быть проще, это точно надежнее авиалайнера.

ext2 не может защитить даже от порчи метаданных, не говоря уж о данных.

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

2017-06-23 Пенетрантность Sergey B Kirpichev

On Fri, Jun 23, 2017 at 12:57:38PM +0300, Михаил Касаджиков wrote:
> Sergey B Kirpichev  писал(а) в своём письме Fri, 23 Jun 
> 2017 11:20:45 +0300:
> 
> > On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > > Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> > > тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> > > считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
> > > если ты не опасаешься подделок данных со стороны серьезных
> > > спецслужб. Я думаю, даже CRC32 хватило бы.
> > 
> > А разве не 21-й век на дворе, вроде всякие BTRFS есть уже с
> > хешированием данных?
> 
> Но это ведь не отменяет того что данные всё равно необходимо прочитать. А кто
> именно посчитает контрольную сумму — второй вопрос.

Действительно, какая разница...  Можно ручками md5sum натравливать,
а можно получить контроль целостности автоматический.

> для резервного накопителя, по моему, через чур.

Это не единственная файловая система с контролем целостности данных.  Да и
многие ее фичи вроде как отключаемы.

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

On 06/23/17 17:41, Sergey Matveev wrote:
> *** Tim Sattarov  [2017-06-24 00:21]:
>> не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
>> в RAIDz ?
> Так просто не скажешь.

> Короче нужно смотреть на
> задачи, на режимы использования, на настройки. ZFS дорогая: на паршивом
> железе ведёт себя паршиво, на хорошем, с памятью, ведёт, как правило,
> лучше остальных.
У меня сейчас одна задача с большим количеством (несколько терабайт)
мелких и уже сжатых файлов: это ElasticSearch
причём в AWS. где диски можно подобрать разные, но они все "сетевые"
(EBS), то есть есть некоторая задержка в доступе.
Там же важна скорость чтения.
>  На своём ноутбуке с 4 GB памяти
> я не замечал разницы в производительности с переходом от XFS к ZFS, 
А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь,
реально интересно.

я потенциально думаю заменить мои LVM тома на ZFS в домашнем хранилище,
но ещё не уверен... жду волшебного пенделя :)

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

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

*** Tim Sattarov  [2017-06-24 00:21]:
>не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
>в RAIDz ?

Так просто не скажешь. ZFS очень любит память -- с ней ей очень хорошо.
То бишь, при нормальном её размере всё должно упираться в диск. Про
скорость, опять же, всё сложно. Например если медленно записывать на
диск данные (то есть, буквально, медленно делать cp файла), то из-за
регулярного создания checkpoint-ов каждые n-секунд, они на диске будут
очень разряжены (дефрагментированы) и даже при полностью
последовательном чтении запросто можно получить скорости в считанные
мегабайты или сотни килобайт. Зато запись на диск (пускай даже рандомная
и параллельными процессами)-- убер быстрая, так как это всегда
последовательная запись, грубо говоря, просто участка памяти as-is.
Очень полезно включать прозрачное сжатие данных lz4: на CPU нагрузка не
заметна, а объёмы данных могут быть на десятки процентов сокращены, что
плюс в производительность. Если zpool сильно забит данными, пустого
места мало, то производительность очень ощутимо проседает (не шутки что
нужно иметь 20% хотя бы пустого пространства). Короче нужно смотреть на
задачи, на режимы использования, на настройки. ZFS дорогая: на паршивом
железе ведёт себя паршиво, на хорошем, с памятью, ведёт, как правило,
лучше остальных.

Лично я и всякие знакомые с ext4 дел давно не имели. На NAS/SAN-ах
использовал(и) до ZFS-а только XFS. На железке с 16 GB RAM и тремя 2-х
терабайтными дисками в raidz1 я не замечал проседания производительности
по-сравнению с XFS на mdadm в RAID5-ом. На своём ноутбуке с 4 GB памяти
я не замечал разницы в производительности с переходом от XFS к ZFS, а
ведь на нём и разворачивал/работал PostgreSQL базы по несколько десятков
гигабайт, но там SSD диск. От знакомых слышал что они использовали ZFS
на железке с 24-мя SAS дисками и 32 GB RAM, без всяких дополнительных
L2ARC кэшей и дисков для ZIL, в многоуровневом raidz2 в stripe-ах -- ZFS
по IOPS был лучше XFS-ов. ext4 и подобные ФС для таких систем не
рассматривали в принципе.

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

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

On 06/23/17 16:22, Sergey Matveev wrote:
>
> Прошу прощения что снова про ZFS, 
Продолжай в том же духе, интересно :)

> но в его "мире" есть практика такой
> перезаписи путём инициирования подобия RAID rebuild-а. Добавляете диск,
> говоря что он будет частью зеркала, начинается процесс resilvering,
> который копирует все данные с одного на другой, но в дефрагментированном
> виде. Когда процесс закончился -- можно вынуть оригинальный. Если речь
> про бэкап, то плюсы в том что простоя системы нет, диск и перечитывается
> и перезаписывается, плюс дефрагментируется (что для ZFS может быть
> ощутимо). Но подход точно такой же: перелить в идеале последовательно
> читая/записывая с одного на другой.
>
Интересно будет попробовать на виртуальных железках, когда блочные
устройства на лету апгрейдишь...
не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
в RAIDz ?

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

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

*** Oleksandr Gavenko  [2017-06-23 23:12]:
>Современные роботизированые type library просто переодически перезаписывают
>данные на новую бобину. Производитель обеспокоился, пользователи не
>замарачиваються.
>
>Выходит что проще с архивами поступать как с бекапами - переписывать на новый
>носитель с ротациями и проверкой целосности. Или периодически реплицировать по
>сети с проверкой целосности...

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

Прошу прощения что снова про ZFS, но в его "мире" есть практика такой
перезаписи путём инициирования подобия RAID rebuild-а. Добавляете диск,
говоря что он будет частью зеркала, начинается процесс resilvering,
который копирует все данные с одного на другой, но в дефрагментированном
виде. Когда процесс закончился -- можно вынуть оригинальный. Если речь
про бэкап, то плюсы в том что простоя системы нет, диск и перечитывается
и перезаписывается, плюс дефрагментируется (что для ZFS может быть
ощутимо). Но подход точно такой же: перелить в идеале последовательно
читая/записывая с одного на другой.

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

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

2017-06-23 Пенетрантность Eugene Berdnikov

On 2017-06-23, Sergey Matveev wrote:

> Передёргивать нужно не только на чтение, но, в идеале, ещё и на запись.

Это потому что нету гарантий производителя?

Современные роботизированые type library просто переодически перезаписывают
данные на новую бобину. Производитель обеспокоился, пользователи не
замарачиваються.

У нас же наоборот дешовенькие диски (с кодами контроля ошибок и избыточностью)
и дорогие твердотельные, которые скорее всего даже без четности, не говоря об
избыточности...

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

Когда бос спросит админа что он делает - ответ "переливаю из пустого в
порожнее" не впечатлит ((

Архивы есть? Что жы ты делаешь?

Есть конечно понятная практика - попытка восстановления из архива, что бы
навыки не потерять и быстро реагировать + проблемы посторонние выявить до дня
X. Но совсем не похоже на "переливание".

Я работал как то в банке и слышал про очень дорогие шкафы, в которых диски
просто перевтыкаешь и оно там "само все делает". Помигивает когда хочет
внимания.

А как поступают в конторках с меньшим числом денег? Или как получают гарантии
в облаке?

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

--
http://defun.work/

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

On Fri, Jun 23, 2017 at 09:47:22PM +0300, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-russian@lists.debian.org  @ Fri, 23 Jun 2017 
> 18:06:00 +0300:
>  >  Владельцы (в виде числовых uid:gid) и права (mask) сохраняются на копии
>  >  по "rsync -a --numeric-ids".
> 
> ... и ты получаешь нежелательные соответствия на бэкап-сервере, который
> не всегда является _только_ бэкап-сервером.

 Если бэкап отдаётся на чтение юзерам, о синхронизации uid/gid и имён
 нужно специально позаботиться. Если нет -- это никого не волнует.

>  >  В общем, при использовании для бэкапа устройств прямого доступа
>  >  не вижу никаких причин заморачиваться с tar-ом.
> 
> Скажем так, если оперативный доступ к файлам бэкапа не требуется, то tar
> всё вышеперечисленное обеспечивает бесплатно.

 Прямой доступ к файлам всегда есть бонус. И на практике у меня лично
 не было случаев (или были настолько редкие, что я их не помню), когда
 этот бонус не играл существенной роли. А вот случаев, когда нужно
 выборочно восстановиться с учётом атрибутов (например, восстановить то,
 что уничтожил утром вирус-шифровальщик, и при этом сохранить файлы,
 изменённые после начала его работы), этих случаев масса. Rsync-ом задача
 решается легко и БЫСТРО, а вот сколько пришлось бы мучиться с tar-ом,
 страшно подумать...

 Собственно, скорость восстановления и является решающим фактором,
 который делает предпочтительным бэкап на диски. А бонусом, который
 добивает все другие варианты, является прямой доступ.

> Когда требуется, я настраиваю конструкцию с rsync. Это (настройка, в
> смысле), как правило, заметно медленнее.

 Настраиваешь один раз, потом просто клонируешь какой-то rsnapshot.conf.

 Зато восстановление из бэкапа идёт на порядки (!) быстрее. Именно время
 восстановления критично, особенно в атмосфере бурных эмоций и ажиотажа,
 которыми сопровождается каждый крэш.
-- 
 Eugene Berdnikov

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

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

*** Oleksandr Gavenko  [2017-06-23 22:11]:
>Мои познания в ZFS ограничены "чексумами".
>
>Во вторых не ясно перечитывает ли в офлайне ZFS чексумы файлов и как она
>сообщит о проблеме?

Контрольные суммы всегда читаются вместе с данными и это будет ошибка
ввода/вывода (типа битый блок) если не сойдётся. Команда zfs scrub
позволяет запустить принудительную проверку абсолютно всех данных и
метаданных. Целостность метаданных "защищена" криптографическими хэшами,
а просто данных это можно выставить (sha256, sha512, skein).
Гарантированно узнать что целостность метаданных или данных нарушена --
на ZFS гарантия.

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

Передёргивать нужно не только на чтение, но, в идеале, ещё и на запись.
Но это в идеале. Кстати инкрементальные backup-ы на ZFS делаются из
коробки: создаёте snapshop, делаете zfs send от него, далее делаете ещё
один snapshot и говорите zfs send чтобы он послал только дельту между
прошлым и текущим snapshot-ами. При этом, опять же, полная гарантия
целостности (обнаружения проблемы).

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

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

On 2017-06-23, Tim Sattarov wrote:

> Я, честно говоря, скептичен, но описание файловой системы и то как она
> борется с такими "тихими" проблемам достаточно, чтобы посмотреть в её
> сторону...

Мои познания в ZFS ограничены "чексумами".

Во первых не ясно как ошибка в чексуме вернется через системный вызов в
приложение. При чтении что я увижу в случае с проблемой?

Во вторых не ясно перечитывает ли в офлайне ZFS чексумы файлов и как она
сообщит о проблеме?

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

-- 
http://defun.work/

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

2017-06-23 Пенетрантность Eugene Berdnikov

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Fri, 23 Jun 2017 
18:06:00 +0300:

 >> тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по
 >> возможности бэкапы делаются rsync'ом. Инкрементальный - rsync после cp -al.
 >> 
 >> С другой стороны, если надо сохранить систему владельцев и прав при
 >> бэкапе на другую машину, то, конечно, tar. А кто-то вроде rdiff,
 >> помнится, делал бэкап пофайлово, а права хранил отдельно, что тоже
 >> вариант. Но получается более сложная система, что сразу ее минус.

 >  Владельцы (в виде числовых uid:gid) и права (mask) сохраняются на копии
 >  по "rsync -a --numeric-ids".

... и ты получаешь нежелательные соответствия на бэкап-сервере, который
не всегда является _только_ бэкап-сервером.

 >  Для ремаппинга пользователей и групп у rsync есть опции --usermap и
 >  --groupmap. Если нужно, можно дополнительно бэкапить маппинги,
 >  в простейшем случае это /etc/passwd и /etc/group.

 >  В общем, при использовании для бэкапа устройств прямого доступа
 >  не вижу никаких причин заморачиваться с tar-ом.

Скажем так, если оперативный доступ к файлам бэкапа не требуется, то tar
всё вышеперечисленное обеспечивает бесплатно.

Когда требуется, я настраиваю конструкцию с rsync. Это (настройка, в
смысле), как правило, заметно медленнее.

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

On Fri, Jun 23, 2017 at 05:13:37PM +0300, Artem Chuprina wrote:
> тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по
> возможности бэкапы делаются rsync'ом. Инкрементальный - rsync после cp -al.
> 
> С другой стороны, если надо сохранить систему владельцев и прав при
> бэкапе на другую машину, то, конечно, tar. А кто-то вроде rdiff,
> помнится, делал бэкап пофайлово, а права хранил отдельно, что тоже
> вариант. Но получается более сложная система, что сразу ее минус.

 Владельцы (в виде числовых uid:gid) и права (mask) сохраняются на копии
 по "rsync -a --numeric-ids". Опция -X ещё и extended file attributes
 копирует, если файловая система на хосте-приёмнике их поддерживает.

 Для ремаппинга пользователей и групп у rsync есть опции --usermap и
 --groupmap. Если нужно, можно дополнительно бэкапить маппинги,
 в простейшем случае это /etc/passwd и /etc/group.

 В общем, при использовании для бэкапа устройств прямого доступа
 не вижу никаких причин заморачиваться с tar-ом.
-- 
 Eugene Berdnikov

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

On 23/06/17 10:20 AM, Artem Chuprina wrote:
> А, ее уже довели до состояния "нормально есть в дистрибутиве"... Хотя
> пока пугает наличие пакета zfs-dkms, т.е. отсутствие поддержки
> мейнстрим-ядром.
>
Те ребята пользуются Ubuntu,  где ZFS "из коробки"
я честно говоря не вижу смысла в установке её везде, где можно.
другой знакомый использует на домашнем NAS, в несколько десятков
терабайт(энтузиаст), в восторге (наверное потому что энтузиаст :) ).

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

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Fri, 23 Jun 2017 
14:51:58 +0300:

 >> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
 >> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
 >> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,

 > Да, я такого не делал, но к этому прихожу. Сам вопрос остался в силе. Бытовые
 > проблемы. Где хранить md5sum - рядом с файлом, в отдельной иерархии, одним
 > файлом.

Я предпочитаю один файл на всю иерархию.

 > Я склоняюсь к мысли в такой иерархии:

 >   /backup/photo/2017-06-23/*
 >   /backup/photo/2017-06-23.md5

 > А то я упирался в 256 символов в имени из ntfs в ext3, добавлять .md5 суфикс
 > в имя - возможные проблемы.

 > + по единственному текстовому файлу можно и грепом погулять и редактором и
 > inode сберегу...

 > Перечитывание иерархии будет простым: md5 -c 2017-06-23.md5

 > А вот дополнительные файлы как детектить однострочником (например при
 > повреждении fs) если есть 2017-06-23.md5?

 > 

 > Можно ли расчет сум оптимизировать по inode?

 > А то с хардлинками и rsync замарачиваешся, а с md5 нет?

 > Есть ли что то готовое под такой кейс?

 > Я бекаплю перед важными событиями в жизни, например когда переежаю и хочется
 > побыстрее на носитель *разницу* скинуть. Может в это время и md5 не так
 > важно...

Ну, строго говоря, следует понимать разницу между бэкапом и
архивом. Вопрос деградации носителя важен для архива, при нем и надо
хранить md5. А на бэкап как раз адекватно рядом посоветовали ключ
проверки у rsync.

 > Еще не ясно где считать md5. Я полагаю на оригинале. Стает резонный вопрос
 > проверить совпадение хешей с предыдущими бекапами по известным файлам...

Но если не rsync, то да, считаем от оригинала, проверяем у копии. Для
начала у свежесделанной.

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

Tim Sattarov -> debian-russian@lists.debian.org  @ Fri, 23 Jun 2017 09:29:41 
-0400:

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

 > :~# apt-cache  show zfs
 > zfs-auto-snapshot  zfs-dbgzfs-dkms  
 > zfs-dracut zfs-fuse   zfs-initramfs 
 > zfsnap zfsutils-linux zfs-zed

 > Я, честно говоря, скептичен, но описание файловой системы и то как она
 > борется с такими "тихими" проблемам достаточно, чтобы посмотреть в её
 > сторону...

А, ее уже довели до состояния "нормально есть в дистрибутиве"... Хотя
пока пугает наличие пакета zfs-dkms, т.е. отсутствие поддержки
мейнстрим-ядром.

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

Михаил Касаджиков -> debian-russian@lists.debian.org  @ Fri, 23 Jun 2017 
16:56:05 +0300:

 >> Еще вопрос - архивы этож не tar на магритную ленту? Индивидуальными файлами,
 >> правда?

 > Как раз tar. Используя LVM очень удобно делать snapshot и спокойно паковать
 > каждый раздел в свой архив. В одной конторе было именно на ленту. Но там
 > использовалась ленточная библиотека и в данном обсуждении оно не интересно
 > потому что там своя архитектура каталога лент. Ещё в одной конторе
 > использовалась пачка HDD. Каждую пятницу человек втыкал в usb-кроватку
 > очередной диск и в понедельник этот диск с архивами прятал в сейф.

Я вот, собственно, недолюбливаю tar за последовательный доступ. Если
тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по
возможности бэкапы делаются rsync'ом. Инкрементальный — rsync после cp -al.

С другой стороны, если надо сохранить систему владельцев и прав при
бэкапе на другую машину, то, конечно, tar. А кто-то вроде rdiff,
помнится, делал бэкап пофайлово, а права хранил отдельно, что тоже
вариант. Но получается более сложная система, что сразу ее минус.

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

Oleksandr Gavenko писал(а) в своём письме Fri, 23 Jun 2017
15:58:46 +0300:

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

Потому что я говорю о «резервных копиях надолго». А для оперативных копий у
меня давно настроен backup-manager с сохранением архивов на домашний NAS и с
периодической чисткой этого дела.

Т.е. речь про лазерные диски не идет? Если бы была - по мне крайне интересно.

Почему же? Как раз куча фильмов у меня дома, как и у многих, хранится на
CD/DVD. Но, честно говоря, меня неоднократно посещала мысль это дело выкинуть —
вряд ли я буду всю эту коллекцию пересматривать.
В телекомах, на станциях типа S12 вполне себе используется магнитооптика для
хранения конфигурации.

А то важные архивы с пяток под 100 GiB каждый. Даже с BlueRay придется
дробить. Как это делать не представляю.

А чем split+md5 не устраивает?

Еще вопрос - архивы этож не tar на магритную ленту? Индивидуальными файлами,
правда?

Как раз tar. Используя LVM очень удобно делать snapshot и спокойно паковать
каждый раздел в свой архив. В одной конторе было именно на ленту. Но там
использовалась ленточная библиотека и в данном обсуждении оно не интересно
потому что там своя архитектура каталога лент. Ещё в одной конторе
использовалась пачка HDD. Каждую пятницу человек втыкал в usb-кроватку
очередной диск и в понедельник этот диск с архивами прятал в сейф.

А вообще, всё это обсуждение в отрыве от конкретной задачи особого смысла не
имеет.

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

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

On 23/06/17 03:41 AM, Oleksandr Gavenko wrote:
> Интересен другой момент. Информацию мы же не гравируем на платиновой
> пластинке. Деградация носителей - обычный процес.
>
Мне надысь ребята из одной софтверной конторы все уши прожужжали, как
они везде используют ZFS,  даже на коротко живущих серверах.
потому что надо и деградация носителей...

:~# apt-cache  show zfs
zfs-auto-snapshot  zfs-dbgzfs-dkms  
zfs-dracut zfs-fuse   zfs-initramfs 
zfsnap zfsutils-linux zfs-zed

Я, честно говоря, скептичен, но описание файловой системы и то как она
борется с такими "тихими" проблемам достаточно, чтобы посмотреть в её
сторону...

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

On 2017-06-23, Artem Chuprina wrote:

> Если я правильно понимаю, btrfs из-за своей сложности - больший риск
> потери данных, чем банальный ext2 (для архивного носителя, не путать с
> бэкапным, даже возможности ext4 не требуются).

Даже журнал не нужен.

Только вот вопрос как чистить каталог при сбое питания. Удалить иерархию -
достточно и есть ли fsck ключик не восстанавливать, а просто почистьт. А то
каких то левых файлов насоздаеться, еще ищи их и чисть...

-- 
http://defun.work/

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

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

> Потому что я говорю о «резервных копиях надолго». А для оперативных копий у
> меня давно настроен backup-manager с сохранением архивов на домашний NAS и с
> периодической чисткой этого дела.

Т.е. речь про лазерные диски не идет? Если бы была - по мне крайне интересно.
А то важные архивы с пяток под 100 GiB каждый. Даже с BlueRay придется
дробить. Как это делать не представляю.

Еще вопрос - архивы этож не tar на магритную ленту? Индивидуальными файлами,
правда?

-- 
http://defun.work/

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

2017-06-23 Пенетрантность Eugene Berdnikov


Oleksandr Gavenko  писал(а) в своём письме Fri, 23 Jun 2017 
14:38:26 +0300:


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


Даже не в сырости дело. Просто я не вижу смысла использовать такую
навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь
если это архив для долговременного хранения — его не будут многократно
перезаписывать. Скорее всего этот архив вообще будет записан один раз за всю
историю.


Почему Вы пишите об однократной записи?


Потому что я говорю о «резервных копиях надолго». А для оперативных копий у 
меня давно настроен backup-manager с сохранением архивов на домашний NAS и с 
периодической чисткой этого дела.


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

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

On Fri, Jun 23, 2017 at 02:51:58PM +0300, Oleksandr Gavenko wrote:
> А то с хардлинками и rsync замарачиваешся, а с md5 нет?
...
> Еще не ясно где считать md5. Я полагаю на оригинале. Стает резонный вопрос
> проверить совпадение хешей с предыдущими бекапами по известным файлам...

 Почитайте описание опции -c, --checksum для rsync.
 При -nc получается проверка хэшей без копирования.
-- 
 Eugene Berdnikov

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

On 2017-06-23, Artem Chuprina wrote:

> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,

Да, я такого не делал, но к этому прихожу. Сам вопрос остался в силе. Бытовые
проблемы. Где хранить md5sum - рядом с файлом, в отдельной иерархии, одним
файлом.

Я склоняюсь к мысли в такой иерархии:

/backup/photo/2017-06-23/*
/backup/photo/2017-06-23.md5

А то я упирался в 256 символов в имени из ntfs в ext3, добавлять .md5 суфикс
в имя - возможные проблемы.

+ по единственному текстовому файлу можно и грепом погулять и редактором и
inode сберегу...

Перечитывание иерархии будет простым: md5 -c 2017-06-23.md5

А вот дополнительные файлы как детектить однострочником (например при
повреждении fs) если есть 2017-06-23.md5?

Можно ли расчет сум оптимизировать по inode?

А то с хардлинками и rsync замарачиваешся, а с md5 нет?

Есть ли что то готовое под такой кейс?

Я бекаплю перед важными событиями в жизни, например когда переежаю и хочется
побыстрее на носитель *разницу* скинуть. Может в это время и md5 не так
важно...

Еще не ясно где считать md5. Я полагаю на оригинале. Стает резонный вопрос
проверить совпадение хешей с предыдущими бекапами по известным файлам...

--
http://defun.work/

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

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

> Даже не в сырости дело. Просто я не вижу смысла использовать такую
> навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь
> если это архив для долговременного хранения — его не будут многократно
> перезаписывать. Скорее всего этот архив вообще будет записан один раз за всю
> историю.

Почему Вы пишите об однократной записи?

С минитюризаций персоналок CD/DVD/BlueRay ридеры/врайтеры перестали вставлять.
Не говоря про планшетики. Эти носители уже живой анахронизм. Порой драйвера
предлагают скачать на сайте в квик-гвайд, что бы сэкономить на диске.

Разве что на западе лицензионное медиа фанаты покупают, как грампластинки ))

Цена на внешний накопитель не малая для местного бюджета, но все же ротировать
раз в три года устройства для бекапа можно...

-- 
http://defun.work/

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

Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Fri, 23 Jun 2017 
11:20:45 +0300:

 >> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
 >> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
 >> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
 >> если ты не опасаешься подделок данных со стороны серьезных
 >> спецслужб. Я думаю, даже CRC32 хватило бы.

 > А разве не 21-й век на дворе, вроде всякие BTRFS есть уже с
 > хешированием данных?

Если я правильно понимаю, btrfs из-за своей сложности - больший риск
потери данных, чем банальный ext2 (для архивного носителя, не путать с
бэкапным, даже возможности ext4 не требуются).

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

Igor Savlook  писал(а) в своём письме Fri, 23 Jun 2017 12:59:09 
+0300:

On Fri, 2017-06-23 at 12:57 +0300, Михаил Касаджиков wrote:

Sergey B Kirpichev  писал(а) в своём письме
Fri, 23 Jun 2017 11:20:45 +0300:

> On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > Собственно, я абсолютно уверен, что надо проверять криптосуммы.
> > Ну, если
> > тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> > считывалось ровно то, что ты хотел бы считать. md5 -c вполне
> > достаточно,
> > если ты не опасаешься подделок данных со стороны серьезных
> > спецслужб. Я думаю, даже CRC32 хватило бы.
>
> А разве не 21-й век на дворе, вроде всякие BTRFS есть уже с
> хешированием данных?

Но это ведь не отменяет того что данные всё равно необходимо
прочитать. А кто именно посчитает контрольную сумму — второй вопрос.
Да и применение BTRFS для резервного накопителя, по моему, через чур.

Учитывая что еще и сама btrfs очень сырая.

Даже не в сырости дело. Просто я не вижу смысла использовать такую навороченную 
ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь если это 
архив для долговременного хранения — его не будут многократно перезаписывать. 
Скорее всего этот архив вообще будет записан один раз за всю историю.

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

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

2017-06-23 Пенетрантность Igor Savlook

On Fri, 2017-06-23 at 12:57 +0300, Михаил Касаджиков wrote:
> Sergey B Kirpichev  писал(а) в своём письме
> Fri, 23 Jun 2017 11:20:45 +0300:
> 
> > On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> > > Собственно, я абсолютно уверен, что надо проверять криптосуммы.
> > > Ну, если
> > > тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> > > считывалось ровно то, что ты хотел бы считать. md5 -c вполне
> > > достаточно,
> > > если ты не опасаешься подделок данных со стороны серьезных
> > > спецслужб. Я думаю, даже CRC32 хватило бы.
> > 
> > А разве не 21-й век на дворе, вроде всякие BTRFS есть уже с
> > хешированием данных?
> 
> Но это ведь не отменяет того что данные всё равно необходимо
> прочитать. А кто именно посчитает контрольную сумму — второй вопрос.
> Да и применение BTRFS для резервного накопителя, по моему, через чур.
> 
Учитывая что еще и сама btrfs очень сырая.
> -- 
> Написано с помощью почтового клиента Opera: http://www.opera.com/mail
> /

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

2017-06-23 Пенетрантность Sergey B Kirpichev


Sergey B Kirpichev  писал(а) в своём письме Fri, 23 Jun 
2017 11:20:45 +0300:


On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:

Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
если ты не опасаешься подделок данных со стороны серьезных
спецслужб. Я думаю, даже CRC32 хватило бы.


А разве не 21-й век на дворе, вроде всякие BTRFS есть уже с
хешированием данных?


Но это ведь не отменяет того что данные всё равно необходимо прочитать. А кто 
именно посчитает контрольную сумму — второй вопрос. Да и применение BTRFS для 
резервного накопителя, по моему, через чур.

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

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

On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
> если ты не опасаешься подделок данных со стороны серьезных
> спецслужб. Я думаю, даже CRC32 хватило бы.

А разве не 21-й век на дворе, вроде всякие BTRFS есть уже с
хешированием данных?

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