[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backup



>  >>  >>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>  >>  >>  >>> выбранные пользовательские данные.
>  >>  >>  >> 
>  >>  >>  >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>  >>  >>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>  >>  >>  >> восстановления не разбираться если версии конфигурации в /etc остались
>  >>  >>  >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>  >>  >>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>  >>  >>  > Как минимум, две машины (плюс, ещё /opt).
>  >>  >>  > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>  >>  >>  > для Oracle Java на рабочей машине).
>  >>  >>  > /var ещё надо бэкапить. Но /usr для чего?
>  >>  >> 
>  >>  >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
>  >>  >> чистый диск не получится. Придется ставить систему и накатывать
>  >>  >> конфиги. И тут упс... система оказалась поновее, конфиги частично
>  >>  >> несовместимы...
>  >>  >> 
>  >>  > Это не столь серьёзная проблема в моём случае: как правило, система
>  >>  > более ли менее новая.
>  >> 
>  >> Ключевые слова - "более или менее" :)
>  > Ok, система достаточно новая. Максимум - месяц без обновлений (это
>  > означает, что она не включалась, потому вероятность выхода из строя
>  > низка), и как правило, в таком случае я могу себе позволить затратить
>  > время на её восстановление. Больше - крайне редкие случаи.
> 
> Бэкап, с которого восстанавливаемся, может оказаться не офигительно
> свежим. Потом, легко забыть забэкапить что-нибудь важное из
> /usr/local...
> 
Если что-то установленное туда я долго не использую, значит оно мне не
так и нужно.

>  >>  >>  >> В общем, анализировать бэкапные решения надо начинать не с "где
>  >>  >>  >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>  >>  >>  >> процедура восстановления". Причем в двух вариантах 
>  >>  >>  >>
>  >>  >>  > Да, вообще явного анализа восстановления я не провёл.
>  >>  >>  > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
>  >>  >>  > данные, а не образ.
>  >>  >>  > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
>  >>  >>  > машин.
>  >>  >> 
>  >>  >> Практика восстановления показывает, что если бэкапятся настройки
>  >>  >> системы, то лучше бэкапить всю систему. Восстановление работоспособного
>  >>  >> состояния получится на порядок быстрее. Пользовательские данные можно (и
>  >>  >> часто полезно) бэкапить отдельно.
>  >>  >> 
>  >>  > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
>  >>  > Мало того, не всегда мне нужно будет восстанавливать ту же самую
>  >>  > систему: на том же железе и в точности с той же конфигурацией, плюс к
>  >>  > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
>  >>  > Падение скорости восстановления здесь для меня терпимо.
>  >> 
>  >> Системы обычно падают в самый неподходящий момент :) И даже если ты
>  >> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
>  >> прежнюю работоспособную конфигурацию, а потом уже обновлять.
>  >> 
>  > Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже
>  > кем-то решённых).
>  > Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
>  > (пусть и маленькую).
> 
>  > Отсюда:
> 
>  > - Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
>  > года не переустанавливалась, редко выключалась, кроме последних лет, и
>  > долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
>  > заботливо сохранена, и воспроизведётся при каждом полном восстановлении.
> 
> Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только
> конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
> быстро восстановиться, если есть бэкап только конфигов, не получится.
> 
В случае же переустановки, из бэкапа ничего не прилетит.
Возможно, конечно, бороться "антивирусными" мерами...

> Ну и думай, что дороже: дополнительное дисковое пространство для
> хранения бэкапа системы, или твои время и нервы на более сложную
> процедуру восстановления.
> 
С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
пространства хранилища, какие-то 50 Гб на машину странно.
С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
накатил свежую ОС, накатил конфигурацию и пакеты, всё.
Кроме того,

>  > - В этой старой системе я хочу многое переделать, например дисковую
>  > организацию, что потребует переустановки при сохранении большинства
>  > конфигов.
> 
> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
> 
Там много что надо поменять. Плюс, лишних пакетов море скопилось, со
старых версий (это ещё squeeze) что-то определённо тянется. Но там пока
до обновления или переустановки далеко, я ещё не решил, как буду делать.

>  >>  >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
>  >>  >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
>  >>  >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
>  >>  >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
>  >>  >> квалификацией админа и наличием _регулярно_ времени на эту работу.
>  >>  >> 
>  >>  > Насколько регулярно и насколько велик объём донастройки?
>  >> 
>  >> Мне пока не доводилось работать в таком месте, где работодатель считал
>  >> бы, что это ему по карману :)
>  >> 
>  > Если я делаю для себя, читается, как: "Ты не будешь этим заниматься"?
> 
> Скорее всего, да. У тебя же есть и другие занятия, а ты у себя один. И
> кушать хочешь три раза в день, вероятно.
> 
Ok, понял. Некоторый обзор уже показывает, что BareOS - сомнительный
вариант. Сложен и запутан.

>  >> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
>  >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
>  >> и набор пакетов привел меня к выводу, что потребуется специальный
>  >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
>  >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
>  >> виртуалки с виндой.
>  >> 
>  > А форки, которые здесь рекламируют?
>  > http://www.urbackup.org/
>  > https://time404.ru/1776/
> 
> А можно я не буду на них смотреть? Но по идее, если форк, тем более
> более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
> ли система с тех пор стала сильно проще...
> 
UrBackup - не форк, а отдельный инструмент.

>  >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>  >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>  >> раз - только потому, что у меня был еще и свой бэкап.
>  >> 
>  > Но ведь система специально заточена под бэкап, долго живёт и развивается.
>  > Почему не было успешно её применение?
>  > Возможно ли, что это просто было неправильное использование?
> 
> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
> 
В таком случае, по каким причинам они выбирают Bacula-like?


Reply to: