subject:"бэкап"

*** Vasiliy P. Melnik  [2017-07-16 21:55]:
>далась вам эта фрагментация, сказали держать 20% свободного места и все будет 
>хорошо.

В ZFS её легко можно получить просто медленно записывая файл. Да, можно
потом сделать cp file file_ && mv file_ file, но а если файлов много и
мало ли какие ещё режимы работы будут? Всякое может быть, и медленная
запись файла не позволит его быстро прочитать это факт.

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

Re: зеркальный бэкап ZFS

*** Alex Kicelew  [2017-07-16 22:11]:
>правильно ли я понимаю, что худшее, что я получу при
>превышении количества имеющихся чекпойнтов -- это необходимость снова
>ресилверить 4 часа вместо 5 минут?

Да, всё верно.

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

Re: зеркальный бэкап ZFS

2017-07-16 Пенетрантность Alex Kicelew

On 07/16/17 21:43, Sergey Matveev wrote:
> Тоже всё верно. Но есть засада. Время от времени ZFS делает checkpoint
> -- обновляет überblock ссылающийся на самое свежее дерево метаданных. У
> этого checkpoint есть, грубо говоря, timestamp, который только
> увеличивается. Во время вставки диска для resilvering он пытается понять
> не был ли он частью этого пула и если был, то он понимает насколько
> checkpoint-ов он "отстал" от основного. Найдя в основном поле старый
> checkpoint, он может создать "diff", который будет заresilverен. Но если
> прошло достаточно большое время, то настолько старого checkpoint-а не
> будет и он вынужден будет делать resilvering полностью всех данных с
> нуля, ведь он же не может "вечно" хранить все прошлые известные ему
> checkpoint-ы/überblock-и. Я точно не уверен, но вот терзают смутные
> сомнения что он будет хоть как-то смотреть на данные которые там всё же
> были -- поэтому такой старый диск для него будет как пустой.
> 
> Кол-во checkpoint-ов на пуле вроде как фиксировано и что-то порядка
> полутысячи (где-то слышал). То есть минуты отключенного состояния он
> конечно переживёт спокойно, но вот часы уже навряд ли.
> 

Ага, спасибо. Об этом я не знал. На самом деле такой способ уже был
проверен (перед тем, как спрашивать о его безопасности я хотел убедиться
хотя бы в том, что он осуществим физически), и на сутки чекпойнтов явно
хватает (первичный ресилверинг был около 4х часов, последующие -- 5-10
минут), но правильно ли я понимаю, что худшее, что я получу при
превышении количества имеющихся чекпойнтов -- это необходимость снова
ресилверить 4 часа вместо 5 минут?

Re: зеркальный бэкап ZFS

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

*** Vasiliy P. Melnik  [2017-07-16 21:59]:
>> Как минимум, zpool scrub может сообщить какие именно файлы повреждены и
>> из бэкапа их взять можно будет. Один раз у меня, когда внешний жёсткий
>> диск начал сыпаться, как-раз scrub показал что вот такой и такой файлы
>> биты -- взял из прошлого бэкапа.
>
>У нас наверное просто разный подход к резервированию критично важных
>данных: как показала недавняя у нас ситуация с шифровальщиком - бекапов
>много не бывает. И лучше разных и в разных местах

Я не понял в чём она у нас разная и какой у вас подход.

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

Re: зеркальный бэкап ZFS

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

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

Re: зеркальный бэкап ZFS

2017-07-16 Пенетрантность Alex Kicelew

On 07/16/17 21:43, Vasiliy P. Melnik wrote:
> Уравнение со слишком многими неизвестными и слишком большим количеством
> если.
> 
> так с данными лучше не поступать - проще использовать рсинк, и лучше
> складывать на ехт4, ибо инструментов рекавери с зфс-а нет, а один раз я уже
> был в ситуации, когда очень бы они пригодились

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

Что касается риска... Я допускаю, что у zfs он выше. Но раз уж я в
качестве эксперимента на нее перешел, то хотелось бы получить от этого
эксперимента максимум экспириенса. :) Все же бОльшая часть (хотя и не
все) данных у меня автоматически синхронизируется между всеми доступными
машинами (две домашние и две рабочие), а бэкап нужен в 75% для того,
чтобы не возиться с ручным сбором этих данных со всех машин. И как раз в
случае ноута -- чтобы было можно просто загрузиться с бэкапного винта, и
все.

Re: зеркальный бэкап ZFS

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

*** Vasiliy P. Melnik  [2017-07-16 21:45]:
>так с данными лучше не поступать - проще использовать рсинк

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

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

Re: зеркальный бэкап ZFS

>
> Но похожий хак можно например использовать для дефрагментации диска.


далась вам эта фрагментация, сказали держать 20% свободного места и все
будет хорошо.

Re: зеркальный бэкап ZFS

*** Alex Kicelew  [2017-07-16 21:02]:
>2) дожидаемся окончания ресилвера, однократно делаем этот диск
>загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в
>degraded state, но полностью работоспособный (в этом моменте я уверен не
>до конца, и хотелось бы выслушать его подтверждение или опровержение);

Но похожий хак можно например использовать для дефрагментации диска.
Вообще с ней проблем быть не должно если всегда имеется запас
достаточного количества свободного места (которое можно зарезервировать
например как-то так: zfs set reservation=XXXG mypool/reserved), но
всякое может быть. Так вот resilvering делается не как в RAID-е
байт-в-байт, а записывая на диск сериализованное представление
diff-а/данных: поэтому в зеркале на дисках данные могут лежать очень по
разному и с очень разной степень фрагментации. Добавляем диск-зеркало:
zpool attach mypool mydisk-first mydisk-second, ждём resilvering, потом
делаем *detach* основного диска: zpool detach mypool mydisk-first --
массив не будет в degraded состоянии и в нём будет хорошо
дефрагментированный диск. Процедуру можно повторить чтобы всё же
оригинальный диск был в pool-е. В отличии от zfs send/recv -- не нужно
систему переводить в offline, всё прозрачно работает.

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

Re: зеркальный бэкап ZFS

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

*** Alex Kicelew  [2017-07-16 21:02]:
>2) дожидаемся окончания ресилвера, однократно делаем этот диск
>загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в
>degraded state, но полностью работоспособный (в этом моменте я уверен не
>до конца, и хотелось бы выслушать его подтверждение или опровержение);

Да, всё верно.

>Цель этих нетривиальных действий: если в процессе эксплуатации основного
>диска (когда резервный отключен) на нем возникнет checksum error, есть
>предположение (в котором я как раз совершенно не уверен), что когда
>вечером будет подключен резервный и окажется, что поврежденные данные
>есть в неповрежденном виде на резервном, zfs поправит их на основном,
>как он поступает в случае, если в момент обнаружения ошибки доступны оба
>зеркала.

Тоже всё верно. Но есть засада. Время от времени ZFS делает checkpoint
-- обновляет überblock ссылающийся на самое свежее дерево метаданных. У
этого checkpoint есть, грубо говоря, timestamp, который только
увеличивается. Во время вставки диска для resilvering он пытается понять
не был ли он частью этого пула и если был, то он понимает насколько
checkpoint-ов он "отстал" от основного. Найдя в основном поле старый
checkpoint, он может создать "diff", который будет заresilverен. Но если
прошло достаточно большое время, то настолько старого checkpoint-а не
будет и он вынужден будет делать resilvering полностью всех данных с
нуля, ведь он же не может "вечно" хранить все прошлые известные ему
checkpoint-ы/überblock-и. Я точно не уверен, но вот терзают смутные
сомнения что он будет хоть как-то смотреть на данные которые там всё же
были -- поэтому такой старый диск для него будет как пустой.

