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

*** Oleksandr Gavenko [2017-07-07 18:51]: >Интересно, восстановление в случае упавшего диска в ZFS также затронет только >используемые блоки? Ведь эта оптимизация на уровне FS, где присутствует >необходимая информация. Это должно сэкономить время восстановления в 2-3 и >более

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

On 2017-07-07, Oleksandr Gavenko wrote: > В случае ZFS, Btrfs скрабинг будет выполняться по используемым блокам, что > эффективней чем в случае md сканировать весь массив. И с md нет контрольных > сумм что бы выяснить какой диск обманывает. Интересно, восстановление в случае упавшего диска в ZFS

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

On 2017-06-23, Oleksandr Gavenko wrote: > Тут писали про CD/DVD, флешки, диски. https://en.wikipedia.org/wiki/M-DISC Millenniata testing found that M-Disc DVDs are more durable than conventional DVDs. "The discs were subject to the following test conditions in the environmental chamber:

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

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]: > >>

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

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

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

On 06/07/17 04:43 PM, Sergey Matveev wrote: > *** Tim Sattarov [2017-07-06 23:04]: >> сейчас я вижу требование о равных размерах томов и пересборке vdev. > Не равных, а не меньших. И статья о том чтобы увеличить размер VDEV-а, > сделать expand. Если в VDEV-е два терабайтных

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

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

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 диска

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

*** Tim Sattarov [2017-07-06 21:21]: >> Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в >> опасности, вставьте диск чтобы на него произошёл resilvering и не было >> страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает, >> то в системе, с

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

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

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

On 2017-06-23, Oleksandr Gavenko wrote: > Флешки тоже дохнут. Стандартные заявления - 10 лет заряд стекает с > транзистора. Полезное видео про SSD носители, MLC, TLC и over provisioning: https://www.youtube.com/watch?v=-XZNr7mS0iw Вывод - нужно держать минимум 10% места свободным на

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

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. В случае

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

On Mon, 26 Jun 2017, Oleksandr Gavenko wrote: OG>Или поступать как с лентами - попеременно между лентами гонять данные, что бы OG>освежать намагниченность? badblocks -n ?

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

А может есть смысл воспользоваться чем-то тапа par2? Да это в среднем на 10% увеличит размер архива, но будет возможность не только удостовериться, что данные в архиве повреждены (проверив crc/md5), но и восстановить утраченное в архиве? On Fri, Jun 23, 2017 at 11:11:14PM +0300, Oleksandr

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

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 до

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

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

Sergey Matveev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017 17:23:36 +0300: >>Хотя идея, что для хранения данных _на диске_ >>нужно больше чем по гигу RAM на терабайт диска как бы намекает нам, что >>для хранения кошечек это, пожалуй, overkill. > На гиге ZFS работать будет. Чисто

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

On Mon, 26 Jun 2017 17:50:01 +0300 Sergey B Kirpichev wrote: > > Могу предложить дочитать man md5sum до ключа -c. Он же, сюрприз, эти > > буковки и читает. А человеку выдает только "все в порядке" или > > "кошечка сдохла". > > Замечательно. Т.е. в итоге, после "чтений"

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

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

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: > > >> > Я повторю в чем разница, если вы не поняли до сих пор. В современной > >> > файловой системе - достаточно просто прочитать

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

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

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

Sergey B Kirpichev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017 16:06:27 +0300: >> Но вообще - чтобы оставить себе пространство для маневра, например. Весь >> диск под LVM - это уже ограничение выбора. Захочется, например, >> поэкспериментировать с ZFS или воткнуть второй винт и

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

Sergey B Kirpichev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017 16:01:52 +0300: >> > Я повторю в чем разница, если вы не поняли до сих пор. В современной >> > файловой системе - достаточно просто прочитать файл, чтобы узнать о >> > проблемах в нем. Чем вы это делаете - без

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

Sergey B Kirpichev писал(а) в своём письме Mon, 26 Jun 2017 16:26:32 +0300: On Mon, Jun 26, 2017 at 03:17:06PM +0300, Михаил Касаджиков wrote: Но не нужно высокомерных заявлений о «трёхколёсных велосипедах». Это констатация факта, а не заявление. Заметно. Ну а

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

On Mon, Jun 26, 2017 at 03:17:06PM +0300, Михаил Касаджиков wrote: > Но не нужно высокомерных заявлений о «трёхколёсных велосипедах». Это констатация факта, а не заявление. Ну а чтобы оценить "трехколесность" - можно взглянуть на ваше решение по автоматизации проверки md5?

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

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 - ан > в лучшем случае

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

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

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

Sergey B Kirpichev -> debian-russian@lists.debian.org @ Mon, 26 Jun 2017 12:57:13 +0300: >> Это понятно. Важно, что его не требуется выделять заранее, на этапе >> разбиения на диска разделы, как в случае с LVM. > А зачем с LVM вы вообще заморачиваетесь на тему "разделов"? В 99% > случаев

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

