artiom -> debian-russian@lists.debian.org @ Sat, 17 Feb 2018 11:16:16 +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-интерфейс там, пожалуй, нет). >> >> >> >> Не путаем бэкап с архивом. Для бэкапа не годится. >> >> >> > По каким причинам? >> >> Требует архивной дисциплины. Я использовал его, ага. >> > git-annex? Да. Архивные, т.е. _не изменяющиеся_, здоровенные бинарники, с отслеживанием, где и сколько их копий, и комментированием, где что за хрень. Он придуман для этой задачи, и ее выполняет хорошо. Потом как-то продолбал дисциплину архивной работы, и теперь уже поди найди хотя бы один репозиторий, где вся эта информация... >> >> >> - NextCloud >> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт, >> >> > почему называется "облаком", легко ли его интегрировать с той же >> Bacula >> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл >> >> > использовать в составе NAS. >> >> >> >> >> - SyncThing >> >> > Сам уже нашёл. >> >> > Хотелось бы о нём услышать отзывы использующих. >> >> > По мне: весьма интересная штука. >> >> >> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится. >> >> >> > По каким причинам? >> > Тут бы неплохо прояснить разницу. >> > Если из бэкапа требуется доставать отдельные файлы, то границу мне >> > сложно провести. >> >> Синхронизатор не отличает намеренное удаление или порчу от >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели >> засинхронизироваться. >> > Как отличает система резервного копирования? > Или тоже не отличает, но это компенсируется историей бэкапов? Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания удаляется целиком, либо (если ему повезло оказаться, например, годичным) хранится "вечно". >> >> Инкрементальный бэкап, который обеспечивает tar и основные >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный, >> >> как у rsync, второе и третье ценой невозможности первого. Первое и >> >> третье можно делать, гоняя каждый раз полный бэкап. >> >> >> > Вы не вполне верно поняли требование, либо я не точно выразился. >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище >> > (облако). >> > Шифровать отдельно при хранении в NAS, не требуется. >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл, >> вообще-то, выбирать разные два из трех. Но, естественно, получатся >> разные технологии бэкапа :) >> > Да, конечно, так и планировалось изначально. Минус простота настройки. >> >> В многолетней практике (man tar, там эта практика еще со времен бэкапов >> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно >> >> по временнЫм характеристикам) обычно устраивают комбинированное решение: >> >> раз в некоторое время гонят полный бэкап, а между ними >> >> инкрементальный. tar вот даже различает дифференциальный (разница с >> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он >> >> ни был). Для разумного времени восстановления характерная частота >> >> полного - раз в месяц, дифференциального - в неделю, инкрементального - >> >> ежедневно. В результате получается дорого, но не невменяемо дорого. >> >> >> > Любопытно, на основе инструментов, которые тут советовали, возможно это >> > построить не сильно напрягаясь? >> >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого >> не позволяет, его нужно выкинуть и посмотреть на другой. >> > Согласен. > Пока не вполне понятно, что из этого выкинуть. > Кроме Bacula, но тут хвалят её форки. >> На глазок, при использовании собственно tar, gpg и любого способа >> копирования такая конструкция собирается за неделю, включая написание >> регламента. Но трафика будет изрядно. >> > И не вполне портируемо. Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на винде не будут забэкаплены открытые в данный момент файлы. >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как >> >> при работе в архиве, но все же изрядная. >> > Она мне, в принципе, требуется. >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать >> > (сейчас закончил только с музыкой и видео, проекты в нормальном >> > состоянии, книги и документы в процессе сортировки). >> > Поэтому, что бэкапить, я могу сказать. >> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага. >> > Ну ok, политика и регламент бэкапа? > Если делать на серьёзном уровне, конечно полезно. > В принципе, это в любом случае полезно, так что пока ещё NAS не > завершён, в рамках этого проекта возможно и системой резервного > копирования более серьёзно заняться. Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем, чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в касающейся его части. >> >> "Результатом автоматизации >> >> бардака может быть только автоматизированный бардак." В нее, в >> >> частности, входит периодическая тренировка восстановления из >> >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не >> >> получится восстановиться. >> >> >> > С проведением таких "учений" всё сложнее: как восстанавливать машину, на >> > которой постоянно работаешь (в любом случае, восстановление - потеря >> > времени)? >> >> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно >> делаешь, либо у тебя очень невысокие шансы, что ты сможешь >> восстановиться в случае проблем. >> >> Вероятность того, что при первой попытке восстановления проблемы >> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но >> все же заметно больше нуля, и чем сложнее инфраструктура хранения >> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати, >> аргумент в пользу решений на базе rsync, у которых на выходе такое же >> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому >> лучше, чтобы первые несколько тревог были учебными. >> > Хорошо, тогда касательно rsync: как делать дифференциальный и > инкрементальный бэкап? У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап, и потом rsync -a --delete в будущий_бэкап. Если бэкапится юниксовая машина, то вся конструкция без особых сложностей скриптуется с сервера, который и следит за расписанием. С виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp -al" и по расписанию пинал по почте владельца машины. А часть rsync запускает уже владелец машины. > Касательно проверок: как это делается? > На практике, там где это было, как проводится такая проверка в > существующей инфраструктуре? Тупо и цинично. Берется специальная тренировочная машина, типа с пустым диском (обычно виртуалка, но по возможности иногда и на железе стоит прогнать), и на нее выполняется регламент восстановления. Если не сработал - все бросаем, чиним, корректируем регламент. Если речь идет о восстановлении пользовательских данных, а не всей системы, то машина берется не пустая, а с установленной ОС. В этом случае регламент восстановления должен включать установку необходимого софта поверх базовой установки ОС (буде он нужен), если он еще не установлен. Это тоже надо проверять, а то разное может получиться.