Кол-во checkpoint-ов на пуле вроде как фиксировано и что-то порядка
полутысячи (где-то слышал). То есть минуты отключенного состояния он
конечно переживёт спокойно, но вот часы уже навряд ли.

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

Re: зеркальный бэкап ZFS

Уравнение со слишком многими неизвестными и слишком большим количеством
если.

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

16 июля 2017 г., 21:00 пользователь Alex Kicelew 
написал:

> Hi
>
> Вопрос адресован к тем, кто давно работает с ZFS (наверное, неважно, на
> какой платформе) и хорошо в ней разбирается.
>
> Просьба оценить (не)жизнеспособность такого экстравагантного способа
> бэкапа пула, состоящего из одного диска:
>
> 1) в первый раз подсоединяем бэкапный диск по USB и говорим zpool
> attach, в результате чего пул становится зеркальным и начинается
> ресилверинг основного диска на резервный;
>
> 2) дожидаемся окончания ресилвера, однократно делаем этот диск
> загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в
> degraded state, но полностью работоспособный (в этом моменте я уверен не
> до конца, и хотелось бы выслушать его подтверждение или опровержение);
>
> 3) с определенной периодичностью подключаем резервный диск, говорим ему
> zpool online, дожидаемся окончания ресилвера, говорим zpool offline и
> отключаем обратно.
>
> Цель этих нетривиальных действий: если в процессе эксплуатации основного
> диска (когда резервный отключен) на нем возникнет checksum error, есть
> предположение (в котором я как раз совершенно не уверен), что когда
> вечером будет подключен резервный и окажется, что поврежденные данные
> есть в неповрежденном виде на резервном, zfs поправит их на основном,
> как он поступает в случае, если в момент обнаружения ошибки доступны оба
> зеркала. Если мое предположение неправильно, то, разумеется, такие
> неочевидные действия совершенно не нужны, достаточно zfs send (-I) -R.
> Но вдруг?..
>
>

зеркальный бэкап ZFS

2017-07-16 Пенетрантность Alex Kicelew

Hi

Вопрос адресован к тем, кто давно работает с ZFS (наверное, неважно, на
какой платформе) и хорошо в ней разбирается.

Просьба оценить (не)жизнеспособность такого экстравагантного способа
бэкапа пула, состоящего из одного диска:

1) в первый раз подсоединяем бэкапный диск по USB и говорим zpool
attach, в результате чего пул становится зеркальным и начинается
ресилверинг основного диска на резервный;

2) дожидаемся окончания ресилвера, однократно делаем этот диск
загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в
degraded state, но полностью работоспособный (в этом моменте я уверен не
до конца, и хотелось бы выслушать его подтверждение или опровержение);

3) с определенной периодичностью подключаем резервный диск, говорим ему
zpool online, дожидаемся окончания ресилвера, говорим zpool offline и
отключаем обратно.

Цель этих нетривиальных действий: если в процессе эксплуатации основного
диска (когда резервный отключен) на нем возникнет checksum error, есть
предположение (в котором я как раз совершенно не уверен), что когда
вечером будет подключен резервный и окажется, что поврежденные данные
есть в неповрежденном виде на резервном, zfs поправит их на основном,
как он поступает в случае, если в момент обнаружения ошибки доступны оба
зеркала. Если мое предположение неправильно, то, разумеется, такие
неочевидные действия совершенно не нужны, достаточно zfs send (-I) -R.
Но вдруг?..

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

2016-03-24 Пенетрантность Андрей Любимец

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

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

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

2016-03-24 Пенетрантность Artem Chuprina

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
12:45:36 +0200:

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

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

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

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

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

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

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

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

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

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

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

2016-03-24 Пенетрантность Eugene Berdnikov

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

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

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

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

On 2016-03-24, Artem Chuprina wrote:

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

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

  Reliability

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

  Durability

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

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

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

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

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

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

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

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

-- 
http://defun.work/

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

2016-03-24 Пенетрантность Artem Chuprina

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 
12:00:20 +0200:

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

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

 OG> От туда:

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

 OG> Лукавит:

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

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

 OG>  price/GiB  Write

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

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

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

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

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

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

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

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

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

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

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

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

От туда:

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

Лукавит:

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

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

 price/GiB  Write

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

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

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

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

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

-- 
http://defun.work/

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

2016-03-24 Пенетрантность Eugene Berdnikov

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

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

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

2016-03-24 Пенетрантность Artem Chuprina

Андрей Любимец -> debian-russian@lists.debian.org  @ Thu, 24 Mar 2016 13:26:26 
+0600:

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

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

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

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

2016-03-24 Пенетрантность Андрей Любимец

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

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

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

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

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

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

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
20:37:44 +0300:

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

 EB>  Я подумал, что проще и эффективнее "cp -al", а затем на полученной копии
 EB>  "rsync --delete". Это даёт инкрементальный бэкап (эквивалентный полному)
 EB>  и не требует поддержки снапшотов.

Не требует.  Я дома так и делаю.  Но если снапшоты все равно в комплекте?

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

On Wed, Mar 23, 2016 at 08:06:09PM +0300, Sergey B Kirpichev wrote:
> On Wed, Mar 23, 2016 at 07:52:40PM +0300, Eugene Berdnikov wrote:
> >  Интересно, для чего может понадобиться снапшот свежего бэкапа?
> 
> Я понял так, что просто делается синхронизация rsync, а потом
> получившееся состояние запоминается с помощью снапшота.
> 
> А вы что подумали?)

 Я подумал, что проще и эффективнее "cp -al", а затем на полученной копии
 "rsync --delete". Это даёт инкрементальный бэкап (эквивалентный полному)
 и не требует поддержки снапшотов.

 Можно и в обратном порядке, конечно, но тогда да, без снапшота тоска.
-- 
 Eugene Berdnikov

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

On Wed, Mar 23, 2016 at 07:52:40PM +0300, Eugene Berdnikov wrote:
>  Интересно, для чего может понадобиться снапшот свежего бэкапа?

Я понял так, что просто делается синхронизация rsync, а потом
получившееся состояние запоминается с помощью снапшота.

А вы что подумали?)

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

On Wed, Mar 23, 2016 at 07:04:25PM +0300, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
> 17:57:44 +0300:
> 
>  >> Механизм простой - рсинком сливаешь и делаешь снапшот
> 
>  EB>  Лучше наоборот, меньше вероятность неконсистентности.
> 
>  EB>  Вообще, с rsync'ом снапшот не особо-то нужен. К тому же на той стороне,
>  EB>  которую нужно бэкапить, может не быть снапшотов.
> 
> Речь про бэкап-сервер.  На нем делается снапшот того, что только что
> сбэкапили.

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

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

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
17:57:44 +0300:

 >> Механизм простой - рсинком сливаешь и делаешь снапшот

 EB>  Лучше наоборот, меньше вероятность неконсистентности.

 EB>  Вообще, с rsync'ом снапшот не особо-то нужен. К тому же на той стороне,
 EB>  которую нужно бэкапить, может не быть снапшотов.

