16.02.2018 10:39, Artem Chuprina пишет: > artiom -> debian-russian@lists.debian.org @ Fri, 16 Feb 2018 08:25:39 +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-интерфейс там, пожалуй, нет). > > Не путаем бэкап с архивом. Для бэкапа не годится. > По каким причинам?
> >> - SparkleShare - что-то весьма минималистичное > > Неслабо минималистичное: свой Dropbox. > > Правда, в качестве хранилища по умолчанию - git. > > Интересная штука, но у меня пока слабое представление о том, что с ней > > возможно сделать, решит ли это мои задачи. > > Вообще, должен сказать, что существующие системы контроля версий с > задачами бэкапа довольно плохо совместимы. Поскольку по построению > хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут > со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно > небольшую выборку, а промежуточные состояния периодически удалять. > Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то так) для внешнего хранения бинарей: они тоже могли реализовать своё бинарное хранилище, как модуль гита. > >> - NextCloud > > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт, > > почему называется "облаком", легко ли его интегрировать с той же Bacula > > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл > > использовать в составе NAS. > > >> - SyncThing > > Сам уже нашёл. > > Хотелось бы о нём услышать отзывы использующих. > > По мне: весьма интересная штука. > > Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится. > По каким причинам? Тут бы неплохо прояснить разницу. Если из бэкапа требуется доставать отдельные файлы, то границу мне сложно провести. > >> - rsync поддерживает использование ssh как транспорт, существуют так же > >> надстройки разные > >> > > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним > > придётся всё доделывать самостоятельно, а в той же Bacula большинство > > функций реализовано и отлажено. > > >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так > >> абстрактно... > >> > > 1. Шифрование бэкапов. > > 2. Репликация в выбранное облако (например, dropbox). > > > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное > шифрование. > > Т.к. раньше я ими не пользовался, ничего конкретного про > > репликацию/наличие API спросить не могу. > > "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по > сети", и "восстанавливать за разумное время" - выберите любые два из > трех. Первые два, но время именно "разумное", я же не говорю "быстро". > Инкрементальный бэкап, который обеспечивает tar и основные > продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает > первое и второй ценой невозможности третьего. Обратный инкрементальный, > как у rsync, второе и третье ценой невозможности первого. Первое и > третье можно делать, гоняя каждый раз полный бэкап. > Вы не вполне верно поняли требование, либо я не точно выразился. Шифровать каналы отправки и шифровать при отправке на внешнее хранилище (облако). Шифровать отдельно при хранении в NAS, не требуется. > В многолетней практике (man tar, там эта практика еще со времен бэкапов > на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно > по временнЫм характеристикам) обычно устраивают комбинированное решение: > раз в некоторое время гонят полный бэкап, а между ними > инкрементальный. tar вот даже различает дифференциальный (разница с > предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он > ни был). Для разумного времени восстановления характерная частота > полного - раз в месяц, дифференциального - в неделю, инкрементального - > ежедневно. В результате получается дорого, но не невменяемо дорого. > Любопытно, на основе инструментов, которые тут советовали, возможно это построить не сильно напрягаясь? > Но вообще, если уж ты собираешься делать бэкапы как следует, то надо > понимать, что первое, что тут требуется - это дисциплина. Не такая, как > при работе в архиве, но все же изрядная. Она мне, в принципе, требуется. В плане организации я пытаюсь сейчас всё постепенно рассортировать (сейчас закончил только с музыкой и видео, проекты в нормальном состоянии, книги и документы в процессе сортировки). Поэтому, что бэкапить, я могу сказать. > "Результатом автоматизации > бардака может быть только автоматизированный бардак." В нее, в > частности, входит периодическая тренировка восстановления из > бэкапа. Потому что очень легко настроить бэкап, из которого потом не > получится восстановиться. > С проведением таких "учений" всё сложнее: как восстанавливать машину, на которой постоянно работаешь (в любом случае, восстановление - потеря времени)?
