Тут писали про CD/DVD, флешки, диски.
Понятно что устареванием старых ридеров нужно обеспокоиться переносом данных
на новые типы носителей (перфокарты => бобины, CD => DVD => BlueRay, IDE =>
SATA).
Интересен другой момент. Информацию мы же не гравируем на платиновой
пластинке. Деградация носителе
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/
> не достаточно. Возможно потребуеться
On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
> если ты не опас
On Thu, 22 Jun 2017 23:13:25 +0300
artiom wrote:
> >
> Дык зачем использовать stable, когда testing уже вполне стабилен?
Как уже? Еще. Этому тестингу от роду 4 дня. А то что было тестингом
неделю назад сейчас stable.
Sergey B Kirpichev писал(а) в своём письме Fri, 23 Jun
2017 11:20:45 +0300:
On Fri, Jun 23, 2017 at 11:16:09AM +0300, Artem Chuprina wrote:
Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
считывалось ро
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:
> > > Собственно, я абсолютно уверен, что надо проверять криптосуммы.
> > > Ну, если
>
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:
> > Собственно, я а
Sergey B Kirpichev -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
11:20:45 +0300:
>> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
>> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
>> считывалось ровно то, что ты хотел бы считать. md5 -c вп
On 2017-06-23, Михаил Касаджиков wrote:
> Даже не в сырости дело. Просто я не вижу смысла использовать такую
> навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь
> если это архив для долговременного хранения — его не будут многократно
> перезаписывать. Скорее всего этот
On 2017-06-23, Artem Chuprina wrote:
> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
> считывалось ровно то, что ты хотел бы считать. md5 -c вполне достаточно,
Да, я такого не делал, но к этому прихожу.
On Fri, Jun 23, 2017 at 02:51:58PM +0300, Oleksandr Gavenko wrote:
> А то с хардлинками и rsync замарачиваешся, а с md5 нет?
...
> Еще не ясно где считать md5. Я полагаю на оригинале. Стает резонный вопрос
> проверить совпадение хешей с предыдущими бекапами по известным файлам...
Почитайте описан
Oleksandr Gavenko писал(а) в своём письме Fri, 23 Jun 2017
14:38:26 +0300:
On 2017-06-23, Михаил Касаджиков wrote:
Даже не в сырости дело. Просто я не вижу смысла использовать такую
навороченную ФС (с кучей метаданных) для однократной записи (DVD, лента). Ведь
если это архив для долговременн
On 2017-06-23, Михаил Касаджиков wrote:
> Потому что я говорю о «резервных копиях надолго». А для оперативных копий у
> меня давно настроен backup-manager с сохранением архивов на домашний NAS и с
> периодической чисткой этого дела.
Т.е. речь про лазерные диски не идет? Если бы была - по мне край
On 2017-06-23, Artem Chuprina wrote:
> Если я правильно понимаю, btrfs из-за своей сложности - больший риск
> потери данных, чем банальный ext2 (для архивного носителя, не путать с
> бэкапным, даже возможности ext4 не требуются).
Даже журнал не нужен.
Только вот вопрос как чистить каталог при сб
On Wed, 21 Jun 2017 22:34:10 -0400
Tim Sattarov wrote:
> Судя по тому, как его бэкпортили в Jessie, будут делать то же самое в
> Stretch.
Пока что не вижу vbox в stretch-backports. Может и правда появится.
--
Alexander Galanin
А в чём проблема подключить репозиторий самого virtualbox и поставить
оттуда?
23 июня 2017 г., 16:17 пользователь Alexander Galanin
написал:
> On Wed, 21 Jun 2017 22:34:10 -0400
> Tim Sattarov wrote:
>
> > Судя по тому, как его бэкпортили в Jessie, будут делать то же самое в
> > Stretch.
>
> По
On 23/06/17 03:41 AM, Oleksandr Gavenko wrote:
> Интересен другой момент. Информацию мы же не гравируем на платиновой
> пластинке. Деградация носителей - обычный процес.
>
Мне надысь ребята из одной софтверной конторы все уши прожужжали, как
они везде используют ZFS, даже на коротко живущих сервер
On Fri, 23 Jun 2017 16:27:21 +0300
Grigory Fateyev wrote:
> А в чём проблема подключить репозиторий самого virtualbox и поставить
> оттуда?
В доверии к работникам Oracle. В частности, в доверии к тому, что они
не накосячат и не положат в репозиторий пакетов, конфликтующих с
основным репозиторием
Oleksandr Gavenko писал(а) в своём письме Fri, 23 Jun 2017
15:58:46 +0300:
On 2017-06-23, Михаил Касаджиков wrote:
Потому что я говорю о «резервных копиях надолго». А для оперативных копий у
меня давно настроен backup-manager с сохранением архивов на домашний NAS и с
периодической чисткой эт
23 июня 2017 г., 16:40 пользователь Alexander Galanin
написал:
> On Fri, 23 Jun 2017 16:27:21 +0300
> Grigory Fateyev wrote:
>
> > А в чём проблема подключить репозиторий самого virtualbox и поставить
> > оттуда?
>
> В доверии к работникам Oracle. В частности, в доверии к тому, что они
> не нако
Михаил Касаджиков -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
16:56:05 +0300:
>> Еще вопрос - архивы этож не tar на магритную ленту? Индивидуальными файлами,
>> правда?
> Как раз tar. Используя LVM очень удобно делать snapshot и спокойно паковать
> каждый раздел в свой архив. В од
Tim Sattarov -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 09:29:41
-0400:
>> Интересен другой момент. Информацию мы же не гравируем на платиновой
>> пластинке. Деградация носителей - обычный процес.
>>
> Мне надысь ребята из одной софтверной конторы все уши прожужжали, как
> они ве
On 23/06/17 10:13 AM, Grigory Fateyev wrote:
>
> Странная логика. Пользоваться программой Oracle не боитесь, а вот
> собранным ими же пакетом, боитесь. Но да
> ладно, не моё это дело. :)
>
Логика тут простая: virtualbox-ose (open source edition) был пересобран
мэйнтейнерами Дебиан, есть какая то на
Oleksandr Gavenko -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
14:51:58 +0300:
>> Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
>> тебя интересует, не чтобы оно в принципе читалось, а чтобы оттуда
>> считывалось ровно то, что ты хотел бы считать. md5 -c впо
On 23/06/17 10:20 AM, Artem Chuprina wrote:
> А, ее уже довели до состояния "нормально есть в дистрибутиве"... Хотя
> пока пугает наличие пакета zfs-dkms, т.е. отсутствие поддержки
> мейнстрим-ядром.
>
Те ребята пользуются Ubuntu, где ZFS "из коробки"
я честно говоря не вижу смысла в установке её
Grigory Fateyev -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017 17:13:20
+0300:
>> > А в чём проблема подключить репозиторий самого virtualbox и поставить
>> > оттуда?
>>
>> В доверии к работникам Oracle. В частности, в доверии к тому, что они
>> не накосячат и не положат в репозитори
On Fri, Jun 23, 2017 at 05:13:37PM +0300, Artem Chuprina wrote:
> тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по
> возможности бэкапы делаются rsync'ом. Инкрементальный - rsync после cp -al.
>
> С другой стороны, если надо сохранить систему владельцев и прав при
> бэкапе на
Eugene Berdnikov -> debian-russian@lists.debian.org @ Fri, 23 Jun 2017
18:06:00 +0300:
>> тебе надо файл из конца, то приходится прочитать весь файл. Поэтому по
>> возможности бэкапы делаются rsync'ом. Инкрементальный - rsync после cp -al.
>>
>> С другой стороны, если надо сохранить систему
23.06.2017 11:47, Victor Wagner пишет:
> On Thu, 22 Jun 2017 23:13:25 +0300
> artiom wrote:
>
>
>>>
>> Дык зачем использовать stable, когда testing уже вполне стабилен?
>
> Как уже? Еще. Этому тестингу от роду 4 дня. А то что было тестингом
> неделю назад сейчас stable.
>
>
В данном слу
On 2017-06-23, Tim Sattarov wrote:
> Я, честно говоря, скептичен, но описание файловой системы и то как она
> борется с такими "тихими" проблемам достаточно, чтобы посмотреть в её
> сторону...
Мои познания в ZFS ограничены "чексумами".
Во первых не ясно как ошибка в чексуме вернется через систем
*** Oleksandr Gavenko [2017-06-23 22:11]:
>Мои познания в ZFS ограничены "чексумами".
>
>Во вторых не ясно перечитывает ли в офлайне ZFS чексумы файлов и как она
>сообщит о проблеме?
Контрольные суммы всегда читаются вместе с данными и это будет ошибка
ввода/вывода (типа битый блок) если не сойдё
Раз пошла такая пьянка (топик про Debian без system.d, приведший к
топику о физической деградации носителей со временем), не будет уже
оффтопиком задать и мой вопрос.
Припёрло сделать NAS, после того, как пару дней назад сдох последний IDE
диск, на который делались бэкапы.
Хочу, чтобы NAS торчал
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".
>
> ... и ты получаешь нежел
On Fri, Jun 23, 2017 at 10:25:01PM +0300, artiom wrote:
> - RAID, кроме mirror, не дают повышения надёжности (упал диск - потерял
> часть данных, упал диск в рэйде - рейд может и не пересобраться,
> потеряются все данные, упало два - капут). Это верно?
Нет, неверно. Отказоустойчивость не даёт тол
*** artiom [2017-06-23 22:27]:
>Хочу, чтобы NAS торчал в Интернет и был точкой синхронизации пока между
>ноутом и стационарным компом.
>- Какие диски лучше использовать (объём, марка)? Был обзор со
>статистикой, вроде как Хитачи отказывают меньше всех. Так?
Лично мой опыт говорит что Hitachi/HGS
*** Eugene Berdnikov [2017-06-23 22:45]:
> Отказоустойчивость не даёт только raid0 ака jbod.
Придерусь к терминологии, но JBOD это не RAID0. RAID0 делает striping --
то есть "размазывает" блоки по дискам, позволяя читать параллельно со
всех дисков разом. А JBOD это просто "конкатенация" дисков др
23.06.2017 22:44, Eugene Berdnikov пишет:
> On Fri, Jun 23, 2017 at 10:25:01PM +0300, artiom wrote:
>> - RAID, кроме mirror, не дают повышения надёжности (упал диск - потерял
>> часть данных, упал диск в рэйде - рейд может и не пересобраться,
>> потеряются все данные, упало два - капут). Это верн
23.06.2017 22:50, Sergey Matveev пишет:
> *** Eugene Berdnikov [2017-06-23 22:45]:
>> Отказоустойчивость не даёт только raid0 ака jbod.
>
> Придерусь к терминологии, но JBOD это не RAID0. RAID0 делает striping --
> то есть "размазывает" блоки по дискам, позволяя читать параллельно со
> всех дис
*** artiom [2017-06-23 22:57]:
>Не про отказоустойчивость вопрос, а про повышение надёжности
>относительно отсутствие рэйда.
>Рэйды 5 и 8, если не ошибаюсь, где хранятся контрольные суммы не
>увеличивают надёжность, по утверждению товарища.
RAID5 не хранит контрольные суммы, он хранит XOR от блок
*** artiom [2017-06-23 22:58]:
>Да, как-раз JBOD и рекомендовался.
Зачем? У вас JBOD на двух 1TiB дисках -- значит вылетел один диск и
какой-то из двух терабайт вы потеряли навсегда. Для NAS непонятно зачем
оно, ведь если вылетел один диск, то, скорее всего, данные на всех
остальных станут беспол
On 2017-06-23, Sergey Matveev wrote:
> Передёргивать нужно не только на чтение, но, в идеале, ещё и на запись.
Это потому что нету гарантий производителя?
Современные роботизированые type library просто переодически перезаписывают
данные на новую бобину. Производитель обеспокоился, пользователи
*** Oleksandr Gavenko [2017-06-23 23:12]:
>Современные роботизированые type library просто переодически перезаписывают
>данные на новую бобину. Производитель обеспокоился, пользователи не
>замарачиваються.
>
>Выходит что проще с архивами поступать как с бекапами - переписывать на новый
>носитель с
On 06/20/17 16:10, sergio wrote:
> рассылка-хуилка ведёт себя как говно-хуивно
> этот текст тут для того, что бы письмо ушло в рассылку
>
>
> ну баг потом смотришь:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
>
Вот ругаешься, а гугл твои письма регулярно в спам кидает. Настрой
почтов
On 06/23/17 16:22, Sergey Matveev wrote:
>
> Прошу прощения что снова про ZFS,
Продолжай в том же духе, интересно :)
> но в его "мире" есть практика такой
> перезаписи путём инициирования подобия RAID rebuild-а. Добавляете диск,
> говоря что он будет частью зеркала, начинается процесс resilvering
*** Tim Sattarov [2017-06-24 00:21]:
>не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
>в RAIDz ?
Так просто не скажешь. ZFS очень любит память -- с ней ей очень хорошо.
То бишь, при нормальном её размере всё должно упираться в диск. Про
скорость, опять же, всё сложно. Напр
On 23.06.2017 23:05, Sergey Matveev wrote:
*** artiom [2017-06-23 22:57]:
Не про отказоустойчивость вопрос, а про повышение надёжности
относительно отсутствие рэйда.
Рэйды 5 и 8, если не ошибаюсь, где хранятся контрольные суммы не
увеличивают надёжность, по утверждению товарища.
RAID5 не хран
On 06/23/17 17:41, Sergey Matveev wrote:
> *** Tim Sattarov [2017-06-24 00:21]:
>> не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
>> в RAIDz ?
> Так просто не скажешь.
> Короче нужно смотреть на
> задачи, на режимы использования, на настройки. ZFS дорогая: на паршивом
> ж
On 23.06.2017 23:07, Sergey Matveev wrote:
*** artiom [2017-06-23 22:58]:
Да, как-раз JBOD и рекомендовался.
Зачем? У вас JBOD на двух 1TiB дисках -- значит вылетел один диск и
какой-то из двух терабайт вы потеряли навсегда. Для NAS непонятно зачем
оно, ведь если вылетел один диск, то, скорее
On 23.06.2017 22:48, Sergey Matveev wrote:
*** artiom [2017-06-23 22:27]:
Хочу, чтобы NAS торчал в Интернет и был точкой синхронизации пока между
ноутом и стационарным компом.
- Какие диски лучше использовать (объём, марка)? Был обзор со
статистикой, вроде как Хитачи отказывают меньше всех.
On 19.06.2017 23:46, Артём Н. wrote:
Подскажите, чем удобно играть музыку "в фоне"?
В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не
обязательно).
Также, желательно не GTK.
Попробовал Clementine, хороший, но не нравится управление.
Amarok как-то в последнее время разоч
On 24.06.2017 01:51, Артём Н. wrote:
On 19.06.2017 23:46, Артём Н. wrote:
Подскажите, чем удобно играть музыку "в фоне"?
В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не
обязательно).
Также, желательно не GTK.
Попробовал Clementine, хороший, но не нравится управление.
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:
> > > Собственно, я абсолютно уверен, что надо проверять криптосуммы. Ну, если
On Fri, Jun 23, 2017 at 02:26:55PM +0300, Artem Chuprina wrote:
> Если я правильно понимаю, btrfs из-за своей сложности - больший риск
> потери данных, чем банальный ext2 (для архивного носителя, не путать с
> бэкапным, даже возможности ext4 не требуются).
Мда, летайте на "Фарманах", друзья... Фа
Обновился апач.
И у меня когда-то уже была такая ошибка:
Настраивается пакет apache2 (2.4.25-3+deb9u1) …
info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
ERROR: Conf apache2-doc does not exist!
dpkg: ошибка при обработке пакета apache2 (--configure):
подпроцесс установлен с
попробуйте так
apt-get download
sudo dpkg --unpack *.deb
sudo rm /var/lib/dpkg/info/.postinst -f
sudo dpkg --configure
sudo apt-get install -yf #To fix dependencies
24 июня 2017 г., 9:43 пользователь Артём Н. написал:
> Обновился апач.
> И у меня когда-то уже была такая ошибка:
> Настраивает
55 matches
Mail list logo