Речь про бэкап-сервер.  На нем делается снапшот того, что только что
сбэкапили.  Если на том, что бэкапится, есть снапшоты, то там снапшот
делается до.  Но у меня как раз не будет.

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

2016-03-23 Пенетрантность sergio

On 23/03/16 15:51, Artem Chuprina wrote:

> Ну, я понимаю, что RAID 5 не переживет вылет любых двух дисков, в то
> время как RAID 10 - только половину вариантов.

Они оба не переживут при вылете двух дисков. 10 это не совсем 1+0.

Разница в том, что при вылете диска на RAID 5 I/O просядет заметно
больше чем на RAID 10. Ну и на восстановлении эта разница будет ещё
более заметной.

-- 
sergio

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

2016-03-23 Пенетрантность Dmitry Kulagin






On Wed, Mar 23, 2016 at 05:04:58PM +0300, Dmitry Kulagin wrote:

Более 10-ти лет работаю по следующей схеме.
На каждом диске создается по 3 раздела - swap (1-4 GB), boot (500MB), sys.
Boot разделы собираются в raid1 и монтируются в /boot, первые 2 диска -
основные, остальные - spare.

  Загрузчик в mbr как ставится при такой схеме, на каждый диск отдельно?


Да




Аналогично для swap (при желании).

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


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

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

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
17:49:54 +0300:

 >> Аналогично для swap (при желании).

 EB>  Зачем своп на рейде делать? Данные там имеют ценность лишь при хибернейте,
 EB>  иначе рейд даёт лишь накладные расходы. Не лучше ли подключить несколько
 EB>  своповых разделов подряд, задав им приоритеты по вкусу?

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

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

On Wed, Mar 23, 2016 at 04:00:49PM +0200, Vasiliy P. Melnik wrote:
> Механизм простой - рсинком сливаешь и делаешь снапшот

 Лучше наоборот, меньше вероятность неконсистентности.

 Вообще, с rsync'ом снапшот не особо-то нужен. К тому же на той стороне,
 которую нужно бэкапить, может не быть снапшотов.
-- 
 Eugene Berdnikov

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

On Wed, Mar 23, 2016 at 05:04:58PM +0300, Dmitry Kulagin wrote:
> Более 10-ти лет работаю по следующей схеме.
> На каждом диске создается по 3 раздела - swap (1-4 GB), boot (500MB), sys.
> Boot разделы собираются в raid1 и монтируются в /boot, первые 2 диска -
> основные, остальные - spare.

 Загрузчик в mbr как ставится при такой схеме, на каждый диск отдельно?

> Аналогично для swap (при желании).

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

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

On Wed, Mar 23, 2016 at 05:04:58PM +0300, Dmitry Kulagin wrote:
> В качестве современной альтернативы данной схемы можно предложить btrfs или
> zfs, в которых и фс,
> и рейд, и lvm в одном флаконе.

btrfs не умеет нормально raid5 в jessie.

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

Vasiliy P. Melnik -> debian-russian  @ Wed, 23 Mar 2016 16:00:49 +0200:

 > так модуль есть в кернел для зфса - у меня правда на оракл линукс стоит, но
 > не думаю что это принципиально.

А вот зря.  Оракл теперь владелец оригинала, у него этот модуль
гарантированно не сломается при апгрейде ядра.  А дебиан - отнюдь.  А
модуль, как я понимаю, ни разу не в апстриме.

Впрочем, судя по тому, что пишут на zfsonlinux, работа по внедрению в
дебиан уже идет, так что можно брать...

 > Правда больше на фре использую, но тут вопрос не принципиальный: там
 > модуль из коробки, здесь - из репозитария.  Жалею только, что систему
 > поставил на эти же винты - сложно что-то переделывать

Ну, у меня и вариантов-то нет, нету других винтов.

 > Механизм простой - рсинком сливаешь и делаешь снапшот

Угу, стоит попробовать...

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

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

2016-03-23 Пенетрантность Vasiliy P. Melnik

On Wed, Mar 23, 2016 at 04:00:49PM +0200, Vasiliy P. Melnik wrote:
>У меня просто обычный raid1 , но зфс много умеет разных рейдов. Есть
>компрессия на лету, что тоже хорошо

Есть data-checksums, что весьма полезно.  Не знаю сколько у ТС
предполагается храниться бекапу, но у меня данные на md raid
периодически протухают.

>З.Ы. пробовал btrfs - тормозное оно шибко, но тоже работает как надо 

А в каком месте тормозное, в смысле последующей работы со снапшотами?

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

2016-03-23 Пенетрантность Dmitry Kulagin

Более 10-ти лет работаю по следующей схеме.
На каждом диске создается по 3 раздела - swap (1-4 GB), boot (500MB), sys.
Boot разделы собираются в raid1 и монтируются в /boot, первые 2 диска -
основные, остальные - spare.

Аналогично для swap (при желании).
Sys разделы собираются в raid5, поверх создается lvm, в котором
создаются /,/var,/home и т.д.
Проблем с загрузкой никаких, установщик как минимум 3 последних версий
Debian позволяет создать

и загрузить такую систему.
Потеря системы за это время случилась всего один раз из-за бага в работе
NCQ в дисках Samsung,
когда под высокой нагрузкой из рейда вылетел первый диск, а потом в
процессе восстановления - второй.
В качестве современной альтернативы данной схемы можно предложить btrfs
или zfs, в которых и фс,
и рейд, и lvm в одном флаконе. Последняя позволяет заметно ускорить
работу при вынесении cache и log
на ssd диск, но сильно страдает от дефрагментации из-за COW, что,
правда, не актуально для бэкап-

сервера. Установщик ее не поддерживает.
Jessie поддерживает btrfs, на одном разделе точно, но можно ли
выбирать рейд режимы и несколько разделов при установке мне неизвестно.

23.03.2016 13:06, Artem Chuprina пишет:

Люди местные, сами мы недобрые, поможите умным словом.

Никогда не работал раньше с софтверным рейдом. Ситуация.

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

Четыре винта по 500 Gb. На самом деле 6, но рейд-контроллер давно сдох
от перегрева, и еще два воткнуть некуда. Винты вроде живы. Винты
одинаковые, т.е. в случае чего будет что воткнуть вместо сдохшего, и
даже два раза. Хочется иметь не четыре раздела с ручным
перетасовыванием, а один. Хочется некоторого запаса надежности, потому
хочется не тупо LVM, а софтверный рейд.

Грузиться буду с него же. ATA есть, но отдельного винта и даже флешки
нет.

Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
полтерабайта сделает полтора? Какие тонкости с загрузкой?

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

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

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

Механизм простой - рсинком сливаешь и делаешь снапшот

З.Ы. пробовал btrfs - тормозное оно шибко, но тоже работает как надо


23 марта 2016 г., 15:46 пользователь Artem Chuprina <r...@lasgalen.net>
написал:

