Re: Backup
artiom -> debian-russian@lists.debian.org @ Sat, 17 Feb 2018 11:16:16 +0300:
>> >> >> - git-annex - то, что и можно предположить: костыль над гитом.
>> >> > `Git's man page calls it "a stupid content tracker". With git-annex, git
>> >> > is instead "a stupid filename and metadata" tracker. The contents of
>> >> > annexed files are not stored in git, only the names of the files and
>> >> > some other metadata remain there.`
>> >>
>> >> > Насколько проще с этим будет работать, чем с Bacula?
>> >> > Насколько переносимо и отлажено?
>> >> > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
>> >> > пока не ясно (к примеру, централизованного управления и интеграции в
>> >> > web-интерфейс там, пожалуй, нет).
>> >>
>> >> Не путаем бэкап с архивом. Для бэкапа не годится.
>> >>
>> > По каким причинам?
>>
>> Требует архивной дисциплины. Я использовал его, ага.
>>
> git-annex?
Да. Архивные, т.е. _не изменяющиеся_, здоровенные бинарники, с
отслеживанием, где и сколько их копий, и комментированием, где что за
хрень. Он придуман для этой задачи, и ее выполняет хорошо.
Потом как-то продолбал дисциплину архивной работы, и теперь уже поди
найди хотя бы один репозиторий, где вся эта информация...
>> >> >> - NextCloud
>> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>> >> > почему называется "облаком", легко ли его интегрировать с той же Bacula
>> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>> >> > использовать в составе NAS.
>> >>
>> >> >> - SyncThing
>> >> > Сам уже нашёл.
>> >> > Хотелось бы о нём услышать отзывы использующих.
>> >> > По мне: весьма интересная штука.
>> >>
>> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>> >>
>> > По каким причинам?
>> > Тут бы неплохо прояснить разницу.
>> > Если из бэкапа требуется доставать отдельные файлы, то границу мне
>> > сложно провести.
>>
>> Синхронизатор не отличает намеренное удаление или порчу от
>> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>> засинхронизироваться.
>>
> Как отличает система резервного копирования?
> Или тоже не отличает, но это компенсируется историей бэкапов?
Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
удаляется целиком, либо (если ему повезло оказаться, например, годичным)
хранится "вечно".
>> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >>
>> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> > (облако).
>> > Шифровать отдельно при хранении в NAS, не требуется.
>>
>> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> разные технологии бэкапа :)
>>
> Да, конечно, так и планировалось изначально.
Минус простота настройки.
>> >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>> >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>> >> раз в некоторое время гонят полный бэкап, а между ними
>> >> инкрементальный. tar вот даже различает дифференциальный (разница с
>> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>> >> ни был). Для разумного времени восстановления характерная частота
>> >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>> >> ежедневно. В результате получается дорого, но не невменяемо дорого.
>> >>
>> > Любопытно, на основе инструментов, которые тут советовали, возможно это
>> > построить не сильно напрягаясь?
>>
>> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
>> не позволяет, его нужно выкинуть и посмотреть на другой.
>>
> Согласен.
> Пока не вполне понятно, что из этого выкинуть.
> Кроме Bacula, но тут хвалят её форки.
>> На глазок, при использовании собственно tar, gpg и любого способа
>> копирования такая конструкция собирается за неделю, включая написание
>> регламента. Но трафика будет изрядно.
>>
> И не вполне портируемо.
Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на
винде не будут забэкаплены открытые в данный момент файлы.
>> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> >> при работе в архиве, но все же изрядная.
>> > Она мне, в принципе, требуется.
>> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>> > (сейчас закончил только с музыкой и видео, проекты в нормальном
>> > состоянии, книги и документы в процессе сортировки).
>> > Поэтому, что бэкапить, я могу сказать.
>>
>> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>>
> Ну ok, политика и регламент бэкапа?
> Если делать на серьёзном уровне, конечно полезно.
> В принципе, это в любом случае полезно, так что пока ещё NAS не
> завершён, в рамках этого проекта возможно и системой резервного
> копирования более серьёзно заняться.
Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
касающейся его части.
>> >> "Результатом автоматизации
>> >> бардака может быть только автоматизированный бардак." В нее, в
>> >> частности, входит периодическая тренировка восстановления из
>> >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
>> >> получится восстановиться.
>> >>
>> > С проведением таких "учений" всё сложнее: как восстанавливать машину, на
>> > которой постоянно работаешь (в любом случае, восстановление - потеря
>> > времени)?
>>
>> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
>> делаешь, либо у тебя очень невысокие шансы, что ты сможешь
>> восстановиться в случае проблем.
>>
>> Вероятность того, что при первой попытке восстановления проблемы
>> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
>> все же заметно больше нуля, и чем сложнее инфраструктура хранения
>> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
>> аргумент в пользу решений на базе rsync, у которых на выходе такое же
>> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
>> лучше, чтобы первые несколько тревог были учебными.
>>
> Хорошо, тогда касательно rsync: как делать дифференциальный и
> инкрементальный бэкап?
У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап,
и потом rsync -a --delete в будущий_бэкап.
Если бэкапится юниксовая машина, то вся конструкция без особых
сложностей скриптуется с сервера, который и следит за расписанием. С
виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
-al" и по расписанию пинал по почте владельца машины. А часть rsync
запускает уже владелец машины.
> Касательно проверок: как это делается?
> На практике, там где это было, как проводится такая проверка в
> существующей инфраструктуре?
Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
диском (обычно виртуалка, но по возможности иногда и на железе стоит
прогнать), и на нее выполняется регламент восстановления. Если не
сработал - все бросаем, чиним, корректируем регламент.
Если речь идет о восстановлении пользовательских данных, а не всей
системы, то машина берется не пустая, а с установленной ОС. В этом
случае регламент восстановления должен включать установку необходимого
софта поверх базовой установки ОС (буде он нужен), если он еще не
установлен. Это тоже надо проверять, а то разное может получиться.
Reply to: