> >> >> >> - NextCloud > >> >> > Хотелось бы услышать отзывы, стоит ли его использовать, что оно > даёт, > >> >> > почему называется "облаком", легко ли его интегрировать с той же > Bacula > >> >> > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл > >> >> > использовать в составе NAS. > >> >> > >> >> >> - SyncThing > >> >> > Сам уже нашёл. > >> >> > Хотелось бы о нём услышать отзывы использующих. > >> >> > По мне: весьма интересная штука. > >> >> > >> >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не > годится. > >> >> > >> > По каким причинам? > >> > Тут бы неплохо прояснить разницу. > >> > Если из бэкапа требуется доставать отдельные файлы, то границу мне > >> > сложно провести. > >> > >> Синхронизатор не отличает намеренное удаление или порчу от > >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в > >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели > >> засинхронизироваться. > >> > > Как отличает система резервного копирования? > > Или тоже не отличает, но это компенсируется историей бэкапов? > > Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания > удаляется целиком, либо (если ему повезло оказаться, например, годичным) > хранится "вечно". > А какова частота полного, декремента и инкремента?
> >> >> Инкрементальный бэкап, который обеспечивает tar и основные > >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает > >> >> первое и второй ценой невозможности третьего. Обратный > инкрементальный, > >> >> как у rsync, второе и третье ценой невозможности первого. Первое и > >> >> третье можно делать, гоняя каждый раз полный бэкап. > >> >> > >> > Вы не вполне верно поняли требование, либо я не точно выразился. > >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище > >> > (облако). > >> > Шифровать отдельно при хранении в NAS, не требуется. > >> > >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл, > >> вообще-то, выбирать разные два из трех. Но, естественно, получатся > >> разные технологии бэкапа :) > >> > > Да, конечно, так и планировалось изначально. > > Минус простота настройки. > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз. > >> >> В многолетней практике (man tar, там эта практика еще со времен > бэкапов > >> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно > >> >> по временнЫм характеристикам) обычно устраивают комбинированное > решение: > >> >> раз в некоторое время гонят полный бэкап, а между ними > >> >> инкрементальный. tar вот даже различает дифференциальный (разница с > >> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы > он > >> >> ни был). Для разумного времени восстановления характерная частота > >> >> полного - раз в месяц, дифференциального - в неделю, инкрементального > - > >> >> ежедневно. В результате получается дорого, но не невменяемо дорого. > >> >> > >> > Любопытно, на основе инструментов, которые тут советовали, возможно это > >> > построить не сильно напрягаясь? > >> > >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого > >> не позволяет, его нужно выкинуть и посмотреть на другой. > >> > > Согласен. > > Пока не вполне понятно, что из этого выкинуть. > > Кроме Bacula, но тут хвалят её форки. > > >> На глазок, при использовании собственно tar, gpg и любого способа > >> копирования такая конструкция собирается за неделю, включая написание > >> регламента. Но трафика будет изрядно. > >> > > И не вполне портируемо. > > Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на > винде не будут забэкаплены открытые в данный момент файлы. > Всё-таки, не вижу пока чем хуже urbackup: агенты уже реализованы и отлажены, web-интерфейс есть, по фичам всё нормально и статей о нём нет типа "О том, как я неделю вдуплял в BareOS". > >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо > >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, > как > >> >> при работе в архиве, но все же изрядная. > >> > Она мне, в принципе, требуется. > >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать > >> > (сейчас закончил только с музыкой и видео, проекты в нормальном > >> > состоянии, книги и документы в процессе сортировки). > >> > Поэтому, что бэкапить, я могу сказать. > >> > >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда > >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага. > >> > > Ну ok, политика и регламент бэкапа? > > Если делать на серьёзном уровне, конечно полезно. > > В принципе, это в любом случае полезно, так что пока ещё NAS не > > завершён, в рамках этого проекта возможно и системой резервного > > копирования более серьёзно заняться. > > Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем, > чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в > касающейся его части. > Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все слышали такое понятие, как "регламент бэкапа". Кое-что пользователю знать не нужно. > >> >> "Результатом автоматизации > >> >> бардака может быть только автоматизированный бардак." В нее, в > >> >> частности, входит периодическая тренировка восстановления из > >> >> бэкапа. Потому что очень легко настроить бэкап, из которого потом не > >> >> получится восстановиться. > >> >> > >> > С проведением таких "учений" всё сложнее: как восстанавливать машину, > на > >> > которой постоянно работаешь (в любом случае, восстановление - потеря > >> > времени)? > >> > >> Я в курсе, что это сложно. Но тут одно из двух: либо ты это регулярно > >> делаешь, либо у тебя очень невысокие шансы, что ты сможешь > >> восстановиться в случае проблем. > >> > >> Вероятность того, что при первой попытке восстановления проблемы > >> возникнут, близка к 1. Вероятность, что их не удастся решить, меньше, но > >> все же заметно больше нуля, и чем сложнее инфраструктура хранения > >> резервных копий (привет бакуле), тем ближе она к 1. (Это, кстати, > >> аргумент в пользу решений на базе rsync, у которых на выходе такое же > >> дерево файлов, как в оригинале - восстановление очень простое.) Поэтому > >> лучше, чтобы первые несколько тревог были учебными. > >> > > Хорошо, тогда касательно rsync: как делать дифференциальный и > > инкрементальный бэкап? > > У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап, > и потом rsync -a --delete в будущий_бэкап. > А про упомянутый тут restic можете что-то сказать? > Если бэкапится юниксовая машина, то вся конструкция без особых > сложностей скриптуется с сервера, который и следит за расписанием. С > виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp > -al" и по расписанию пинал по почте владельца машины. А часть rsync > запускает уже владелец машины. > Как понять "скриптуется с сервера"? > > Касательно проверок: как это делается? > > На практике, там где это было, как проводится такая проверка в > > существующей инфраструктуре? > > Тупо и цинично. Берется специальная тренировочная машина, типа с пустым > диском (обычно виртуалка, но по возможности иногда и на железе стоит > прогнать), и на нее выполняется регламент восстановления. Если не > сработал - все бросаем, чиним, корректируем регламент. > > Если речь идет о восстановлении пользовательских данных, а не всей > системы, то машина берется не пустая, а с установленной ОС. В этом > случае регламент восстановления должен включать установку необходимого > софта поверх базовой установки ОС (буде он нужен), если он еще не > установлен. Это тоже надо проверять, а то разное может получиться. > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа основной инфраструктуры ради проверки восстановления не прерывается.