Sergey B Kirpichev -> Михаил Касаджиков @ Mon, 26 Jun 2017 14:58:42 +0300: >> >>Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не >> >>сильно большая разница между чтением с проверкой целостности средствами >> >>самой ФС и «md5sum -c». >> > >> >Действительно, какая

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

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

Sergey Matveev писал(а) в своём письме Mon, 26 Jun 2017 14:43:23 +0300: *** Oleksandr Gavenko [2017-06-26 14:11]: Или поступать как с лентами - попеременно между лентами гонять данные, что бы освежать намагниченность? Мне кажется что этот

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

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: > >>Что так, что эдак, всё равно файл нужно полностью

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

*** Oleksandr Gavenko [2017-06-26 14:11]: >Или поступать как с лентами - попеременно между лентами гонять данные, что бы >освежать намагниченность? Мне кажется что этот вариант хорош. Чисто чтобы поддерживать намагниченность. -- Sergey Matveev (http://www.stargrave.org/)

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

On 2017-06-26, Михаил Касаджиков wrote: > Это уже другая тема. И remap происходит при записи. При невозможности чтения > мы просто получим ошибку чтения, какая-то там ATA_ERROR. Вроде ж коды на диске с избыточностью. При такой плотности записи - ошибки допустимы, будут обранужены и на лету

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

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

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

Oleksandr Gavenko писал(а) в своём письме Sun, 25 Jun 2017 23:22:16 +0300: On 2017-06-25, Михаил Касаджиков wrote: Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не сильно большая разница между чтением с проверкой целостности средствами самой ФС и

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

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

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

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

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

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

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

Oleksandr Gavenko -> debian-russian@lists.debian.org @ Sun, 25 Jun 2017 23:22:16 +0300: >> Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не сильно >> большая разница между чтением с проверкой целостности средствами самой ФС и >> «md5sum -c». > Повторюсь с вопросом, а

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

On 2017-06-25, Михаил Касаджиков wrote: > Что так, что эдак, всё равно файл нужно полностью прочитать. И тут не сильно > большая разница между чтением с проверкой целостности средствами самой ФС и > «md5sum -c». Повторюсь с вопросом, а то фокус сдвинулся. Только прочитать достаточно? Вроде в

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

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

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

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/ а оно простым смертным разве

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

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

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

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

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

Sergey Matveev -> debian-russian@lists.debian.org @ Sat, 24 Jun 2017 22:56:35 +0300: > *** Artem Chuprina [2017-06-24 22:49]: >>Я правильно понимаю, что для создания снапшота ей не нужно отдельного >>незадействованного места на диске, как LVM? > Просто так создать

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

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

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

*** Tim Sattarov [2017-06-25 07:21]: >Параллельный вопрос - умеет ли оно кэшировать на более быстрые >устройства (типа основные данные на HDD, а кэш на SSD) ? >как те же bcache или dm-cache ? Да, умеет. Называется это L2ARC (layer 2 adaptive replacement cache). Абсолютно (ну с

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

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

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

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

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

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

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

*** Oleksandr Gavenko [2017-06-24 22:49]: >Какие физические интерфейсы поддерживают - вынять/вставить? Обычный SATA. Только backplane (в который диск вставляется) должен это поддерживать. Ну и салазки для диска соответствующие. Как во всех серверах. >Что можно себе дома

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

Sergey Matveev -> debian-russian@lists.debian.org @ Sat, 24 Jun 2017 12:22:04 +0300: > * snapshot-ы. Если нужно быстренько что-то проверить/сделать, и при этом > откатить назад файлы, то можно сделать snapshot (за секунду > выполняется) а потом его откатить (снова секунда). Знаю что

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

Oleksandr Gavenko -> debian-russian@lists.debian.org @ Sat, 24 Jun 2017 15:38:16 +0300: >> Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с >> целостностью всё ok и прозрачно продолжил работу. > Какие физические интерфейсы поддерживают - вынять/вставить? > Что

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

On 2017-06-24, Sergey Matveev wrote: > Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с > целостностью всё ok и прозрачно продолжил работу. Какие физические интерфейсы поддерживают - вынять/вставить? Что можно себе дома поставить? Я работал по старинке - ATX размера

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

On 2017-06-24, Sergey Matveev wrote: > пользователь CVS или Subversion скажет что ему бранчи не нужны, но > когда он с ними столкнётся в Git-е, то поймёт насколько это удобно. В современном SVN бранчи удобные если извращенные воркфловы не делать. И даже "продвинутые", т.к. информация о

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

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

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

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

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

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

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

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

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

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 ? Так просто не скажешь. Короче нужно смотреть на задачи, на режимы

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

On 2017-06-24, Sergey B Kirpichev wrote: > ext2 не может защитить даже от порчи метаданных, не говоря уж о данных. Для архивов это ж неважно? Если чек-сума не сошлась, восстанавливаем с предыдущего носителя, а текущий выкидываем. Ну и делает еще одну копию... -- http://defun.work/

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

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

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

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: > > > Собственно, я абсолютно уверен, что надо проверять

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

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

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

*** Tim Sattarov [2017-06-24 00:21]: >не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда >в RAIDz ? Так просто не скажешь. ZFS очень любит память -- с ней ей очень хорошо. То бишь, при нормальном её размере всё должно упираться в диск. Про скорость, опять

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

On 06/23/17 16:22, Sergey Matveev wrote: > > Прошу прощения что снова про ZFS, Продолжай в том же духе, интересно :) > но в его "мире" есть практика такой > перезаписи путём инициирования подобия RAID rebuild-а. Добавляете диск, > говоря что он будет частью зеркала, начинается процесс

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

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

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

On 2017-06-23, Sergey Matveev wrote: > Передёргивать нужно не только на чтение, но, в идеале, ещё и на запись. Это потому что нету гарантий производителя? Современные роботизированые type library просто переодически перезаписывают данные на новую бобину. Производитель обеспокоился, пользователи

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". > > ... и ты получаешь

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

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

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

On 2017-06-23, Tim Sattarov wrote: > Я, честно говоря, скептичен, но описание файловой системы и то как она > борется с такими "тихими" проблемам достаточно, чтобы посмотреть в её > сторону... Мои познания в ZFS ограничены "чексумами". Во первых не ясно как ошибка в чексуме вернется через

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

Eugene Berdnikov -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 18:06:00 +0300: >> тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по >> возможности бэкапы делаются rsync'ом. Инкрементальный - rsync после cp -al. >> >> С другой стороны, если надо сохранить

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

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

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

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

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

Oleksandr Gavenko -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 14:51:58 +0300: >> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если >> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда >> считывалось ровно то, что ты хотел бы считать. md5 -c

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

Tim Sattarov -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 09:29:41 -0400: >> Интересен другой момент. Информацию мы же не гравируем на платиновой >> пластинке. Деградация носителей - обычный процес. >> > Мне надысь ребята из одной софтверной конторы все уши прожужжали, как > они

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

Михаил Касаджиков -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 16:56:05 +0300: >> Еще вопрос - архивы этож не tar на магритную ленту? Индивидуальными файлами, >> правда? > Как раз tar. Используя LVM очень удобно делать snapshot и спокойно паковать > каждый раздел в свой архив. В

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

Oleksandr Gavenko писал(а) в своём письме Fri, 23 Jun 2017 15:58:46 +0300: On 2017-06-23, Михаил Касаджиков wrote: Потому что я говорю о «резервных копиях надолго». А для оперативных копий у меня давно настроен backup-manager с сохранением архивов на домашний NAS и с

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

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

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

On 2017-06-23, Artem Chuprina wrote: > Если я правильно понимаю, btrfs из-за своей сложности - больший риск > потери данных, чем банальный ext2 (для архивного носителя, не путать с > бэкапным, даже возможности ext4 не требуются). Даже журнал не нужен. Только вот вопрос как чистить каталог при

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

On 2017-06-23, Михаил Касаджиков wrote: > Потому что я говорю о «резервных копиях надолго». А для оперативных копий у > меня давно настроен backup-manager с сохранением архивов на домашний NAS и с > периодической чисткой этого дела. Т.е. речь про лазерные диски не идет? Если бы была - по мне

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

Oleksandr Gavenko писал(а) в своём письме Fri, 23 Jun 2017 14:38:26 +0300: On 2017-06-23, Михаил Касаджиков wrote: Даже не в сырости дело. Просто я не вижу смысла использовать такую навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь если это

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

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

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

On 2017-06-23, Artem Chuprina wrote: > Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если > тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда > считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно, Да, я такого не делал, но к этому

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

On 2017-06-23, Михаил Касаджиков wrote: > Даже не в сырости дело. Просто я не вижу смысла использовать такую > навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь > если это архив для долговременного хранения — его не будут многократно > перезаписывать. Скорее всего

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

Sergey B Kirpichev -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 11:20:45 +0300: >> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если >> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда >> считывалось ровно то, что ты хотел бы считать. md5 -c

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,

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

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: > > > Собственно, я абсолютно уверен, что надо проверять

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

Sergey B Kirpichev писал(а) в своём письме Fri, 23 Jun 2017 11:20:45 +0300: On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote: Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если тебя интересует, не чтобы оно в принципе читалось, а

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

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

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

Oleksandr Gavenko -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 10:41:32 +0300: > Вопрос 4. Какой практический период перечитывания стоит выбрать? > Вопрос 5. Выходит что > cp -al /backup/old /backup/new > rsync -r /orig/ /backup/new/ > не достаточно. Возможно потребуеться

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

Тут писали про CD/DVD, флешки, диски. Понятно что устареванием старых ридеров нужно обеспокоиться переносом данных на новые типы носителей (перфокарты => бобины, CD => DVD => BlueRay, IDE => SATA). Интересен другой момент. Информацию мы же не гравируем на платиновой пластинке. Деградация