> Vasiliy P. Melnik -> debian-russian  @ Wed, 23 Mar 2016 15:00:04 +0200:
>
>  VPM> А данные какие? я держу бекапы на зфс-е - у меня достаточно мало
> изменений,
>  VPM> ну и плюс снапшоты очень удобная вещь и спасает от удаления данных
>
> Данные разные, но в целом, вероятно, со сравнительно небольшими
> изменениями.  Исключений, типа дампа базы данных, немного.
>
> А можно поподробнее про модель?  ZFS применяется вместо рейда, со своим
> собственным?  Или ты применяешь без рейда?  zfs-fuse, т.е. система на
> чем-то еще?  Создание бэкапа при этом как - по принципу "сделали бэкап,
> затем сделали снапшот"?
>
>

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

2016-03-23 Пенетрантность Stanislav Vlasov

23 марта 2016 г., 17:39 пользователь Artem Chuprina  написал:
>  >> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью.  В
>  >> смысле, в случае вылета винта.

>  > В случае вылета винта вы получите данные без избыточности
>  > и при проблемах с любым оставшимся диском - потерю данных. // КО.

> Это я невнятно говорю или ты невнятно понимаешь?  Про очевидное я в
> курсе.  Вопрос в том, насколько гладко проходит замена винта.

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

>  >> И кто чем, кстати, мониторит состояние mdraid?
>
>  > mdadm пакет запускает стандартно mdadm --monitor, обычно этого
>  > достаточно, про проблемы он пишет на почту.  Плюс регулярно из кронтаба

У нас для этого nagios опрашивает состояние через nrpe. Не помню,какой
у него плугин, но что-то стандартное.

-- 
Stanislav

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

2016-03-23 Пенетрантность Vasiliy P. Melnik

Vasiliy P. Melnik -> debian-russian  @ Wed, 23 Mar 2016 15:00:04 +0200:

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

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

А можно поподробнее про модель?  ZFS применяется вместо рейда, со своим
собственным?  Или ты применяешь без рейда?  zfs-fuse, т.е. система на
чем-то еще?  Создание бэкапа при этом как - по принципу "сделали бэкап,
затем сделали снапшот"?

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

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

23 марта 2016 г., 14:51 пользователь Artem Chuprina <r...@lasgalen.net>
написал:

> Андрей Любимец -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016
> 17:49:52 +0600:
>
>  >>  >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех
> винтов по
>  >>  >>  >> полтерабайта сделает полтора?
>  >>  >>
>  >>  >>  SBK> Места-то сколько надо?
>  >>  >>
>  >>  >> Бэкап-сервер. Лучше больше.
>  >>
>  >>  > Ну тогда все просто.  Больше чем raid5 вы не получите.
>  >>
>  >> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью.
> В
>  >> смысле, в случае вылета винта.
>  АЛ> я за raid10 -- погугли "Why RAID 5 Sucks"
>
> Погуглил.  Ничего внятного не увидел.
>
> Можно пояснить?
>
> Ну, я понимаю, что RAID 5 не переживет вылет любых двух дисков, в то
> время как RAID 10 - только половину вариантов.  За это в случае четырех
> дисков RAID 10 по сравнению с RAID 5 теряет треть пространства. В моем
> случае вылет сразу или почти сразу двух представляется маловероятным, а
> полтерабайта лишними, пожалуй, не будут.
>
> Еще?
>
>

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

Андрей Любимец -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 17:49:52 
+0600:

 >>  >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов 
 >> по
 >>  >>  >> полтерабайта сделает полтора?
 >>  >> 
 >>  >>  SBK> Места-то сколько надо?
 >>  >> 
 >>  >> Бэкап-сервер. Лучше больше.
 >> 
 >>  > Ну тогда все просто.  Больше чем raid5 вы не получите.
 >> 
 >> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью.  В
 >> смысле, в случае вылета винта.
 АЛ> я за raid10 -- погугли "Why RAID 5 Sucks"

Погуглил.  Ничего внятного не увидел.

Можно пояснить?

Ну, я понимаю, что RAID 5 не переживет вылет любых двух дисков, в то
время как RAID 10 - только половину вариантов.  За это в случае четырех
дисков RAID 10 по сравнению с RAID 5 теряет треть пространства. В моем
случае вылет сразу или почти сразу двух представляется маловероятным, а
полтерабайта лишними, пожалуй, не будут.

Еще?

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

Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
14:55:27 +0300:

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

 > В случае вылета винта вы получите данные без избыточности
 > и при проблемах с любым оставшимся диском - потерю данных. // КО.

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

 >> И кто чем, кстати, мониторит состояние mdraid?

 > mdadm пакет запускает стандартно mdadm --monitor, обычно этого
 > достаточно, про проблемы он пишет на почту.  Плюс регулярно из кронтаба
 > делается проверка райд.  B BTS кстати валяется мой патч, который делает
 > это чаще (ежедневно вроде) и инкрементально.

Вот это полезный ответ, спасибо.

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

2016-03-23 Пенетрантность Андрей Любимец

On Wed, Mar 23, 2016 at 02:24:44PM +0300, Artem Chuprina wrote:
> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью.  В
> смысле, в случае вылета винта.

В случае вылета винта вы получите данные без избыточности
и при проблемах с любым оставшимся диском - потерю данных. // КО.

> И кто чем, кстати, мониторит состояние mdraid?

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

>  > Если совсем лень - выделите отдельно разделы под /boot на
>  > дисках, с raid1 груб точно умеет грузиться сто лет.
> 
> Видимо, так и сделаю.

Да, оверхед в принципе небольшой.  Но должно уже работать и с raid5.

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

23.03.2016 17:24, Artem Chuprina пишет:
> Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
> 14:07:58 +0300:
> 
>  >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
>  >>  >> полтерабайта сделает полтора?
>  >> 
>  >>  SBK> Места-то сколько надо?
>  >> 
>  >> Бэкап-сервер. Лучше больше.
> 
>  > Ну тогда все просто.  Больше чем raid5 вы не получите.
> 
> Это я и сам понимаю.  Меня интересует, нету ли грабель с надежностью.  В
> смысле, в случае вылета винта.
я за raid10 -- погугли "Why RAID 5 Sucks"

> 
> И кто чем, кстати, мониторит состояние mdraid?
mdadm же и мониторит и почту шлёт

> 
>  >>  >> Какие тонкости с загрузкой?
>  >> 
>  >>  SBK> В jessie вроде должно уметь грузиться и с raid5.
>  >> 
>  >> Installation manual про это молчит. Говорит про RAID1.
> 
>  > Ну возьмите, да попробуйте в эмуляторе.  Честно говоря, я так
>  > сразу и про raid1 не нашел, где это?
> 
> https://www.debian.org/releases/stable/amd64/ch06s03.html.ru#mdcfg, примечание
> 
>  > Если совсем лень - выделите отдельно разделы под /boot на
>  > дисках, с raid1 груб точно умеет грузиться сто лет.
> 
> Видимо, так и сделаю.
>

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

Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
14:07:58 +0300:

 >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
 >>  >> полтерабайта сделает полтора?
 >> 
 >>  SBK> Места-то сколько надо?
 >> 
 >> Бэкап-сервер. Лучше больше.

 > Ну тогда все просто.  Больше чем raid5 вы не получите.

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

И кто чем, кстати, мониторит состояние mdraid?

 >>  >> Какие тонкости с загрузкой?
 >> 
 >>  SBK> В jessie вроде должно уметь грузиться и с raid5.
 >> 
 >> Installation manual про это молчит. Говорит про RAID1.

 > Ну возьмите, да попробуйте в эмуляторе.  Честно говоря, я так
 > сразу и про raid1 не нашел, где это?

