Re: Backup
artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:36:37 +0300:
>> >> >> >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> >> >> >>> выбранные пользовательские данные.
>> >> >> >>
>> >> >> >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>> >> >> >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>> >> >> >> восстановления не разбираться если версии конфигурации в /etc остались
>> >> >> >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>> >> >> >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>> >> >> > Как минимум, две машины (плюс, ещё /opt).
>> >> >> > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>> >> >> > для Oracle Java на рабочей машине).
>> >> >> > /var ещё надо бэкапить. Но /usr для чего?
>> >> >>
>> >> >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
>> >> >> чистый диск не получится. Придется ставить систему и накатывать
>> >> >> конфиги. И тут упс... система оказалась поновее, конфиги частично
>> >> >> несовместимы...
>> >> >>
>> >> > Это не столь серьёзная проблема в моём случае: как правило, система
>> >> > более ли менее новая.
>> >>
>> >> Ключевые слова - "более или менее" :)
>> > Ok, система достаточно новая. Максимум - месяц без обновлений (это
>> > означает, что она не включалась, потому вероятность выхода из строя
>> > низка), и как правило, в таком случае я могу себе позволить затратить
>> > время на её восстановление. Больше - крайне редкие случаи.
>>
>> Бэкап, с которого восстанавливаемся, может оказаться не офигительно
>> свежим. Потом, легко забыть забэкапить что-нибудь важное из
>> /usr/local...
>>
> Если что-то установленное туда я долго не использую, значит оно мне не
> так и нужно.
У меня там бывают (в /usr/local/sbin) скрипты, которые использую не я, а, например, cron...
>> >> >> >> В общем, анализировать бэкапные решения надо начинать не с "где
>> >> >> >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>> >> >> >> процедура восстановления". Причем в двух вариантах
>> >> >> >>
>> >> >> > Да, вообще явного анализа восстановления я не провёл.
>> >> >> > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
>> >> >> > данные, а не образ.
>> >> >> > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
>> >> >> > машин.
>> >> >>
>> >> >> Практика восстановления показывает, что если бэкапятся настройки
>> >> >> системы, то лучше бэкапить всю систему. Восстановление работоспособного
>> >> >> состояния получится на порядок быстрее. Пользовательские данные можно (и
>> >> >> часто полезно) бэкапить отдельно.
>> >> >>
>> >> > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
>> >> > Мало того, не всегда мне нужно будет восстанавливать ту же самую
>> >> > систему: на том же железе и в точности с той же конфигурацией, плюс к
>> >> > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
>> >> > Падение скорости восстановления здесь для меня терпимо.
>> >>
>> >> Системы обычно падают в самый неподходящий момент :) И даже если ты
>> >> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
>> >> прежнюю работоспособную конфигурацию, а потом уже обновлять.
>> >>
>> > Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже
>> > кем-то решённых).
>> > Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
>> > (пусть и маленькую).
>>
>> > Отсюда:
>>
>> > - Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
>> > года не переустанавливалась, редко выключалась, кроме последних лет, и
>> > долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
>> > заботливо сохранена, и воспроизведётся при каждом полном восстановлении.
>>
>> Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только
>> конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
>> быстро восстановиться, если есть бэкап только конфигов, не получится.
>>
> В случае же переустановки, из бэкапа ничего не прилетит.
Очень не факт. Зараза с легкостью может окопаться и в /etc (в случае
винды - системном реестре).
>> Ну и думай, что дороже: дополнительное дисковое пространство для
>> хранения бэкапа системы, или твои время и нервы на более сложную
>> процедуру восстановления.
>>
> С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
> пространства хранилища, какие-то 50 Гб на машину странно.
> С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
> накатил свежую ОС, накатил конфигурацию и пакеты, всё.
Твоих телодвижений больше. "Накатил свежую ОС" - это существенно больше
одной команды, и внимания оно хочет не единым куском, а урывками.
>> > - В этой старой системе я хочу многое переделать, например дисковую
>> > организацию, что потребует переустановки при сохранении большинства
>> > конфигов.
>>
>> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
>> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
>> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
>> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
>>
> Там много что надо поменять.
В моей практике это все же обычно лучше делать по одному блоку
функциональности за раз.
> Плюс, лишних пакетов море скопилось, со старых версий (это ещё
> squeeze) что-то определённо тянется.
dpkg -l, и вдумчиво apt-get remove --purge. Это проще, чем наоборот.
>> >> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
>> >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
>> >> и набор пакетов привел меня к выводу, что потребуется специальный
>> >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
>> >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
>> >> виртуалки с виндой.
>> >>
>> > А форки, которые здесь рекламируют?
>> > http://www.urbackup.org/
>> > https://time404.ru/1776/
>>
>> А можно я не буду на них смотреть? Но по идее, если форк, тем более
>> более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд
>> ли система с тех пор стала сильно проще...
>>
> UrBackup - не форк, а отдельный инструмент.
Anyway, можно я не буду на них смотреть? У _меня_ сейчас эта задача не
стоит.
>> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я
>> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
>> >> раз - только потому, что у меня был еще и свой бэкап.
>> >>
>> > Но ведь система специально заточена под бэкап, долго живёт и развивается.
>> > Почему не было успешно её применение?
>> > Возможно ли, что это просто было неправильное использование?
>>
>> Да. Вопрос в том, кому по карману правильное. Может быть, хостинг-провайдеру.
>>
> В таком случае, по каким причинам они выбирают Bacula-like?
Не могу дать гарантированного ответа, но вероятно, купившись на
рекламные слова. Иногда еще, чтобы было чем оправдываться перед
начальством за продолбы. Типа, "мы использовали проверенный бэкапный
софт, и не виноваты, что не смогли восстановить требуемое". Если тот же
самый продолб (он обычно организационного характера) произойдет с
велосипедным решением, оправдываться будет сложнее.
Reply to: