Re: Backup

[artiom <artiom14@yandex.ru>]

>  >>  >>  >> - NextCloud
>  >>  >>  > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>  >>  >>  > почему называется "облаком", легко ли его интегрировать с той же Bacula
>  >>  >>  > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>  >>  >>  > использовать в составе NAS.
>  >>  >> 
>  >>  >>  >> - SyncThing
>  >>  >>  > Сам уже нашёл.
>  >>  >>  > Хотелось бы о нём услышать отзывы использующих.
>  >>  >>  > По мне: весьма интересная штука.
>  >>  >> 
>  >>  >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>  >>  >> 
>  >>  > По каким причинам?
>  >>  > Тут бы неплохо прояснить разницу.
>  >>  > Если из бэкапа требуется доставать отдельные файлы, то границу мне
>  >>  > сложно провести.
>  >> 
>  >> Синхронизатор не отличает намеренное удаление или порчу от
>  >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>  >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>  >> засинхронизироваться.
>  >> 
>  > Как отличает система резервного копирования?
>  > Или тоже не отличает, но это компенсируется историей бэкапов?
> 
> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
> удаляется целиком, либо (если ему повезло оказаться, например, годичным)
> хранится "вечно".
> 
А какова частота полного, декремента и инкремента?

>  >>  >> Инкрементальный бэкап, который обеспечивает tar и основные
>  >>  >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>  >>  >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>  >>  >> как у rsync, второе и третье ценой невозможности первого. Первое и
>  >>  >> третье можно делать, гоняя каждый раз полный бэкап.
>  >>  >>
>  >>  > Вы не вполне верно поняли требование, либо я не точно выразился.
>  >>  > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>  >>  > (облако).
>  >>  > Шифровать отдельно при хранении в NAS, не требуется.
>  >> 
>  >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>  >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>  >> разные технологии бэкапа :)
>  >> 
>  > Да, конечно, так и планировалось изначально.
> 
> Минус простота настройки.
> 
В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.

>  >>  >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>  >>  >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>  >>  >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>  >>  >> раз в некоторое время гонят полный бэкап, а между ними
>  >>  >> инкрементальный. tar вот даже различает дифференциальный (разница с
>  >>  >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>  >>  >> ни был). Для разумного времени восстановления характерная частота
>  >>  >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>  >>  >> ежедневно. В результате получается дорого, но не невменяемо дорого.
>  >>  >> 
>  >>  > Любопытно, на основе инструментов, которые тут советовали, возможно это
>  >>  > построить не сильно напрягаясь?
>  >> 
>  >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
>  >> не позволяет, его нужно выкинуть и посмотреть на другой.
>  >> 
>  > Согласен.
>  > Пока не вполне понятно, что из этого выкинуть.
>  > Кроме Bacula, но тут хвалят её форки.
> 
>  >> На глазок, при использовании собственно tar, gpg и любого способа
>  >> копирования такая конструкция собирается за неделю, включая написание
>  >> регламента. Но трафика будет изрядно.
>  >> 
>  > И не вполне портируемо.
> 
> Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на
> винде не будут забэкаплены открытые в данный момент файлы.
> 
Всё-таки, не вижу пока чем хуже urbackup: агенты уже реализованы и
отлажены, web-интерфейс есть, по фичам всё нормально и статей о нём нет
типа "О том, как я неделю вдуплял в BareOS".

>  >>  >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>  >>  >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>  >>  >> при работе в архиве, но все же изрядная.
>  >>  > Она мне, в принципе, требуется.
>  >>  > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>  >>  > (сейчас закончил только с музыкой и видео, проекты в нормальном
>  >>  > состоянии, книги и документы в процессе сортировки).
>  >>  > Поэтому, что бэкапить, я могу сказать.
>  >> 
>  >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>  >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>  >> 
>  > Ну ok, политика и регламент бэкапа?
>  > Если делать на серьёзном уровне, конечно полезно.
>  > В принципе, это в любом случае полезно, так что пока ещё NAS не
>  > завершён, в рамках этого проекта возможно и системой резервного
>  > копирования более серьёзно заняться.
> 
> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
> касающейся его части.
> 
Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все
слышали такое понятие, как "регламент бэкапа". Кое-что пользователю
знать не нужно.

>  >>  >> "Результатом автоматизации
>  >>  >> бардака может быть только автоматизированный бардак." В нее, в
>  >>  >> частности, входит периодическая тренировка восстановления из
>  >>  >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
>  >>  >> получится восстановиться.
>  >>  >> 
>  >>  > С проведением таких "учений" всё сложнее: как восстанавливать машину, на
>  >>  > которой постоянно работаешь (в любом случае, восстановление - потеря
>  >>  > времени)?
>  >> 
>  >> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
>  >> делаешь, либо у тебя очень невысокие шансы, что ты сможешь
>  >> восстановиться в случае проблем.
>  >> 
>  >> Вероятность того, что при первой попытке восстановления проблемы
>  >> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
>  >> все же заметно больше нуля, и чем сложнее инфраструктура хранения
>  >> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
>  >> аргумент в пользу решений на базе rsync, у которых на выходе такое же
>  >> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
>  >> лучше, чтобы первые несколько тревог были учебными.
>  >> 
>  > Хорошо, тогда касательно rsync: как делать дифференциальный и
>  > инкрементальный бэкап?
> 
> У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап,
> и потом rsync -a --delete в будущий_бэкап.
> 
А про упомянутый тут restic можете что-то сказать?

> Если бэкапится юниксовая машина, то вся конструкция без особых
> сложностей скриптуется с сервера, который и следит за расписанием. С
> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
> -al" и по расписанию пинал по почте владельца машины. А часть rsync
> запускает уже владелец машины.
> 
Как понять "скриптуется с сервера"?

>  > Касательно проверок: как это делается?
>  > На практике, там где это было, как проводится такая проверка в
>  > существующей инфраструктуре?
> 
> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
> диском (обычно виртуалка, но по возможности иногда и на железе стоит
> прогнать), и на нее выполняется регламент восстановления. Если не
> сработал - все бросаем, чиним, корректируем регламент.
> 
> Если речь идет о восстановлении пользовательских данных, а не всей
> системы, то машина берется не пустая, а с установленной ОС. В этом
> случае регламент восстановления должен включать установку необходимого
> софта поверх базовой установки ОС (буде он нужен), если он еще не
> установлен. Это тоже надо проверять, а то разное может получиться.
> 
В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
основной инфраструктуры ради проверки восстановления не прерывается.