https://www.debian.org/releases/stable/amd64/ch06s03.html.ru#mdcfg, примечание

 > Если совсем лень - выделите отдельно разделы под /boot на
 > дисках, с raid1 груб точно умеет грузиться сто лет.

Видимо, так и сделаю.

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

Stanislav Vlasov -> debian-russian  @ Wed, 23 Mar 2016 15:35:25 +0500:

 >>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
 >>  >> полтерабайта сделает полтора?

 SV> Работал и такой вариант, но нам было медленно...

 >>  SBK> Места-то сколько надо?
 >>
 >> Бэкап-сервер. Лучше больше.

 SV> У нас под бекапы делается raid10, но тут еще требуется обеспечить NN
 SV> потоков на запись (NN от 20 до 40 где-то).

Мне скорость не важна, а вот объем у raid10, как и у raid1, сразу в пополам...

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

2016-03-23 Пенетрантность Stanislav Vlasov

On Wed, Mar 23, 2016 at 01:24:08PM +0300, Artem Chuprina wrote:
> Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
> 13:14:52 +0300:
> 
>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
>  >> полтерабайта сделает полтора?
> 
>  SBK> Места-то сколько надо?
> 
> Бэкап-сервер. Лучше больше.

Ну тогда все просто.  Больше чем raid5 вы не получите.

>  >> Какие тонкости с загрузкой?
> 
>  SBK> В jessie вроде должно уметь грузиться и с raid5.
> 
> Installation manual про это молчит. Говорит про RAID1.

Ну возьмите, да попробуйте в эмуляторе.  Честно говоря, я так
сразу и про raid1 не нашел, где это?

Если совсем лень - выделите отдельно разделы под /boot на
дисках, с raid1 груб точно умеет грузиться сто лет.

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

23 марта 2016 г., 15:24 пользователь Artem Chuprina <r...@lasgalen.net> написал:

>  >> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
>  >> полтерабайта сделает полтора?

Работал и такой вариант, но нам было медленно...

>  SBK> Места-то сколько надо?
>
> Бэкап-сервер. Лучше больше.

У нас под бекапы делается raid10, но тут еще требуется обеспечить NN
потоков на запись (NN от 20 до 40 где-то).

>  >> Какие тонкости с загрузкой?
>
>  SBK> В jessie вроде должно уметь грузиться и с raid5.
>
> Installation manual про это молчит. Говорит про RAID1.

grub с raid10 грузится нормально, но из инсталлятора я туда его не
ставил - только руками после debootstrap.

-- 
Stanislav

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

Sergey B Kirpichev -> debian-russian@lists.debian.org  @ Wed, 23 Mar 2016 
13:14:52 +0300:

 >> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
 >> полтерабайта сделает полтора?

 SBK> Места-то сколько надо?

Бэкап-сервер. Лучше больше.

 >> Какие тонкости с загрузкой?

 SBK> В jessie вроде должно уметь грузиться и с raid5.

Installation manual про это молчит. Говорит про RAID1.

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

On Wed, Mar 23, 2016 at 01:06:54PM +0300, Artem Chuprina wrote:
> Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
> полтерабайта сделает полтора?

Места-то сколько надо?

> Какие тонкости с загрузкой?

В jessie вроде должно уметь грузиться и с raid5.

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

2015-10-23 Пенетрантность Andrey Tataranovich

Люди местные, сами мы недобрые, поможите умным словом.

Никогда не работал раньше с софтверным рейдом. Ситуация.

Грузиться буду с него же. ATA есть, но отдельного винта и даже флешки
нет.

Бэкап конфигурации диска

Доброго времени суток.

А может кто подскажет готовый инструмент для резервного
копирования/восстановления "сложной" дисковой конфигурации?

Под "сложной" я понимаю dm-crypt + lvm2. Плюс нужно восстановить UUID
файловых систем. Я понимаю, что все это можно воссоздать из livecd
руками и поправить /etc/{crypttab,fstab}, но хочется автоматизации.

-- 
WBR, Andrey Tataranovich

Re: криптованный бэкап : возможено реализовать простым путём?

2010-12-06 Пенетрантность Dmitri V. Ivanov

On Mon, Nov 29, 2010 at 03:47:22PM +0300, Artem Chuprina wrote:
 Ему для этого достаточно одного флаг-файла.  Ну, в предположении, что часы на
 бэкапимой машине идут нормально.  Но все остальные средства бэкапа тоже живут
 в этом предположении.  Только rsync, кажется, можно заставить проверять
 контент, но он это делает невообразимо долгое время (ну понятно, чтобы
 сравнить контент, его надо прочесть и из фс, и из бэкапа, целиком).

Если речь идет о GNU tar, то создание инкрементальных backup-ов там делается
через опцию --listed-incremental=file (насколько я помню). Говоря, что это 
флаг-файл IMHO стоит добавить, что в этом флаг-файле хранится (помимо момента
времени предыдущего backup) еще и информация, позволяющая отследить переиме-
нование каталогов (нужен как минимум список каталогов и их inode numbers).

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101206184024.ga6...@intex.spb.ru

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-29 Пенетрантность Denis Feklushkin

В Пнд, 29/11/2010 в 11:32 +0300, Artem Chuprina пишет:
Есть простые способы сделать инкрементальный бэкап
зашифрованным? Сейчас никакого бэкапа вообще нет, раз в неделю
вручную делаю копию + WAL-лог базы ведётся
dar с ключами -K, -J

Если следующим шагом захочется разных клиентов/стораджей,
может иметь смысл сразу посмотреть на bacula.

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

Дык эта... Штатный наш гнутый tar для инкрементального бэкапа даже список
файлов не использует. Так справляется...

dump/restore тоже

но это файлосистемозависимо, имхо

У tar, кажется, нет. У dump - да, он сам по себе по определению
файлосистемозависим.

но где-то ведь он хранит информацию о версиях файлов в бэкапе? ему же
нужно знать изменился файл с прошлого раза или нет

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1291026922.8209.76.ca...@localhost.localdomain

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-28 Пенетрантность Denis Feklushkin

В Сбт, 27/11/2010 в 19:57 +0200, Michael Shigorin пишет:
 On Fri, Nov 26, 2010 at 06:10:37PM +0200, Maxym Kudelya wrote:
  Есть простые способы сделать инкрементальный бэкап
  зашифрованным? Сейчас никакого бэкапа вообще нет, раз в неделю
  вручную делаю копию + WAL-лог базы ведётся
  dar с ключами -K, -J
 
 Если следующим шагом захочется разных клиентов/стораджей,
 может иметь смысл сразу посмотреть на bacula.

бакула была первым номером в списке, но я не нашёл как красиво
прикрутить к ней gpg


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1290942628.8209.66.ca...@localhost.localdomain

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-28 Пенетрантность Denis Feklushkin

В Пнд, 29/11/2010 в 02:58 +0300, Artem Chuprina пишет:
Есть простые способы сделать инкрементальный бэкап
зашифрованным? Сейчас никакого бэкапа вообще нет, раз в неделю
вручную делаю копию + WAL-лог базы ведётся
dar с ключами -K, -J

Если следующим шагом захочется разных клиентов/стораджей,
может иметь смысл сразу посмотреть на bacula.

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

