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? Не могу дать гарантированного ответа, но вероятно, купившись на рекламные слова. Иногда еще, чтобы было чем оправдываться перед начальством за продолбы. Типа, "мы использовали проверенный бэкапный софт, и не виноваты, что не смогли восстановить требуемое". Если тот же самый продолб (он обычно организационного характера) произойдет с велосипедным решением, оправдываться будет сложнее.
