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, > но почему-то мне кажется, что система с агентами более гибка. Зато более сложна и, соответственно, более подвержена сбоям. А от бэкапа требуется надежность. Поэтому чем сложнее система, тем больше внимания ей придется уделять, чтобы поддерживать ее в работоспособном состоянии. Избыточная гибкость бывает хуже, чем недостаточная.