dump/restore тоже

но это файлосистемозависимо, имхо

Re: криптованный бэкап : возможено реализовать простым путём?

2010-11-27 Пенетрантность Michael Shigorin

On Fri, Nov 26, 2010 at 06:10:37PM +0200, Maxym Kudelya wrote:
 Есть простые способы сделать инкрементальный бэкап
 зашифрованным? Сейчас никакого бэкапа вообще нет, раз в неделю
 вручную делаю копию + WAL-лог базы ведётся
 dar с ключами -K, -J

Если следующим шагом захочется разных клиентов/стораджей,
может иметь смысл сразу посмотреть на bacula.

-- 
  WBR, Michael Shigorin m...@altlinux.ru
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101127175707.ga25...@osdn.org.ua

Re: криптованный бэкап: в озможено реализовать прос тым путём?

2010-11-26 Пенетрантность Maxym Kudelya


25.11.2010 02:08, Denis Feklushkin пишет:

Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
базы ведётся


dar с ключами -K, -J

--
maxym


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cefdbfd.1070...@gmail.com

Re: криптованный бэкап: в озможено реализовать прос тым путём?

2010-11-25 Пенетрантность Jedi

Denis Feklushkin пишет:
 Хостинг у нас добрый, даёт нахаляву бэкапное место. Но кто у них там
 будет иметь к нему будет иметь доступ знает только Аллах.
 
 Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
 никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
 базы ведётся
 
 

есть смысл посмотреть

boxbackup-client
boxbackup-server


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cee1296.8080...@hotbox.ru

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-25 Пенетрантность Denis Feklushkin

В Чтв, 25/11/2010 в 12:23 +0500, Andrey Rahmatullin пишет:
 On Thu, Nov 25, 2010 at 07:08:05AM +0700, Denis Feklushkin wrote:
  Хостинг у нас добрый, даёт нахаляву бэкапное место. Но кто у них там
  будет иметь к нему будет иметь доступ знает только Аллах.
  
  Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
  никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
  базы ведётся
 duplicity
 

это ведь просто tar | gpg | ssh ? Чем это отличается от tar? 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1290675239..152.ca...@localhost.localdomain

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-25 Пенетрантность Denis Feklushkin

В Чтв, 25/11/2010 в 10:39 +0300, Jedi пишет:
 Denis Feklushkin пишет:
  Хостинг у нас добрый, даёт нахаляву бэкапное место. Но кто у них там
  будет иметь к нему будет иметь доступ знает только Аллах.
  
  Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
  никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
  базы ведётся
  
  
 
 есть смысл посмотреть
 
 boxbackup-client
 boxbackup-server
 
 

Не то - у меня нету специализированного бэкапного сервера, мне просто
дали доступное по sftp/cifs место


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1290675314..154.ca...@localhost.localdomain

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-25 Пенетрантность Denis Feklushkin

В Чтв, 25/11/2010 в 14:23 +0500, Andrey Rahmatullin пишет:
 On Thu, Nov 25, 2010 at 03:53:59PM +0700, Denis Feklushkin wrote:
Хостинг у нас добрый, даёт нахаляву бэкапное место. Но кто у них там
будет иметь к нему будет иметь доступ знает только Аллах.

Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
базы ведётся
   duplicity
  это ведь просто tar | gpg | ssh ? 
 librsync
 

А оно заработает с ssh?

  Чем это отличается от tar?
 Не, ну можно всё то же самое руками написать, но зачем?
 




-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1290677200..155.ca...@localhost.localdomain

Re: криптованный бэкап: возмо жено реализовать простым путём?

2010-11-25 Пенетрантность Said Chavkin

aespipe мне помог

2010/11/25 Denis Feklushkin denis.feklush...@gmail.com:
 Хостинг у нас добрый, даёт нахаляву бэкапное место. Но кто у них там
 будет иметь к нему будет иметь доступ знает только Аллах.

 Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
 никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
 базы ведётся


 --
 To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/1290643685..142.ca...@localhost.localdomain

криптованный бэкап: возможено реализовать простым путём?

2010-11-24 Пенетрантность Denis Feklushkin

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

Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
базы ведётся


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1290643685..142.ca...@localhost.localdomain

Re: криптованный бэкап: в озможено реализовать прос тым путём?

2010-11-24 Пенетрантность Nicholas



Например, используя loopback устройство:
apt-get install loop-aes-utils
apt-get install cryptsetup
modprobe loop
modprobe aes
modprobe dm-crypt
dd if=/dev/zero of=/home/marco/crloop bs=1M count=640
losetup /dev/loop0 /home/marco/crloop
cryptsetup -c aes -y create crloop /dev/loop0
mkfs.ext3 /dev/mapper/crloop
mount /dev/mapper/crloop /media/cryptovolume
umount /media/cryptovolume
cryptsetup remove crloop
losetup -d /dev/loop0

--
Sincerely,
Nicholas


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ickg2p$g...@dough.gmane.org

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-24 Пенетрантность Denis Feklushkin

В Срд, 24/11/2010 в 21:00 +, Nicholas пишет:
 Например, используя loopback устройство:
 apt-get install loop-aes-utils
 apt-get install cryptsetup
 modprobe loop
 modprobe aes
 modprobe dm-crypt
 dd if=/dev/zero of=/home/marco/crloop bs=1M count=640
 losetup /dev/loop0 /home/marco/crloop
 cryptsetup -c aes -y create crloop /dev/loop0
 mkfs.ext3 /dev/mapper/crloop
 mount /dev/mapper/crloop /media/cryptovolume
 umount /media/cryptovolume
 cryptsetup remove crloop
 losetup -d /dev/loop0
 
 -- 
 Sincerely,
   Nicholas
 
 

надо на лету. там слишком много инфы чтобы ещё удваивать этот объём и
складывать в бэкап. gpg, к тому же, умеет безопасно открытым ключом на
лету шифровать

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


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1290651547..147.ca...@localhost.localdomain

Re: криптованный бэкап: в озможено реализовать прос тым путём?

2010-11-24 Пенетрантность James Brown

Denis Feklushkin wrote:
 Хостинг у нас добрый, даёт нахаляву бэкапное место. Но кто у них там
 будет иметь к нему будет иметь доступ знает только Аллах.
 
 Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
 никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
 базы ведётся
 
 

Если криптовать прямо на сервере, так они (кто физически контролирует
машину в случае дедика или на чьей физмашине запущен вдс) всю
чувствительную информацию итак могут перехватить, не?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cedd284.3070...@gmail.com

Re: криптованный бэкап: возможено реализовать простым путём?

2010-11-24 Пенетрантность Denis Feklushkin

В Чтв, 25/11/2010 в 03:05 +, James Brown пишет:
 Denis Feklushkin wrote:
  Хостинг у нас добрый, даёт нахаляву бэкапное место. Но кто у них там
  будет иметь к нему будет иметь доступ знает только Аллах.
  
  Есть простые способы сделать инкрементальный бэкап зашифрованным? Сейчас
  никакого бэкапа вообще нет, раз в неделю вручную делаю копию + WAL-лог
  базы ведётся
  
  
 
 Если криптовать прямо на сервере, так они (кто физически контролирует
 машину в случае дедика или на чьей физмашине запущен вдс) всю
 чувствительную информацию итак могут перехватить, не?
 
 

