Re: Backup
artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:15:25 +0300:
>> >> Синхронизатор не отличает намеренное удаление или порчу от
>> >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>> >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>> >> засинхронизироваться.
>> >>
>> > Как отличает система резервного копирования?
>> > Или тоже не отличает, но это компенсируется историей бэкапов?
>>
>> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
>> удаляется целиком, либо (если ему повезло оказаться, например, годичным)
>> хранится "вечно".
>>
> А какова частота полного, декремента и инкремента?
Зависит от характера изменения данных. На работе бэкап делался ежедневно
- восстанавливать работу всей конторы за неделю было сложно, поскольку
задач много, и за неделю тупо успеваешь забыть, что делал, не то что
как. Дома делается раз в неделю. Это, если применяются инкрементные,
частота инкрементных (у меня довольно давно применяются
обратно-инкрементные, там бэкап бывает только одного типа).
Если же говорить о декрементных и полных, то тут вопрос баланса трафика
туда и времени восстановления. Я бы сказал, что полные следует делать
настолько часто, насколько позволяет жаба по трафику. Деление на
декремент и инкремент проводить скорее из соображений "больше десятка
инкрементов за одну операцию восстановления не офигеть как удобно
накатывать". В man tar приводился для прикидки вариант "полные раз в
месяц, декременты раз в неделю, инкременты раз в день". Тогда при
восстановлении накатывается один полный, один декремент (он по
определению один) и не больше 6 инкрементов.
>> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >> >>
>> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> >> > (облако).
>> >> > Шифровать отдельно при хранении в NAS, не требуется.
>> >>
>> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> >> разные технологии бэкапа :)
>> >>
>> > Да, конечно, так и планировалось изначально.
>>
>> Минус простота настройки.
>>
> В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
В изначальной постановке задачи простота настройки была одним из условий :)
>> >> >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>> >> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>> >> >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>> >> >> раз в некоторое время гонят полный бэкап, а между ними
>> >> >> инкрементальный. tar вот даже различает дифференциальный (разница с
>> >> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>> >> >> ни был). Для разумного времени восстановления характерная частота
>> >> >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>> >> >> ежедневно. В результате получается дорого, но не невменяемо дорого.
>> >> >>
>> >> > Любопытно, на основе инструментов, которые тут советовали, возможно это
>> >> > построить не сильно напрягаясь?
>> >>
>> >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
>> >> не позволяет, его нужно выкинуть и посмотреть на другой.
>> >>
>> > Согласен.
>> > Пока не вполне понятно, что из этого выкинуть.
>> > Кроме Bacula, но тут хвалят её форки.
>>
>> >> На глазок, при использовании собственно tar, gpg и любого способа
>> >> копирования такая конструкция собирается за неделю, включая написание
>> >> регламента. Но трафика будет изрядно.
>> >>
>> > И не вполне портируемо.
>>
>> Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на
>> винде не будут забэкаплены открытые в данный момент файлы.
>>
> Всё-таки, не вижу пока чем хуже urbackup: агенты уже реализованы и
> отлажены, web-интерфейс есть, по фичам всё нормально и статей о нём нет
> типа "О том, как я неделю вдуплял в BareOS".
Я не имею цели отвратить тебя от urbackup. Которого я в глаза не видел.
>> >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> >> >> при работе в архиве, но все же изрядная.
>> >> > Она мне, в принципе, требуется.
>> >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>> >> > (сейчас закончил только с музыкой и видео, проекты в нормальном
>> >> > состоянии, книги и документы в процессе сортировки).
>> >> > Поэтому, что бэкапить, я могу сказать.
>> >>
>> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>> >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>> >>
>> > Ну ok, политика и регламент бэкапа?
>> > Если делать на серьёзном уровне, конечно полезно.
>> > В принципе, это в любом случае полезно, так что пока ещё NAS не
>> > завершён, в рамках этого проекта возможно и системой резервного
>> > копирования более серьёзно заняться.
>>
>> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
>> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
>> касающейся его части.
>>
> Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все
> слышали такое понятие, как "регламент бэкапа". Кое-что пользователю
> знать не нужно.
А есть разные регламенты. Для админа, настраивающего бэкап, для админа,
следящего за бэкапами, и для пользователя, желающего, чтобы его данные
и/или систему в случае сбоев можно было восстановить.
Мне не попадалось ситуаций, где бы все данные, ценные для пользователя,
удавалось отследить и забэкапить без его осознанного участия. Кроме
конструкций с бездисковыми X-терминалами в конце 90-х - начале 2000-х,
когда все данные, а зачастую и ОС терминала хранились на одном сервере и
только на нем. Повторюсь,
>> >> >> "Результатом автоматизации
>> >> >> бардака может быть только автоматизированный бардак."
>> > Хорошо, тогда касательно rsync: как делать дифференциальный и
>> > инкрементальный бэкап?
>>
>> У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап,
>> и потом rsync -a --delete в будущий_бэкап.
>>
> А про упомянутый тут restic можете что-то сказать?
Не могу.
>> Если бэкапится юниксовая машина, то вся конструкция без особых
>> сложностей скриптуется с сервера, который и следит за расписанием. С
>> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
>> -al" и по расписанию пинал по почте владельца машины. А часть rsync
>> запускает уже владелец машины.
>>
> Как понять "скриптуется с сервера"?
Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую
мы бэкапим) с точки зрения rsync является сервером.
>> > Касательно проверок: как это делается?
>> > На практике, там где это было, как проводится такая проверка в
>> > существующей инфраструктуре?
>>
>> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
>> диском (обычно виртуалка, но по возможности иногда и на железе стоит
>> прогнать), и на нее выполняется регламент восстановления. Если не
>> сработал - все бросаем, чиним, корректируем регламент.
>>
>> Если речь идет о восстановлении пользовательских данных, а не всей
>> системы, то машина берется не пустая, а с установленной ОС. В этом
>> случае регламент восстановления должен включать установку необходимого
>> софта поверх базовой установки ОС (буде он нужен), если он еще не
>> установлен. Это тоже надо проверять, а то разное может получиться.
>>
> В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
> основной инфраструктуры ради проверки восстановления не прерывается.
Вообще говоря, возможны ситуации, когда приходится прерывать. Потому что
оценить результат восстановления можно только протестировав, что все
документированные функции целевой машины работают. А у нее могут быть
сетевые сервисы, которые надо проверить по тому самому имени. Для чего
"учебная" машина должна подменить в сети "боевую".
Тут можно в разных местах проводить границу, и получать разную степень
уверенности в результате. Если, скажем, восстанавливается какой-нибудь
трекер (веб-морда плюс база плюс почта), то можно в регламент
восстановления включить часть "для учебной тревоги", где расписать
перенастройку на тестовое имя хоста и на тестовый вариант рассылки по
почте (что утраивает работу по написанию регламента и в полтора-два раза
увеличивает работу по учебной тревоге). Но, скажем, проверить
работоспособность восстановленного домен-контроллера виндовой сети без
замены им настоящего я бы вот так вот сходу не взялся, так что надо
приходить ночью, когда никого нет, и выключать настоящий.
Reply to: