Re: Backup

[artiom <artiom14@yandex.ru>]

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