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. > Интересная штука, но у меня пока слабое представление о том, что с ней > возможно сделать, решит ли это мои задачи. Вообще, должен сказать, что существующие системы контроля версий с задачами бэкапа довольно плохо совместимы. Поскольку по построению хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно небольшую выборку, а промежуточные состояния периодически удалять. >> - NextCloud > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт, > почему называется "облаком", легко ли его интегрировать с той же Bacula > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл > использовать в составе NAS. >> - SyncThing > Сам уже нашёл. > Хотелось бы о нём услышать отзывы использующих. > По мне: весьма интересная штука. Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится. >> - rsync поддерживает использование ssh как транспорт, существуют так же >> надстройки разные >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним > придётся всё доделывать самостоятельно, а в той же Bacula большинство > функций реализовано и отлажено. >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так >> абстрактно... >> > 1. Шифрование бэкапов. > 2. Репликация в выбранное облако (например, dropbox). > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование. > Т.к. раньше я ими не пользовался, ничего конкретного про > репликацию/наличие API спросить не могу. "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по сети", и "восстанавливать за разумное время" - выберите любые два из трех. Инкрементальный бэкап, который обеспечивает tar и основные продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает первое и второй ценой невозможности третьего. Обратный инкрементальный, как у rsync, второе и третье ценой невозможности первого. Первое и третье можно делать, гоняя каждый раз полный бэкап. В многолетней практике (man tar, там эта практика еще со времен бэкапов на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно по временнЫм характеристикам) обычно устраивают комбинированное решение: раз в некоторое время гонят полный бэкап, а между ними инкрементальный. tar вот даже различает дифференциальный (разница с предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он ни был). Для разумного времени восстановления характерная частота полного - раз в месяц, дифференциального - в неделю, инкрементального - ежедневно. В результате получается дорого, но не невменяемо дорого. Но вообще, если уж ты собираешься делать бэкапы как следует, то надо понимать, что первое, что тут требуется - это дисциплина. Не такая, как при работе в архиве, но все же изрядная. "Результатом автоматизации бардака может быть только автоматизированный бардак." В нее, в частности, входит периодическая тренировка восстановления из бэкапа. Потому что очень легко настроить бэкап, из которого потом не получится восстановиться.
