Re: Backup
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 вот даже различает дифференциальный (разница с
> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
> ни был). Для разумного времени восстановления характерная частота
> полного - раз в месяц, дифференциального - в неделю, инкрементального -
> ежедневно. В результате получается дорого, но не невменяемо дорого.
>
Любопытно, на основе инструментов, которые тут советовали, возможно это
построить не сильно напрягаясь?
> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
> при работе в архиве, но все же изрядная.
Она мне, в принципе, требуется.
В плане организации я пытаюсь сейчас всё постепенно рассортировать
(сейчас закончил только с музыкой и видео, проекты в нормальном
состоянии, книги и документы в процессе сортировки).
Поэтому, что бэкапить, я могу сказать.
> "Результатом автоматизации
> бардака может быть только автоматизированный бардак." В нее, в
> частности, входит периодическая тренировка восстановления из
> бэкапа. Потому что очень легко настроить бэкап, из которого потом не
> получится восстановиться.
>
С проведением таких "учений" всё сложнее: как восстанавливать машину, на
которой постоянно работаешь (в любом случае, восстановление - потеря
времени)?
Reply to:
- Follow-Ups:
- Re: Backup
- From: Artem Chuprina <ran@lasgalen.net>
- References:
- Backup
- From: artiom <artiom14@yandex.ru>
- Re: Backup
- From: Hexawolf <hexawolf@cock.li>
- Re: Backup
- From: artiom <artiom14@yandex.ru>
- Re: Backup
- From: Artem Chuprina <ran@lasgalen.net>