Re: Backup
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-интерфейс там, пожалуй, нет).
>>
>> Не путаем бэкап с архивом. Для бэкапа не годится.
>>
> По каким причинам?
Требует архивной дисциплины. Я использовал его, ага.
>> >> - 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 спросить не могу.
>>
>> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
>> сети", и "восстанавливать за разумное время" - выберите любые два из
>> трех.
> Первые два, но время именно "разумное", я же не говорю "быстро".
Я тоже говорю "разумное". Выберите любые два из трех.
>> Инкрементальный бэкап, который обеспечивает tar и основные
>> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> как у rsync, второе и третье ценой невозможности первого. Первое и
>> третье можно делать, гоняя каждый раз полный бэкап.
>>
> Вы не вполне верно поняли требование, либо я не точно выразился.
> Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
> (облако).
> Шифровать отдельно при хранении в NAS, не требуется.
Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
вообще-то, выбирать разные два из трех. Но, естественно, получатся
разные технологии бэкапа :)
>> В многолетней практике (man tar, там эта практика еще со времен бэкапов
>> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>> по временнЫм характеристикам) обычно устраивают комбинированное решение:
>> раз в некоторое время гонят полный бэкап, а между ними
>> инкрементальный. tar вот даже различает дифференциальный (разница с
>> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
>> ни был). Для разумного времени восстановления характерная частота
>> полного - раз в месяц, дифференциального - в неделю, инкрементального -
>> ежедневно. В результате получается дорого, но не невменяемо дорого.
>>
> Любопытно, на основе инструментов, которые тут советовали, возможно это
> построить не сильно напрягаясь?
Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
не позволяет, его нужно выкинуть и посмотреть на другой.
На глазок, при использовании собственно tar, gpg и любого способа
копирования такая конструкция собирается за неделю, включая написание
регламента. Но трафика будет изрядно.
>> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> при работе в архиве, но все же изрядная.
> Она мне, в принципе, требуется.
> В плане организации я пытаюсь сейчас всё постепенно рассортировать
> (сейчас закончил только с музыкой и видео, проекты в нормальном
> состоянии, книги и документы в процессе сортировки).
> Поэтому, что бэкапить, я могу сказать.
Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>> "Результатом автоматизации
>> бардака может быть только автоматизированный бардак." В нее, в
>> частности, входит периодическая тренировка восстановления из
>> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
>> получится восстановиться.
>>
> С проведением таких "учений" всё сложнее: как восстанавливать машину, на
> которой постоянно работаешь (в любом случае, восстановление - потеря
> времени)?
Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно
делаешь, либо у тебя очень невысокие шансы, что ты сможешь
восстановиться в случае проблем.
Вероятность того, что при первой попытке восстановления проблемы
возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но
все же заметно больше нуля, и чем сложнее инфраструктура хранения
резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати,
аргумент в пользу решений на базе rsync, у которых на выходе такое же
дерево файлов, как в оригинале - восстановление очень простое.) Поэтому
лучше, чтобы первые несколько тревог были учебными.
Reply to: