> >> >> >> >> В общем, анализировать бэкапные решения надо начинать не с > "где > >> >> >> >> хранить" и "какой транспорт использовать" а с "как будет > выглядеть > >> >> >> >> процедура восстановления". Причем в двух вариантах > >> >> >> >> > >> >> >> > Да, вообще явного анализа восстановления я не провёл. > >> >> >> > Неявно, подразумеваю, что буду переустанавливать систему и > накатывать > >> >> >> > данные, а не образ. > >> >> >> > Т.е., мне не требуется "полный бэкап", как это делают с > большим парком > >> >> >> > машин. > >> >> >> > >> >> >> Практика восстановления показывает, что если бэкапятся настройки > >> >> >> системы, то лучше бэкапить всю систему. Восстановление > работоспособного > >> >> >> состояния получится на порядок быстрее. Пользовательские данные > можно (и > >> >> >> часто полезно) бэкапить отдельно. > >> >> >> > >> >> > Хорошо, но зачем мне 50+ Гб того, что я и так получу? > >> >> > Мало того, не всегда мне нужно будет восстанавливать ту же самую > >> >> > систему: на том же железе и в точности с той же конфигурацией, > плюс к > >> >> > этому, у меня ещё не было ни одного случая, чтобы полностью > загнулся Debian. > >> >> > Падение скорости восстановления здесь для меня терпимо. > >> >> > >> >> Системы обычно падают в самый неподходящий момент :) И даже если ты > >> >> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить > >> >> прежнюю работоспособную конфигурацию, а потом уже обновлять. > >> >> > >> > Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже > >> > кем-то решённых). > >> > Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру" > >> > (пусть и маленькую). > >> > >> > Отсюда: > >> > >> > - Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го > >> > года не переустанавливалась, редко выключалась, кроме последних лет, и > >> > долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет > >> > заботливо сохранена, и воспроизведётся при каждом полном > восстановлении. > >> > >> Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только > >> конфиги из полного бэкапа можно. А вот взять полную систему, чтобы > >> быстро восстановиться, если есть бэкап только конфигов, не получится. > >> > > В случае же переустановки, из бэкапа ничего не прилетит. > > Очень не факт. Зараза с легкостью может окопаться и в /etc (в случае > винды - системном реестре). > Но в /etc бинарник же будет видно, а в случае системного реестра, ей всё равно файл нужен, который будет запускаться, разве нет?
> >> Ну и думай, что дороже: дополнительное дисковое пространство для > >> хранения бэкапа системы, или твои время и нервы на более сложную > >> процедуру восстановления. > >> > > С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом > > пространства хранилища, какие-то 50 Гб на машину странно. > > С другой, я не вижу, чтобы реально усложнилась процедура восстановления: > > накатил свежую ОС, накатил конфигурацию и пакеты, всё. > > Твоих телодвижений больше. "Накатил свежую ОС" - это существенно больше > одной команды, и внимания оно хочет не единым куском, а урывками. > В общем, мне надо подумать над этим вопросом. Пока однозначного решения, как сделать, я принять не могу. У обоих подходов есть плюсы и минусы. > >> > - В этой старой системе я хочу многое переделать, например дисковую > >> > организацию, что потребует переустановки при сохранении большинства > >> > конфигов. > >> > >> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап, > >> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще > >> перегенерировал initrd из чрута до первой перезагрузки, если в разметке > >> добавилось что-то новое, драйвера чего в старом initrd отсутствовали. > >> > > Там много что надо поменять. > > В моей практике это все же обычно лучше делать по одному блоку > функциональности за раз. >> > Плюс, лишних пакетов море скопилось, со старых версий (это ещё > > squeeze) что-то определённо тянется. > > dpkg -l, и вдумчиво apt-get remove --purge. Это проще, чем наоборот. > В любом случае, это уже отдельный вопрос: до того, как с основными задачами NAS разберусь, я этим заниматься не буду. > >> >> Когда я в свое время разрабатывал регламент бэкапов для своей > конторы, я > >> >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию > бакулы > >> >> и набор пакетов привел меня к выводу, что потребуется специальный > >> >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе > >> >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и > >> >> виртуалки с виндой. > >> >> > >> > А форки, которые здесь рекламируют? > >> > http://www.urbackup.org/ > >> > https://time404.ru/1776/ > >> > >> А можно я не буду на них смотреть? Но по идее, если форк, тем более > >> более поздний (я смотрел-то на нее в последний раз лет 10 как), то вряд > >> ли система с тех пор стала сильно проще... > >> > > UrBackup - не форк, а отдельный инструмент. > > Anyway, можно я не буду на них смотреть? У _меня_ сейчас эта задача не > стоит. > Так вы же тут добровольно отвечаете (я надеюсь), что спрашивать-то? Другое дело, что не tar-ом единым. Есть инструмент, о котором в целом, положительные отзывы, который легко интегрируется во FreeNAS, по списку фич удовлетворят моим потребностям: зачем же мне делать на rsync и подпиливать всякие WEB-интерфейсы самостоятельно (пусть, даже разбираться с тем же BackupPC)? > >> >> Ну, то есть, конторы, где эти или подобные технологии применялись, я > >> >> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один > >> >> раз - только потому, что у меня был еще и свой бэкап. > >> >> > >> > Но ведь система специально заточена под бэкап, долго живёт и > развивается. > >> > Почему не было успешно её применение? > >> > Возможно ли, что это просто было неправильное использование? > >> > >> Да. Вопрос в том, кому по карману правильное. Может быть, > хостинг-провайдеру. > >> > > В таком случае, по каким причинам они выбирают Bacula-like? > > Не могу дать гарантированного ответа, но вероятно, купившись на > рекламные слова. Иногда еще, чтобы было чем оправдываться перед > начальством за продолбы. Типа, "мы использовали проверенный бэкапный > софт, и не виноваты, что не смогли восстановить требуемое". Если тот же > самый продолб (он обычно организационного характера) произойдет с > велосипедным решением, оправдываться будет сложнее. > Разве это единственная причина?
