Re: Backup

[Artem Chuprina <ran@lasgalen.net>]

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 вот даже различает дифференциальный (разница с
предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
ни был). Для разумного времени восстановления характерная частота
полного - раз в месяц, дифференциального - в неделю, инкрементального -
ежедневно. В результате получается дорого, но не невменяемо дорого.

Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
понимать, что первое, что тут требуется - это дисциплина. Не такая, как
при работе в архиве, но все же изрядная. "Результатом автоматизации
бардака может быть только автоматизированный бардак." В нее, в
частности, входит периодическая тренировка восстановления из
бэкапа. Потому что очень легко настроить бэкап, из которого потом не
получится восстановиться.