> From: Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> > Date: Mon, 27 Jun 2016 20:50:09 +0300 > > VD>>> О, боже, насколько же dump до-о-о-ольше dd! > >>>Очень сильно зависит от количества файлов, может быть и наоборот. > VD>> Разумеется, диск забит более чем наполовину, иначе зачем переносить-то. > >>dump используется не только для переноса, но и для бекапов же. > > VD> Для write-only бэкапов. > >Периодически пользуюсь, хоть и не сказать, что регулярно. Проблем нет. > > VD> Ибо чтобы воспользоваться таким бэкапом (для > VD> тривиальных задач вроде восстановления когда-то случайно стёртых, а > VD> сейчас внезапно понадобившихся документов), приходится затевать процедуру > VD> restore, > >Элементарную процедуру. > > VD> причём даже просто для того, чтобы выяснить, имеются ли вообще в > VD> этом дампе искомые документы. > >Какие-то проблемы это выяснить при помощи restore?
Да так, пустяк - время. А больше никаких.
> VD>> Да и количество файлов во всяких ports и src (вместе с ихними .svn), > VD>> плюс юзерские сайты и maildirы - весьма заметное. > >>То есть ты пошел по стопам AK - взял свой частный случай и заявил > >>о нём как об общем. > VD> Более того, я взял один конкретный случай. Который устроил по вашей > VD> наводке вместо своего любимого dd-fsck-rsync. Этот dump настолько > VD> нагрузил систему, что клиенты с большим дисковым трафиком (почтовые) > VD> стали отваливаться по таймауту. > >У тебя дисковая подсистема работает на пределе, раз dump приводит аж к >таймаутам.
Это она с дампом работает на пределе (локальная сеть гигабитная) а с почтовыми клиентами (они через 100-мегабитный канал ходят) всё как было тому назад 10 лет нормально, так и посейчас.
> VD> Да и в момент переключения пришлось > >Что за "переключение"?
Промежуток между выключением старого сервера и включением новой копии.