так у меня и не вдс


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1290665719..149.ca...@localhost.localdomain

bacula: бэкап на FTP

2010-04-28 Пенетрантность Denis Feklushkin

bacula умеет делать сабж?

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


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100429072551.22424...@gmail.com

Re: удаленный бэкап

2010-03-20 Пенетрантность Alexey Pechnikov

Hello!

On Thursday 11 March 2010 12:18:14 DamirX wrote:
  зеркало всей машины?
 Нет. зеркало - в смысле дисковый массив из двух дисков уровня RAID1

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

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: удаленный бэкап

В Чтв, 11/03/2010 в 09:57 +0300, Alex Petrov пишет:
 Уважаемые, подскажите, чем и как лучше забэкапить удаленную машину? ну
 на случай обрушения винта к примеру, чтобы потом можно было
 восстановить в короткие сроки. ехать и подрубать cdrom, клавиатуру,
 мышь туда не хочется..
Насколько коротки, эти короткие сроки?
А так, вообще: rsnapshot, rdiffbackup, rsync на худой конец...

-- 
DamirX


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268294797.3631.32.ca...@everest.agg

Re: удаленный бэкап

2010-03-11 Пенетрантность Michael Shigorin

11 марта 2010 г. 11:06 пользователь DamirX damir.haki...@gmail.com написал:
 В Чтв, 11/03/2010 в 09:57 +0300, Alex Petrov пишет:
 Уважаемые, подскажите, чем и как лучше забэкапить удаленную машину? ну
 на случай обрушения винта к примеру, чтобы потом можно было
 восстановить в короткие сроки. ехать и подрубать cdrom, клавиатуру,
 мышь туда не хочется..
 Насколько коротки, эти короткие сроки?
 А так, вообще: rsnapshot, rdiffbackup, rsync на худой конец...


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

-- 
С уважением, Алексей

Re: удаленный бэкап

On Thu, Mar 11, 2010 at 09:57:34AM +0300, Alex Petrov wrote:
 Уважаемые, подскажите, чем и как лучше забэкапить удаленную
 машину? ну на случай обрушения винта к примеру, чтобы потом
 можно было восстановить в короткие сроки. ехать и подрубать
 cdrom, клавиатуру, мышь туда не хочется..

Для bare metal recovery можно рекомендовать mkcdrec
(если его уже переписали, то может быть на rear.sf.net
-- код был неряшистый, но рабочий; авторы это понимали).

-- 
  WBR, Michael Shigorin m...@altlinux.ru
  -- Linux.Kiev http://www.linux.kiev.ua/


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100311080659.gc15...@osdn.org.ua

Re: удаленный бэкап

2010-03-11 Пенетрантность Alexey Lobanov


On 11/03/10 09:57, Alex Petrov wrote:


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


Mindi/Mondo? Оно заточено именно под создание загружаемого комплекта CD 
для автоматического восстановления машины одним движением.


А.Л.


ехать и подрубать cdrom, клавиатуру,
мышь туда не хочется..




--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b98a5e0.9050...@gctrials.com

Re: удаленный бэкап

11 марта 2010 г. 11:12 пользователь Alexey Lobanov
a.loba...@gctrials.com написал:
 On 11/03/10 09:57, Alex Petrov wrote:

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

 Mindi/Mondo? Оно заточено именно под создание загружаемого комплекта CD для
 автоматического восстановления машины одним движением.


Просто дело в том, что там роутер стоит без всего, ни cdrom, ни
клавиатуры и всего остального.. Хочется как-то удаленно делать
резервную копию, чтобы потом не понадобилось с нуля все настраивать на
всякий пожарный.


-- 
С уважением, Алексей

Re: удаленный бэкап

В Чтв, 11/03/2010 в 11:13 +0300, Alex Petrov пишет:
 11 марта 2010 г. 11:06 пользователь DamirX damir.haki...@gmail.com написал:
  В Чтв, 11/03/2010 в 09:57 +0300, Alex Petrov пишет:
  Уважаемые, подскажите, чем и как лучше забэкапить удаленную машину? ну
  на случай обрушения винта к примеру, чтобы потом можно было
  восстановить в короткие сроки. ехать и подрубать cdrom, клавиатуру,
  мышь туда не хочется..
  Насколько коротки, эти короткие сроки?
  А так, вообще: rsnapshot, rdiffbackup, rsync на худой конец...
 
 
 Ну сроки в плане того, чтобы восстановить на свежий винчестер приехать
 туда и поменять его. Ну примерно так.
 
так может лучше просто зеркало?

-- 
DamirX


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268297784.3631.35.ca...@everest.agg

Re: удаленный бэкап

2010-03-11 Пенетрантность Dark_Dimius

Метод извращенца: на соседнем компе за роутером поднять dhcp с раздачей
операционки по tftp.
Если роутер - классическая железка то настроить netboot и в итоге коли-что
shell будет там сразу.

2010/3/11 Alex Petrov plak...@gmail.com

 11 марта 2010 г. 11:12 пользователь Alexey Lobanov
 a.loba...@gctrials.com написал:
  On 11/03/10 09:57, Alex Petrov wrote:
 
  Уважаемые, подскажите, чем и как лучше забэкапить удаленную машину? ну
  на случай обрушения винта к примеру, чтобы потом можно было
  восстановить в короткие сроки.
 
  Mindi/Mondo? Оно заточено именно под создание загружаемого комплекта CD
 для
  автоматического восстановления машины одним движением.
 

 Просто дело в том, что там роутер стоит без всего, ни cdrom, ни
 клавиатуры и всего остального.. Хочется как-то удаленно делать
 резервную копию, чтобы потом не понадобилось с нуля все настраивать на
 всякий пожарный.


 --
 С уважением, Алексей

Re: удаленный бэкап

2010-03-11 Пенетрантность Andrey Rahmatullin

  Уважаемые, подскажите, чем и как лучше забэкапить удаленную машину? ну
  на случай обрушения винта к примеру, чтобы потом можно было
  восстановить в короткие сроки. ехать и подрубать cdrom, клавиатуру,
  мышь туда не хочется..
  Насколько коротки, эти короткие сроки?
  А так, вообще: rsnapshot, rdiffbackup, rsync на худой конец...
 

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

 так может лучше просто зеркало?

зеркало всей машины? да в принципе достаточно было бы раз в месяц
делать копию на всякий случай. Образ к примеру диска. просто tar
спасет?

-- 
С уважением, Алексей

Re: удаленный бэкап

2010-03-11 Пенетрантность AS

11.03.2010 13:48, Alex Petrov пишет:
11 марта 2010 г. 11:12 пользователь Alexey Lobanov
a.loba...@gctrials.com написал:

On 11/03/10 09:57, Alex Petrov wrote:

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

Mindi/Mondo? Оно заточено именно под создание загружаемого комплекта CD для
автоматического восстановления машины одним движением.

Просто дело в том, что там роутер стоит без всего, ни cdrom, ни
клавиатуры и всего остального.. Хочется как-то удаленно делать
резервную копию, чтобы потом не понадобилось с нуля все настраивать на
всякий пожарный.

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

Re: удаленный бэкап

On Thu, Mar 11, 2010 at 11:06:37AM +0300, DamirX wrote:
 А так, вообще: rsnapshot, rdiffbackup, rsync на худой конец...
