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: как делать дифференциальный и инкрементальный бэкап? Касательно проверок: как это делается? На практике, там где это было, как проводится такая проверка в существующей инфраструктуре?
