Re: Backup
artiom -> debian-russian@lists.debian.org @ Tue, 20 Feb 2018 21:07:30 +0300:
>> >> >> >> Инкрементальный бэкап, который обеспечивает tar и основные
>> >> >> >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>> >> >> >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>> >> >> >> как у rsync, второе и третье ценой невозможности первого. Первое и
>> >> >> >> третье можно делать, гоняя каждый раз полный бэкап.
>> >> >> >>
>> >> >> > Вы не вполне верно поняли требование, либо я не точно выразился.
>> >> >> > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>> >> >> > (облако).
>> >> >> > Шифровать отдельно при хранении в NAS, не требуется.
>> >> >>
>> >> >> Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
>> >> >> вообще-то, выбирать разные два из трех. Но, естественно, получатся
>> >> >> разные технологии бэкапа :)
>> >> >>
>> >> > Да, конечно, так и планировалось изначально.
>> >>
>> >> Минус простота настройки.
>> >>
>> > В рамках всей системы - терпимо. Не сразу. К тому же, настроить - один раз.
>>
>> В изначальной постановке задачи простота настройки была одним из условий :)
>>
> Да нет же.
> В изначальной постановке задачи было: "Минимум ручной допилки и сложной
> настройки на сервере".
> Т.е., не приветствуется, но разумный минимум, меньше которого сделать не
> получится (или это приведёт к установке неоправданно внутренне сложной
> системы), принимается.
Простота и есть разумный минимум сложности :)
>> >> >> >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
>> >> >> >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
>> >> >> >> при работе в архиве, но все же изрядная.
>> >> >> > Она мне, в принципе, требуется.
>> >> >> > В плане организации я пытаюсь сейчас всё постепенно рассортировать
>> >> >> > (сейчас закончил только с музыкой и видео, проекты в нормальном
>> >> >> > состоянии, книги и документы в процессе сортировки).
>> >> >> > Поэтому, что бэкапить, я могу сказать.
>> >> >>
>> >> >> Там не просто "что бэкапить". Там еще "как бэкапить" и "как и когда
>> >> >> проверять восстанавливаемость из бэкапа". Два письменных документа, ага.
>> >> >>
>> >> > Ну ok, политика и регламент бэкапа?
>> >> > Если делать на серьёзном уровне, конечно полезно.
>> >> > В принципе, это в любом случае полезно, так что пока ещё NAS не
>> >> > завершён, в рамках этого проекта возможно и системой резервного
>> >> > копирования более серьёзно заняться.
>> >>
>> >> Тут ведь как... Даже к домашнему бэкапу нужен регламент, известный всем,
>> >> чья техника бэкапится. И, сюрприз, его выполнение. Каждым участником в
>> >> касающейся его части.
>> >>
>> > Т.е. мной. Кроме того, я почему-то сомневаюсь, что в компаниях все
>> > слышали такое понятие, как "регламент бэкапа". Кое-что пользователю
>> > знать не нужно.
>>
>> А есть разные регламенты. Для админа, настраивающего бэкап, для админа,
>> следящего за бэкапами, и для пользователя, желающего, чтобы его данные
>> и/или систему в случае сбоев можно было восстановить.
>>
>> Мне не попадалось ситуаций, где бы все данные, ценные для пользователя,
>> удавалось отследить и забэкапить без его осознанного участия. Кроме
>> конструкций с бездисковыми X-терминалами в конце 90-х - начале 2000-х,
>> когда все данные, а зачастую и ОС терминала хранились на одном сервере и
>> только на нем. Повторюсь,
>>
>> >> >> >> "Результатом автоматизации
>> >> >> >> бардака может быть только автоматизированный бардак."
> Формально, пользователь должен держать данные в каталоге Documents (и
> подобном) и на рабочем столе.
> Ну т.е., есть некоторые умолчания. А если нужна кастомизация, то это уже
> отдельная задача.
Для того, чтобы данные бэкапились, пользователь должен предоставить
данные бэкапилке не формально, а фактически. Это обеспечивается только
дисциплиной.
>> >> Если бэкапится юниксовая машина, то вся конструкция без особых
>> >> сложностей скриптуется с сервера, который и следит за расписанием. С
>> >> виндовой, как показала практика, удобнее, чтобы сервер делал часть "cp
>> >> -al" и по расписанию пинал по почте владельца машины. А часть rsync
>> >> запускает уже владелец машины.
>> >>
>> > Как понять "скриптуется с сервера"?
>>
>> Скрипт бэкапа выполняется на бэкап-сервере. "Клиент" (та машина, которую
>> мы бэкапим) с точки зрения rsync является сервером.
>>
> Ясно.
> Вообще, BackupPC так умеет. Он безагентный, использует rsync для *nix,
> но почему-то мне кажется, что система с агентами более гибка.
Зато более сложна и, соответственно, более подвержена сбоям. А от бэкапа
требуется надежность. Поэтому чем сложнее система, тем больше внимания
ей придется уделять, чтобы поддерживать ее в работоспособном
состоянии. Избыточная гибкость бывает хуже, чем недостаточная.
Reply to: