artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:15:25 +0300:
>> >> Синхронизатор не отличает намеренное удаление или порчу от >> >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в >> >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели >> >> засинхронизироваться. >> >> >> > Как отличает система резервного копирования? >> > Или тоже не отличает, но это компенсируется историей бэкапов? >> >> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания >> удаляется целиком, либо (если ему повезло оказаться, например, годичным) >> хранится "вечно". >> > А какова частота полного, декремента и инкремента? Зависит от характера изменения данных. На работе бэкап делался ежедневно - восстанавливать работу всей конторы за неделю было сложно, поскольку задач много, и за неделю тупо успеваешь забыть, что делал, не то что как. Дома делается раз в неделю. Это, если применяются инкрементные, частота инкрементных (у меня довольно давно применяются обратно-инкрементные, там бэкап бывает только одного типа). Если же говорить о декрементных и полных, то тут вопрос баланса трафика туда и времени восстановления. Я бы сказал, что полные следует делать настолько часто, насколько позволяет жаба по трафику. Деление на декремент и инкремент проводить скорее из соображений "больше десятка инкрементов за одну операцию восстановления не офигеть как удобно накатывать". В man tar приводился для прикидки вариант "полные раз в месяц, декременты раз в неделю, инкременты раз в день". Тогда при восстановлении накатывается один полный, один декремент (он по определению один) и не больше 6 инкрементов. >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, >> дает >> >> >> первое и второй ценой невозможности третьего. Обратный >> инкрементальный, >> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и >> >> >> третье можно делать, гоняя каждый раз полный бэкап. >> >> >> >> >> > Вы не вполне верно поняли требование, либо я не точно выразился. >> >> > Шифровать каналы отправки и шифровать при отправке на внешнее >> хранилище >> >> > (облако). >> >> > Шифровать отдельно при хранении в NAS, не требуется. >> >> >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл, >> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся >> >> разные технологии бэкапа :) >> >> >> > Да, конечно, так и планировалось изначально. >> >> Минус простота настройки. >> > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз. В изначальной постановке задачи простота настройки была одним из условий :) >> >> >> В многолетней практике (man tar, там эта практика еще со времен >> бэкапов >> >> >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно >> оно >> >> >> по временнЫм характеристикам) обычно устраивают комбинированное >> решение: >> >> >> раз в некоторое время гонят полный бэкап, а между ними >> >> >> инкрементальный. tar вот даже различает дифференциальный (разница с >> >> >> предыдущим полным) и инкрементальный (разница с предыдущим, каким >> бы он >> >> >> ни был). Для разумного времени восстановления характерная частота >> >> >> полного - раз в месяц, дифференциального - в неделю, >> инкрементального - >> >> >> ежедневно. В результате получается дорого, но не невменяемо дорого. >> >> >> >> >> > Любопытно, на основе инструментов, которые тут советовали, возможно >> это >> >> > построить не сильно напрягаясь? >> >> >> >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого >> >> не позволяет, его нужно выкинуть и посмотреть на другой. >> >> >> > Согласен. >> > Пока не вполне понятно, что из этого выкинуть. >> > Кроме Bacula, но тут хвалят её форки. >> >> >> На глазок, при использовании собственно tar, gpg и любого способа >> >> копирования такая конструкция собирается за неделю, включая написание >> >> регламента. Но трафика будет изрядно. >> >> >> > И не вполне портируемо. >> >> Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на >> винде не будут забэкаплены открытые в данный момент файлы. >> > Всё-таки, не вижу пока чем хуже urbackup: агенты уже реализованы и > отлажены, web-интерфейс есть, по фичам всё нормально и статей о нём нет > типа "О том, как я неделю вдуплял в BareOS". Я не имею цели отвратить тебя от urbackup. Которого я в глаза не видел. >> >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо >> >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, >> как >> >> >> при работе в архиве, но все же изрядная. >> >> > Она мне, в принципе, требуется. >> >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать >> >> > (сейчас закончил только с музыкой и видео, проекты в нормальном >> >> > состоянии, книги и документы в процессе сортировки). >> >> > Поэтому, что бэкапить, я могу сказать. >> >> >> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда >> >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага. >> >> >> > Ну ok, политика и регламент бэкапа? >> > Если делать на серьёзном уровне, конечно полезно. >> > В принципе, это в любом случае полезно, так что пока ещё NAS не >> > завершён, в рамках этого проекта возможно и системой резервного >> > копирования более серьёзно заняться. >> >> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем, >> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в >> касающейся его части. >> > Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все > слышали такое понятие, как "регламент бэкапа". Кое-что пользователю > знать не нужно. А есть разные регламенты. Для админа, настраивающего бэкап, для админа, следящего за бэкапами, и для пользователя, желающего, чтобы его данные и/или систему в случае сбоев можно было восстановить. Мне не попадалось ситуаций, где бы все данные, ценные для пользователя, удавалось отследить и забэкапить без его осознанного участия. Кроме конструкций с бездисковыми X-терминалами в конце 90-х - начале 2000-х, когда все данные, а зачастую и ОС терминала хранились на одном сервере и только на нем. Повторюсь, >> >> >> "Результатом автоматизации >> >> >> бардака может быть только автоматизированный бардак." >> > Хорошо, тогда касательно rsync: как делать дифференциальный и >> > инкрементальный бэкап? >> >> У rsync обратный инкрементальный. cp -al последний_бэкап будущий_бэкап, >> и потом rsync -a --delete в будущий_бэкап. >> > А про упомянутый тут restic можете что-то сказать? Не могу. >> Если бэкапится юниксовая машина, то вся конструкция без особых >> сложностей скриптуется с сервера, который и следит за расписанием. С >> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp >> -al" и по расписанию пинал по почте владельца машины. А часть rsync >> запускает уже владелец машины. >> > Как понять "скриптуется с сервера"? Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую мы бэкапим) с точки зрения rsync является сервером. >> > Касательно проверок: как это делается? >> > На практике, там где это было, как проводится такая проверка в >> > существующей инфраструктуре? >> >> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым >> диском (обычно виртуалка, но по возможности иногда и на железе стоит >> прогнать), и на нее выполняется регламент восстановления. Если не >> сработал - все бросаем, чиним, корректируем регламент. >> >> Если речь идет о восстановлении пользовательских данных, а не всей >> системы, то машина берется не пустая, а с установленной ОС. В этом >> случае регламент восстановления должен включать установку необходимого >> софта поверх базовой установки ОС (буде он нужен), если он еще не >> установлен. Это тоже надо проверять, а то разное может получиться. >> > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа > основной инфраструктуры ради проверки восстановления не прерывается. Вообще говоря, возможны ситуации, когда приходится прерывать. Потому что оценить результат восстановления можно только протестировав, что все документированные функции целевой машины работают. А у нее могут быть сетевые сервисы, которые надо проверить по тому самому имени. Для чего "учебная" машина должна подменить в сети "боевую". Тут можно в разных местах проводить границу, и получать разную степень уверенности в результате. Если, скажем, восстанавливается какой-нибудь трекер (веб-морда плюс база плюс почта), то можно в регламент восстановления включить часть "для учебной тревоги", где расписать перенастройку на тестовое имя хоста и на тестовый вариант рассылки по почте (что утраивает работу по написанию регламента и в полтора-два раза увеличивает работу по учебной тревоге). Но, скажем, проверить работоспособность восстановленного домен-контроллера виндовой сети без замены им настоящего я бы вот так вот сходу не взялся, так что надо приходить ночью, когда никого нет, и выключать настоящий.
