Re: Backup

[artiom <artiom14@yandex.ru>]

17.02.2018 00:35, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 22:25:22 +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?

>  >>  >> - SparkleShare - что-то весьма минималистичное
>  >>  > Неслабо минималистичное: свой Dropbox.
>  >>  > Правда, в качестве хранилища по умолчанию - git.
>  >>  > Интересная штука, но у меня пока слабое представление о том, что с ней
>  >>  > возможно сделать,  решит ли это мои задачи.
>  >> 
>  >> Вообще, должен сказать, что существующие системы контроля версий с
>  >> задачами бэкапа довольно плохо совместимы. Поскольку по построению
>  >> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
>  >> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
>  >> небольшую выборку, а промежуточные состояния периодически удалять.
>  >> 
>  > Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то
>  > так) для внешнего хранения бинарей: они тоже могли реализовать своё
>  > бинарное хранилище, как модуль гита.
> 
> Я поэтому довольно осторожно сказал "плохо", а не "несовместимы". По
> поводу конкретно гита нагуглилось такое:
> 
> https://www.perforce.com/blog/storing-large-binary-files-in-git-repositories
> 
> По косому взгляду, для задач бэкапа одно другого хуже.
> 
Ну да, их много (правда, я думал, что меньше).
И нужны они всё-таки для задач разработки.
Бэкап тут за уши притянут, не спорю.

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

>  >>  >> - rsync поддерживает использование ssh как транспорт, существуют так же
>  >>  >> надстройки разные
>  >>  >> 
>  >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
>  >>  > придётся всё доделывать самостоятельно, а в той же Bacula большинство
>  >>  > функций реализовано и отлажено.
>  >> 
>  >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
>  >>  >> абстрактно...
>  >>  >> 
>  >>  > 1. Шифрование бэкапов.
>  >>  > 2. Репликация в выбранное облако (например, dropbox).
>  >> 
>  >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
>  >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
>  >>  > репликацию/наличие API спросить не могу.
>  >> 
>  >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
>  >> сети", и "восстанавливать за разумное время" - выберите любые два из
>  >> трех.
>  > Первые два, но время именно "разумное", я же не говорю "быстро".
> 
> Я тоже говорю "разумное". Выберите любые два из трех.
> 
Все три: "отправлять зашифрованное" я могу параллельно с созданием
бэкапа (места должно хватить, плюс снэпшоты ZFS).

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

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

> На глазок, при использовании собственно tar, gpg и любого способа
> копирования такая конструкция собирается за неделю, включая написание
> регламента. Но трафика будет изрядно.
> 
И не вполне портируемо.

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

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