Я так понял, требуется снапшот всей системы, а все эти копии произвольных
каталогов можно восстанавливать только из минимально рабочей системы.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Подскажите чайнику, жив ли архив рассылки? По ссылке на сайте не
открывается.
у него послеобеденный сон
-- genix in community@


signature.asc
Description: Digital signature

Re: удаленный бэкап

В Чтв, 11/03/2010 в 11:48 +0300, Alex Petrov пишет:
Просто дело в том, что там роутер стоит без всего, ни cdrom, ни
клавиатуры и всего остального.. Хочется как-то удаленно делать
резервную копию, чтобы потом не понадобилось с нуля все настраивать на
всякий пожарный.
Пожары бывают разные...

представим себе такой пожар, при котором сгорел, только НЖМД. От такого
вида пожара хорошо помагают MD массивы.

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

бывает пожар, при котором обрушается ФС или ОС, который в последнее
время у нормальных людей случается всё реже.

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

Так-же критично может быть время восстановления после пожара. В вашем
случае, при натуральном пожаре время восстановления роутера, я думаю, не
слишком важно, главное, чтобы оно не превышало времени восстановления
всего остального. А некоторых может и HA Linux не устраивает.

Выбирай себе проблему по вкусу и борись с ней :-)

--
DamirX

Re: удаленный бэкап

В Чтв, 11/03/2010 в 12:02 +0300, Alex Petrov пишет:
  так может лучше просто зеркало?
 
 зеркало всей машины?
Нет. зеркало - в смысле дисковый массив из двух дисков уровня RAID1

  да в принципе достаточно было бы раз в месяц
 делать копию на всякий случай. Образ к примеру диска. просто tar
 спасет?
смотря от чего. всякий случай это такая вещь... пытаешься от него
защититься, а происходит совершенно другой всякий случай


-- 
DamirX


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268299094.3631.52.ca...@everest.agg

Re: удаленный бэкап

В Чтв, 11/03/2010 в 14:07 +0500, Andrey Rahmatullin пишет:
 On Thu, Mar 11, 2010 at 11:06:37AM +0300, DamirX wrote:
  А так, вообще: rsnapshot, rdiffbackup, rsync на худой конец...
 Я так понял, требуется снапшот всей системы, а все эти копии произвольных
 каталогов можно восстанавливать только из минимально рабочей системы.
Я тоже понял, но позднее.

-- 
DamirX


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268299161.3631.54.ca...@everest.agg

Re: удаленный бэкап

2010-03-11 Пенетрантность Alexey Lobanov

Как я понимаю, в условии задачи не хватает пары условий.

1. Кто будет заниматься восстановлением на месте? Админ с отвёрткой,
девушка-бухгалтер, виндовый эникейщик?

2. От каких типов аварий хотим защититься? Порча конфигов, физическая
смерть диска, кража?

По поводу первого вопроса. Например, в нескольких серверах, до которых
мне добраться совсем сложно (i.e., город Тбилиси) стоят два винчестера в
съёмных треях. Один рабочий, второй - с зеркалом. Зеркалирование
запускается не автоматически, а ручками, после удачно оттестированных
изменений. После копирования запасной винчестер размонтируем, и шпиндель
останавливаем - чтобы минимизировать вероятность порчи при любой аварии.
Ну и местный сотрудник в состоянии по звонку поменять винчестеры
местами. Уже несколько раз спасало.

А упомянутая mindi/mondo вроде как позволяет сделать загружаемую флешку
вместо CD. Вставить флешку, переданную курьером или почтой, может и
бухгалтер.

А.Л.

Re: удаленный бэкап

11 марта 2010 г. 12:19 пользователь Alexey Lobanov
a.loba...@gctrials.com написал:
 Как я понимаю, в условии задачи не хватает пары условий.

 1. Кто будет заниматься восстановлением на месте? Админ с отвёрткой,
 девушка-бухгалтер, виндовый эникейщик?

 2. От каких типов аварий хотим защититься? Порча конфигов, физическая смерть
 диска, кража?


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


-- 
С уважением, Алексей

Re: удаленный бэкап

2010-03-11 Пенетрантность Andrey Lyubimets

В Чтв, 11/03/2010 в 12:19 +0300, Alexey Lobanov пишет:
 Один рабочий, второй - с зеркалом. Зеркалирование 
 запускается не автоматически, а ручками, после удачно оттестированных 
 изменений. После копирования запасной винчестер размонтируем, и шпиндель 
 останавливаем - чтобы минимизировать вероятность порчи при любой аварии. 
О! интересно. Это сделано средствами md или как-то по другому?

-- 
DamirX


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268301761.3631.56.ca...@everest.agg

Re: удаленный бэкап

2010-03-11 Пенетрантность Alexey Lobanov

On 11/03/10 13:02, DamirX wrote:

В Чтв, 11/03/2010 в 12:19 +0300, Alexey Lobanov пишет:
Один рабочий, второй - с зеркалом. Зеркалирование
запускается не автоматически, а ручками, после удачно оттестированных
изменений. После копирования запасной винчестер размонтируем, и шпиндель
останавливаем - чтобы минимизировать вероятность порчи при любой аварии.

О! интересно. Это сделано средствами md или как-то по другому?

Любой md категорически не защищает от программных и рукодельных аварий.
Если рухнула файловая система, или сделана ошибка в
/etc/network/interfaces, то raid быстро и эффективно воспроизведёт беду
на обоих дисках. И опаньки. Мне ведь не нужна высокая
отказоустойчивость, не нужна работа без сбоя при аварии диска. Нужно
только надёжное восстановление в разумные сроки без поездки
квалифицированного сотрудника.

Поэтому тривиальный скрипт с rsync'ом внутри. И отдельный конфиг lilo,
чтобы резервный диск загрузился после обмена местами. Ключевые слова
примерно такие:

boot=/dev/sdb
root=/dev/sda2
disk=/dev/sdb
bios=0x80
map=/mnt/boot/map
image=/mnt/boot/vmlinuz-2.6

А.Л.

Re: удаленный бэкап

Alex Petrov пишет:
11 марта 2010 г. 11:06 пользователь DamirX damir.haki...@gmail.com
написал:

В Чтв, 11/03/2010 в 09:57 +0300, Alex Petrov пишет:

Уважаемые, подскажите, чем и как лучше забэкапить удаленную машину? ну
на случай обрушения винта к примеру, чтобы потом можно было
восстановить в короткие сроки. ехать и подрубать cdrom, клавиатуру,
мышь туда не хочется..
Насколько коротки, эти короткие сроки? А так, вообще: rsnapshot,
rdiffbackup, rsync на худой конец...

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

Если последовательность действий именно такая -
восстановить-поехать-поменять, то любое из вышеперечисленного, имхо, подойдёт.
Перед восстановить: на свежий винчестер делаешь установку базовой системы
(или восстанавливаешь её из дампа, могут быть и другие варианты)
и устанавливаешь тот же набор пакетов, что был на твоём роутере
(http://www.debian.org/doc/manuals/reference/ch02.en.html#_recording_and_copying_system_configuration)

естественно, вывод
# dpkg --get-selections '*' selection.dpkg
# debconf-get-selections selection.debconf
должен быть в твоих бэкапах ;-)

--
С уважением, Любимец Андрей Алексеевич

Re: удаленный бэкап