> >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные > >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, > дает > >> >> >> первое и второй ценой невозможности третьего. Обратный > инкрементальный, > >> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и > >> >> >> третье можно делать, гоняя каждый раз полный бэкап. > >> >> >> > >> >> > Вы не вполне верно поняли требование, либо я не точно выразился. > >> >> > Шифровать каналы отправки и шифровать при отправке на внешнее > хранилище > >> >> > (облако). > >> >> > Шифровать отдельно при хранении в NAS, не требуется. > >> >> > >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет > смысл, > >> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся > >> >> разные технологии бэкапа :) > >> >> > >> > Да, конечно, так и планировалось изначально. > >> > >> Минус простота настройки. > >> > > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз. > > В изначальной постановке задачи простота настройки была одним из условий :) > Да нет же. В изначальной постановке задачи было: "Минимум ручной допилки и сложной настройки на сервере". Т.е., не приветствуется, но разумный минимум, меньше которого сделать не получится (или это приведёт к установке неоправданно внутренне сложной системы), принимается.
> > >> >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то > надо > >> >> >> понимать, что первое, что тут требуется - это дисциплина. Не > такая, как > >> >> >> при работе в архиве, но все же изрядная. > >> >> > Она мне, в принципе, требуется. > >> >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать > >> >> > (сейчас закончил только с музыкой и видео, проекты в нормальном > >> >> > состоянии, книги и документы в процессе сортировки). > >> >> > Поэтому, что бэкапить, я могу сказать. > >> >> > >> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда > >> >> проверять восстанавливаемость из бэкапа". Два письменных документа, > ага. > >> >> > >> > Ну ok, политика и регламент бэкапа? > >> > Если делать на серьёзном уровне, конечно полезно. > >> > В принципе, это в любом случае полезно, так что пока ещё NAS не > >> > завершён, в рамках этого проекта возможно и системой резервного > >> > копирования более серьёзно заняться. > >> > >> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем, > >> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в > >> касающейся его части. > >> > > Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все > > слышали такое понятие, как "регламент бэкапа". Кое-что пользователю > > знать не нужно. > > А есть разные регламенты. Для админа, настраивающего бэкап, для админа, > следящего за бэкапами, и для пользователя, желающего, чтобы его данные > и/или систему в случае сбоев можно было восстановить. > > Мне не попадалось ситуаций, где бы все данные, ценные для пользователя, > удавалось отследить и забэкапить без его осознанного участия. Кроме > конструкций с бездисковыми X-терминалами в конце 90-х - начале 2000-х, > когда все данные, а зачастую и ОС терминала хранились на одном сервере и > только на нем. Повторюсь, > > >> >> >> "Результатом автоматизации > >> >> >> бардака может быть только автоматизированный бардак." Формально, пользователь должен держать данные в каталоге Documents (и подобном) и на рабочем столе. Ну т.е., есть некоторые умолчания. А если нужна кастомизация, то это уже отдельная задача. > >> Если бэкапится юниксовая машина, то вся конструкция без особых > >> сложностей скриптуется с сервера, который и следит за расписанием. С > >> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp > >> -al" и по расписанию пинал по почте владельца машины. А часть rsync > >> запускает уже владелец машины. > >> > > Как понять "скриптуется с сервера"? > > Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую > мы бэкапим) с точки зрения rsync является сервером. > Ясно. Вообще, BackupPC так умеет. Он безагентный, использует rsync для *nix, но почему-то мне кажется, что система с агентами более гибка.
