Re: Backup

[artiom <artiom14@yandex.ru>]

>  >>  >>  >> Инкрементальный бэкап, который обеспечивает tar и основные
>  >>  >>  >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>  >>  >>  >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>  >>  >>  >> как у rsync, второе и третье ценой невозможности первого. Первое и
>  >>  >>  >> третье можно делать, гоняя каждый раз полный бэкап.
>  >>  >>  >>
>  >>  >>  > Вы не вполне верно поняли требование, либо я не точно выразился.
>  >>  >>  > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>  >>  >>  > (облако).
>  >>  >>  > Шифровать отдельно при хранении в NAS, не требуется.
>  >>  >> 
>  >>  >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>  >>  >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>  >>  >> разные технологии бэкапа :)
>  >>  >> 
>  >>  > Да, конечно, так и планировалось изначально.
>  >> 
>  >> Минус простота настройки.
>  >> 
>  > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
> 
> В изначальной постановке задачи простота настройки была одним из условий :)
> 
Да нет же.
В изначальной постановке задачи было: "Минимум ручной допилки и сложной
настройки на сервере".
Т.е., не приветствуется, но разумный минимум, меньше которого сделать не
получится (или это приведёт к установке неоправданно внутренне сложной
системы), принимается.

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

>  >> Если бэкапится юниксовая машина, то вся конструкция без особых
>  >> сложностей скриптуется с сервера, который и следит за расписанием. С
>  >> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
>  >> -al" и по расписанию пинал по почте владельца машины. А часть rsync
>  >> запускает уже владелец машины.
>  >> 
>  > Как понять "скриптуется с сервера"?
> 
> Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую
> мы бэкапим) с точки зрения rsync является сервером.
> 
Ясно.
Вообще, BackupPC так умеет. Он безагентный, использует rsync для *nix,
но почему-то мне кажется, что система с агентами более гибка.