subject:"Backup"



21.02.2018 08:01, Victor Wagner пишет:
> В Tue, 20 Feb 2018 20:56:03 +0300
> artiom  пишет:
> 
> ю, сбой диска убьет
>>> единственный. 
>> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
>> целом, я считаю, подход неправильный.
>> Надёжность хранилища должна нижним уровнем обеспечиваться.
>> Явно не прикладным, на котором работает система резервного
>> копирования.
> 
> Нет, именно на прикладном - единственный способ обеспечить надежность
> за разумные деньги.
> 
> Тем более, что на прикладном уровне мы можем защищаться от таких угроз
> как "разряд высокого напряжения попал в розетки и убил всю включенную
> электронику в здании" (путем хранения бэкапа на физически отключенном
> устройстве) и даже от угроз "пожар" и "падение атомной бомбы на город"
> (путем хранения одной из копий в географически удаленной локации)
> 
Нет, подождите, во-первых Артём Чуприна, как я это понял, имел ввиду
хранение второй копии просто в другом месте того же самого устройства.
Во-вторых, возможно это и относится к прикладному уровню (в принципе,
политику определяет и отвечает за её реализацию, т.е. выгрузку на
отдельное устройство, система резервного копирования), но это всё-таки
не совсем то.

> Очевидно, что борьба с этими угрозами на нижнем уровне с одной стороны
> обходится бессмысленно дорого, а с другой - порождает новые угрозы.
> 
Думаю, что надо разделять: надёжность системы, в целом (в случае пожара
умрёт аппаратура, а вместе с ней ядро системы резервного копирования) и
надёжность устройства хранения, которая обеспечивается аппаратурой.
"Физический уровень" - это условный RAID (некий как-то реализованный
mirror, благодаря которому не требуется делать две копии, т.к. он делает
это сам).
Резервирование системы, в целом, может быть сделано на разных уровнях
(миграция и репликация в кластере гугла - явно не "прикладной"), но это
не тоже самое, что хранение двух копий каталога с фотографиями.

Re: Backup

2018-02-20 Пенетрантность Victor Wagner

В Tue, 20 Feb 2018 20:56:03 +0300
artiom  пишет:

ю, сбой диска убьет
> > единственный. 
> Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
> целом, я считаю, подход неправильный.
> Надёжность хранилища должна нижним уровнем обеспечиваться.
> Явно не прикладным, на котором работает система резервного
> копирования.

Нет, именно на прикладном - единственный способ обеспечить надежность
за разумные деньги.

Тем более, что на прикладном уровне мы можем защищаться от таких угроз
как "разряд высокого напряжения попал в розетки и убил всю включенную
электронику в здании" (путем хранения бэкапа на физически отключенном
устройстве) и даже от угроз "пожар" и "падение атомной бомбы на город"
(путем хранения одной из копий в географически удаленной локации)

Очевидно, что борьба с этими угрозами на нижнем уровне с одной стороны
обходится бессмысленно дорого, а с другой - порождает новые угрозы.



-- 
   Victor Wagner

Re: Backup

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

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

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

Re: Backup

>  >>  >>  >>  >> В общем, анализировать бэкапные решения надо начинать не с 
> "где
>  >>  >>  >>  >> хранить" и "какой транспорт использовать" а с "как будет 
> выглядеть
>  >>  >>  >>  >> процедура восстановления". Причем в двух вариантах 
>  >>  >>  >>  >>
>  >>  >>  >>  > Да, вообще явного анализа восстановления я не провёл.
>  >>  >>  >>  > Неявно, подразумеваю, что буду переустанавливать систему и 
> накатывать
>  >>  >>  >>  > данные, а не образ.
>  >>  >>  >>  > Т.е., мне не требуется "полный бэкап", как это делают с 
> большим парком
>  >>  >>  >>  > машин.
>  >>  >>  >> 
>  >>  >>  >> Практика восстановления показывает, что если бэкапятся настройки
>  >>  >>  >> системы, то лучше бэкапить всю систему. Восстановление 
> работоспособного
>  >>  >>  >> состояния получится на порядок быстрее. Пользовательские данные 
> можно (и
>  >>  >>  >> часто полезно) бэкапить отдельно.
>  >>  >>  >> 
>  >>  >>  > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
>  >>  >>  > Мало того, не всегда мне нужно будет восстанавливать ту же самую
>  >>  >>  > систему: на том же железе и в точности с той же конфигурацией, 
> плюс к
>  >>  >>  > этому, у меня ещё не было ни одного случая, чтобы полностью 
> загнулся Debian.
>  >>  >>  > Падение скорости восстановления здесь для меня терпимо.
>  >>  >> 
>  >>  >> Системы обычно падают в самый неподходящий момент :) И даже если ты
>  >>  >> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
>  >>  >> прежнюю работоспособную конфигурацию, а потом уже обновлять.
>  >>  >> 
>  >>  > Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже
>  >>  > кем-то решённых).
>  >>  > Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
>  >>  > (пусть и маленькую).
>  >> 
>  >>  > Отсюда:
>  >> 
>  >>  > - Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
>  >>  > года не переустанавливалась, редко выключалась, кроме последних лет, и
>  >>  > долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
>  >>  > заботливо сохранена, и воспроизведётся при каждом полном 
> восстановлении.
>  >> 
>  >> Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только
>  >> конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
>  >> быстро восстановиться, если есть бэкап только конфигов, не получится.
>  >> 
>  > В случае же переустановки, из бэкапа ничего не прилетит.
> 
> Очень не факт. Зараза с легкостью может окопаться и в /etc (в случае
> винды - системном реестре).
> 
Но в /etc бинарник же будет видно, а в случае системного реестра, ей всё
равно файл нужен, который будет запускаться, разве нет?

>  >> Ну и думай, что дороже: дополнительное дисковое пространство для
>  >> хранения бэкапа системы, или твои время и нервы на более сложную
>  >> процедуру восстановления.
>  >> 
>  > С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
>  > пространства хранилища, какие-то 50 Гб на машину странно.
>  > С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
>  > накатил свежую ОС, накатил конфигурацию и пакеты, всё.
> 
> Твоих телодвижений больше. "Накатил свежую ОС" - это существенно больше
> одной команды, и внимания оно хочет не единым куском, а урывками.
> 
В общем, мне надо подумать над этим вопросом. Пока однозначного решения,
как сделать, я принять не могу. У обоих подходов есть плюсы и минусы.

>  >>  > - В этой старой системе я хочу многое переделать, например дисковую
>  >>  > организацию, что потребует переустановки при сохранении большинства
>  >>  > конфигов.
>  >> 
>  >> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
>  >> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
>  >> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
>  >> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
>  >> 
>  > Там много что надо поменять.
> 
> В моей практике это все же обычно лучше делать по одному блоку
> функциональности за раз.
>>  > Плюс, лишних пакетов море скопилось, со старых версий (это ещё
>  > squeeze) что-то определённо тянется.
> 
> dpkg -l, и вдумчиво apt-get remove --purge. Это проще, чем наоборот.
> 
В любом случае, это уже отдельный вопрос: до того, как с основными
задачами NAS разберусь, я этим заниматься не буду.

>  >>  >> Когда я в свое время разрабатывал регламент бэкапов для своей 
> конторы, я
>  >>  >> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию 
> бакулы
>  >>  >> и набор пакетов привел меня к выводу, что потребуется специальный
>  >>  >> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
>  >>  >> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
>  >>  >> виртуалки с виндой.
>  >>  >> 
>  >>  > А форки, которые здесь рекламируют?
>  >>  > http://www.urbackup.org/
>  >>  > https://time404.ru/1776/
>  >> 
>  >> А можно я не буду на них смотреть? Но по идее, если форк, тем более
>  >> более

Re: Backup



18.02.2018 23:07, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sun, 18 Feb 2018 21:23:52 +0300:
> 
>  >>  >>  >>  >> - rsync поддерживает использование ssh как транспорт, 
> существуют так же
>  >>  >>  >>  >> надстройки разные
>  >>  >>  >>  >> 
>  >>  >>  >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над 
> ним
>  >>  >>  >>  > придётся всё доделывать самостоятельно, а в той же Bacula 
> большинство
>  >>  >>  >>  > функций реализовано и отлажено.
>  >>  >>  >> 
>  >>  >>  >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". 
> Это всё так
>  >>  >>  >>  >> абстрактно...
>  >>  >>  >>  >> 
>  >>  >>  >>  > 1. Шифрование бэкапов.
>  >>  >>  >>  > 2. Репликация в выбранное облако (например, dropbox).
>  >>  >>  >> 
>  >>  >>  >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется 
> надёжное шифрование.
>  >>  >>  >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
>  >>  >>  >>  > репликацию/наличие API спросить не могу.
>  >>  >>  >> 
>  >>  >>  >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять 
> по
>  >>  >>  >> сети", и "восстанавливать за разумное время" - выберите любые два 
> из
>  >>  >>  >> трех.
>  >>  >>  > Первые два, но время именно "разумное", я же не говорю "быстро".
>  >>  >> 
>  >>  >> Я тоже говорю "разумное". Выберите любые два из трех.
>  >>  >> 
>  >>  > В процессе изучения вопроса я обнаружил, что есть такая технология, как
>  >>  > дедупликация на клиенте.
>  >>  > И вообще, как ни странно, в случае с файлопомойками, дедап позволяет
>  >>  > экономить до 98% дискового пространства.
>  >> 
>  >> Это, гм, новость. По моим представлениям, дедупликация на файлопомойке
>  >> (где вообще-то каждый файл в среднем чуть более чем в одном экземпляре)
>  >> дает от силы процентов 10, если она пофайловая, и процентов 20, если
>  >> поблочная. А более вероятно - 3 и 5% соответственно. 98% - это надо
>  >> чтобы каждый файл (или блок) хранился в среднем в 50 экземплярах. Я могу
>  >> себе такое представить на хранилище, откуда работают сотни виртуальных
>  >> машин, но на файлопомойке?
>  >> 
>  > Видимо, там большая файлопомойка с большим числом пользователей.
>  > Пользователи, как правило, не создают контент.
>  > Потому, файлы (и, тем более, блоки) часто дублируются.
> 
> На файлопомойках пользователи как раз обычно создают контент. Если не
> сам контент целиком, то выборка-то у всех разная. И для 50-кратного
> дублирования надо устраивать очень специфический набор пользователей. Я
> бы, пожалуй, взялся только роботами такое обеспечить, причем специально
> криво написанными.
> 
Возможно.

>  >> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
>  >> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
>  >> 15). Но не в 50.
>  >>
>  > Ещё неплохо, чтобы дедупликация делалась на клиенте.
> 
> Тут, кстати, палка как минимум о двух концах. Я, например, дома
> предпочитаю, чтобы отобранные фотографии из поездок хранились отдельно
> от совпадающих с ними файлов из подборки оригиналов даже в бэкапе. Из
> соображений "в случае сбоя диска будет второй экземпляр". Если сделать
> полную дедупликацию, сбой диска убьет единственный.
> 
Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в
целом, я считаю, подход неправильный.
Надёжность хранилища должна нижним уровнем обеспечиваться.
Явно не прикладным, на котором работает система резервного копирования.

Re: Backup

>  >>  > Касательно проверок: как это делается?
>  >>  > На практике, там где это было, как проводится такая проверка в
>  >>  > существующей инфраструктуре?
>  >> 
>  >> Тупо и цинично. Берется специальная тренировочная машина, типа с пустым
>  >> диском (обычно виртуалка, но по возможности иногда и на железе стоит
>  >> прогнать), и на нее выполняется регламент восстановления. Если не
>  >> сработал - все бросаем, чиним, корректируем регламент.
>  >> 
>  >> Если речь идет о восстановлении пользовательских данных, а не всей
>  >> системы, то машина берется не пустая, а с установленной ОС. В этом
>  >> случае регламент восстановления должен включать установку необходимого
>  >> софта поверх базовой установки ОС (буде он нужен), если он еще не
>  >> установлен. Это тоже надо проверять, а то разное может получиться.
>  >> 
>  > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
>  > основной инфраструктуры ради проверки восстановления не прерывается.
> 
> Вообще говоря, возможны ситуации, когда приходится прерывать. Потому что
> оценить результат восстановления можно только протестировав, что все
> документированные функции целевой машины работают. А у нее могут быть
> сетевые сервисы, которые надо проверить по тому самому имени. Для чего
> "учебная" машина должна подменить в сети "боевую".
> 
> Тут можно в разных местах проводить границу, и получать разную степень
> уверенности в результате. Если, скажем, восстанавливается какой-нибудь
> трекер (веб-морда плюс база плюс почта), то можно в регламент
> восстановления включить часть "для учебной тревоги", где расписать
> перенастройку на тестовое имя хоста и на тестовый вариант рассылки по
> почте (что утраивает работу по написанию регламента и в полтора-два раза
> увеличивает работу по учебной тревоге). Но, скажем, проверить
> работоспособность восстановленного домен-контроллера виндовой сети без
> замены им настоящего я бы вот так вот сходу не взялся, так что надо
> приходить ночью, когда никого нет, и выключать настоящий.
> 
Это для весьма крупных сетей, а небольшая частна локалка, думаю,
обойдётся без проверки перенастроек после бэкапа (тестовую машину
возможно будет выделить, в принципе).

Re: Backup



20.02.2018 18:10, Коротаев Руслан пишет:
> В сообщении от [Вт 2018-02-20 16:34 +0200]
> Dmitry Nezhevenko  пишет:
> 
>> Нет. Это не Page Cache. Память уходит на внутренние индексы restic и
>> растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry
>> Pi сейчас невозможно забэкапить на терабайтный репозиторий. 
>>
>> Но планы починить это у авторов есть.
> 
>> prune по умолчанию не использует кэш. Он чем-то похож на git repack
>> (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
>> весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
>> SSD. 
> 
> Ясно. Тогда остаюсь на Minio, хотел использовать restic для шифрования,
> но видимо придется подождать когда они всё допилят.
> 
Почему вы используете Minio, как хранилище?
Почему вообще объектное хранилище?

Re: Backup

2018-02-20 Пенетрантность Коротаев Руслан



19.02.2018 13:58, Dmitry Nezhevenko пишет:
> On Sat, Feb 17, 2018 at 11:29:16PM +0300, artiom wrote:
>>>
>> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
>> ней не слышал. С ней есть какие-то проблемы?
> 
> Использую сейчас restic для бэкапа пары ноутбуков плюс домашнего NAS.
> Файлы достаточно сильно пересекаются, так что дедупликация очень сильно
> экономит место (репозиторий около 1.5 TB, до этого пользовался
> rdiff-backup и в сумме получалось около 2.5 TB). И это при том что restic
> не умеет сжатие. Вообще никак. 
> 
> Из плюсов что увидел для себя:
> 
> 1. Дедупликация. Это действительно очень удобно. До этого пытался руками
> отслеживать 'общие' каталоги на разных устройствах. Теперь это всё
> происходит автоматом. Экономится и трафик (если большой файл есть на двух
> хостах, то в хранилище его зальет кто-то один). Дедупликация на блочном
> уровне, так что нет никаких проблем с переименованием/перемещением файлов,
> нет проблем с образами виртуалок.
> 
> 2. Нет понятия полного/инкрементального бэкапа. Все они равноценные. По
> сети всегда гоняются только новые блоки.
> 
> 3. Все данные и метаданные у restic с контрольными суммами. 'restic check
> --read-data' может подтвердить, что бэкап полностью целый и с него 100%
> что можно восстановиться. 
> 
> 4. Стореджем может быть что угодно (sftp, webdav, всякие s3, backblaze).
> Сервера, как такового, нет. 
> 
> Минусы:
> 
> 1. Оно очень сильно кушает RAM на клиенте. При чем потребление
> пропорционально общему размеру репозитория. Для моих 1.5TB данных это
> около 4GB RAM при бэкапе.
> 
> 2. Не умеет бэкапить ACL, extended attributes.
> 
> 3 Удаление ненужных бэкапов (точнее prune, освобождение места после них) --
> штука медленная и, опять же, кушающая много RAM. При этом во время prune
> никто не может бэкапиться в этот же репозиторий.
> 
> 4. Ключи шифрования одни на все хосты (в общем случае любой хост может
> прочитать бэкапы 'соседей'). Если сильно нужно и бэкап на 'свой' сервер,
> то решается с помощью rest-server --append-only.
> 
> 5. Восстановление с помощью 'restic restore' очень медленное. Но есть fuse
> mount, который просто показывает бэкапы в виде иерархии host/дата.
> 
> Я для себя решил что мне более важен удобный backup чем restore. 
> 
Ok, спасибо, принял к сведению.
Любопытно, а в составе какого-нибудь BackupPC его возможно использовать?

Re: Backup

В сообщении от [Вт 2018-02-20 17:51 +0200]
Dmitry Nezhevenko  пишет:

> А при чем тут minio? restic -- средство бэкапа, а minio -- просто
> хранилище файлов.

Не только, ещё есть клиент [1], можно легко перемещать данные между
облаками, но нет шифрования и снапшотов как в restic.

[1]: https://docs.minio.io/docs/minio-client-quickstart-guide

-- 
Коротаев Руслан
https://blog.kr.pp.ru


smime.p7s
Description: S/MIME cryptographic signature

Re: Backup

2018-02-20 Пенетрантность Dmitry Nezhevenko

On Tue, Feb 20, 2018 at 08:10:24PM +0500, Коротаев Руслан wrote:
> > prune по умолчанию не использует кэш. Он чем-то похож на git repack
> > (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
> > весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
> > SSD. 
> 
> Ясно. Тогда остаюсь на Minio, хотел использовать restic для шифрования,
> но видимо придется подождать когда они всё допилят.
> 

А при чем тут minio? restic -- средство бэкапа, а minio -- просто
хранилище файлов.
 
-- 
WBR, Dmitry


signature.asc
Description: PGP signature

Re: Backup

2018-02-20 Пенетрантность Коротаев Руслан

В сообщении от [Вт 2018-02-20 16:34 +0200]
Dmitry Nezhevenko  пишет:

> Нет. Это не Page Cache. Память уходит на внутренние индексы restic и
> растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry
> Pi сейчас невозможно забэкапить на терабайтный репозиторий. 
> 
> Но планы починить это у авторов есть.

> prune по умолчанию не использует кэш. Он чем-то похож на git repack
> (пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
> весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
> SSD. 

Ясно. Тогда остаюсь на Minio, хотел использовать restic для шифрования,
но видимо придется подождать когда они всё допилят.

-- 
Коротаев Руслан
https://blog.kr.pp.ru


smime.p7s
Description: S/MIME cryptographic signature

Re: Backup

2018-02-20 Пенетрантность Dmitry Nezhevenko

On Tue, Feb 20, 2018 at 07:10:24PM +0500, Коротаев Руслан wrote:
> Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите вывод
> команды free, если память потребляется за счет buff/cache, то всё в
> порядке. У меня на виртуалке крутится Minio (прога схожая по
> функциональности с restic и также написана Go), почти вся память уходит
> в Page Cache.

Нет. Это не Page Cache. Память уходит на внутренние индексы restic и
растет с ростом репозитория. Грубо говоря что-то мелкое вродее Raspberry
Pi сейчас невозможно забэкапить на терабайтный репозиторий. 

Но планы починить это у авторов есть.

> > Ключи шифрования одни на все хосты (в общем случае любой хост может
> > прочитать бэкапы 'соседей'). 
> 
> Можно сделать репозиторий под каждый хост, но тогда теряются
> преимущества дедупликации. С точки зрения S3 и Minio, репозиторий это
> просто bucket, мне кажется здесь нужно найти компромисс между
> безопасностью и удобством.

Именно так. В моём случае всё бэкапится на отдельный жесткий диск в
домашнем NAS. При этом хранилище расшарено используя rest-server с
ключиком --append-only ( https://github.com/restic/rest-server ). В таком
случае даже имея ключ/пароль можно только дописывать данные. Прочитать/удалить 
ничего нельзя. 

Все другие операции (prune, восстановление) я делаю на самом NAS, указывая
в качестве репозитория каталог на диске.

Ну а по крону хранилище синхронизируется с облаком (backblaze).

> 
> > Удаление ненужных бэкапов (точнее prune, освобождение места после них)
> > -- штука медленная...  Восстановление с помощью 'restic restore' очень
> > медленное. 
> 
> На сайте restic сказано [1], что он хранит временные файлы и кэш в
> директориях по умолчанию, но их можно переназначить. Было бы интересно
> заменить их на SSD-диск и посмотреть насколько улучшилась
> производительность (конечно если у вас есть такая возможность).

prune по умолчанию не использует кэш. Он чем-то похож на git repack
(пересоздает pack файлы, выкидывая оттуда ненужные blob-ы). Учитывая, что
весь индекс сейчас загружается в RAM, я не вижу, чем ему поможет кэш на
SSD. 

-- 
WBR, Dmitry

signature.asc
Description: PGP signature

Re: Backup

2018-02-20 Пенетрантность Коротаев Руслан

В сообщении от [Пн 2018-02-19 12:58 +0200]
Dmitry Nezhevenko  пишет:

> Оно очень сильно кушает RAM на клиенте. При чем потребление
> пропорционально общему размеру репозитория. Для моих 1.5TB данных это
> около 4GB RAM при бэкапе.

Спасибо, хороший обзор. Вопрос: а может это Page Cache? Посмотрите вывод
команды free, если память потребляется за счет buff/cache, то всё в
порядке. У меня на виртуалке крутится Minio (прога схожая по
функциональности с restic и также написана Go), почти вся память уходит
в Page Cache.

> Ключи шифрования одни на все хосты (в общем случае любой хост может
> прочитать бэкапы 'соседей'). 

Можно сделать репозиторий под каждый хост, но тогда теряются
преимущества дедупликации. С точки зрения S3 и Minio, репозиторий это
просто bucket, мне кажется здесь нужно найти компромисс между
безопасностью и удобством.

> Удаление ненужных бэкапов (точнее prune, освобождение места после них)
> -- штука медленная...  Восстановление с помощью 'restic restore' очень
> медленное. 

На сайте restic сказано [1], что он хранит временные файлы и кэш в
директориях по умолчанию, но их можно переназначить. Было бы интересно
заменить их на SSD-диск и посмотреть насколько улучшилась
производительность (конечно если у вас есть такая возможность).

[1]: https://restic.readthedocs.io/en/stable/manual_rest.html

-- 
Коротаев Руслан
https://blog.kr.pp.ru


smime.p7s
Description: S/MIME cryptographic signature

Re: Backup

2018-02-19 Пенетрантность Artem Chuprina

Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 19 Feb 2018 14:38:14 
+0300:

 >>  > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
 >>  > основной инфраструктуры ради проверки восстановления не
 >>  > прерывается.  
 >> 
 >> Вообще говоря, возможны ситуации, когда приходится прерывать. Потому
 >> что оценить результат восстановления можно только протестировав, что
 >> все документированные функции целевой машины работают. А у нее могут
 >> быть сетевые сервисы, которые надо проверить по тому самому имени.
 >> Для чего "учебная" машина должна подменить в сети "боевую".

 > А я вот подумал - а не дешевле ли будет подсунуть учебной
 > восстанавливаемой машине учебный интернет с учебными DNS-ами и учебным
 > mx-ом? Ну и парочкой учебных рабочих станций, куда админ после
 > восстановления может зайти и обратиться ко всем сервисам, которые надо.

 > Понятно, что это тоже излишние трудозатраты на учебную тревогу. Зато
 > результаты работы проверяются корректно, а учебная сеть делается один
 > раз на все бэкапимые машины.

Вариант, ага.

Re: Backup

2018-02-19 Пенетрантность Victor Wagner

On Sun, 18 Feb 2018 23:34:56 +0300
Artem Chuprina  wrote:

>  > В общем-то я это и хотел услышать. Есть "учебная" машина. Работа
>  > основной инфраструктуры ради проверки восстановления не
>  > прерывается.  
> 
> Вообще говоря, возможны ситуации, когда приходится прерывать. Потому
> что оценить результат восстановления можно только протестировав, что
> все документированные функции целевой машины работают. А у нее могут
> быть сетевые сервисы, которые надо проверить по тому самому имени.
> Для чего "учебная" машина должна подменить в сети "боевую".

А я вот подумал - а не дешевле ли будет подсунуть учебной
восстанавливаемой машине учебный интернет с учебными DNS-ами и учебным
mx-ом? Ну и парочкой учебных рабочих станций, куда админ после
восстановления может зайти и обратиться ко всем сервисам, которые надо.

Понятно, что это тоже излишние трудозатраты на учебную тревогу. Зато
результаты работы проверяются корректно, а учебная сеть делается один
раз на все бэкапимые машины.

--

Re: Backup

2018-02-19 Пенетрантность Dmitry Nezhevenko

On Sat, Feb 17, 2018 at 11:29:16PM +0300, artiom wrote:
> >
> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
> ней не слышал. С ней есть какие-то проблемы?

Использую сейчас restic для бэкапа пары ноутбуков плюс домашнего NAS.
Файлы достаточно сильно пересекаются, так что дедупликация очень сильно
экономит место (репозиторий около 1.5 TB, до этого пользовался
rdiff-backup и в сумме получалось около 2.5 TB). И это при том что restic
не умеет сжатие. Вообще никак.

Из плюсов что увидел для себя:

1. Дедупликация. Это действительно очень удобно. До этого пытался руками
отслеживать 'общие' каталоги на разных устройствах. Теперь это всё
происходит автоматом. Экономится и трафик (если большой файл есть на двух
хостах, то в хранилище его зальет кто-то один). Дедупликация на блочном
уровне, так что нет никаких проблем с переименованием/перемещением файлов,
нет проблем с образами виртуалок.

2. Нет понятия полного/инкрементального бэкапа. Все они равноценные. По
сети всегда гоняются только новые блоки.

3. Все данные и метаданные у restic с контрольными суммами. 'restic check
--read-data' может подтвердить, что бэкап полностью целый и с него 100%
что можно восстановиться.

4. Стореджем может быть что угодно (sftp, webdav, всякие s3, backblaze).
Сервера, как такового, нет.

Минусы:

1. Оно очень сильно кушает RAM на клиенте. При чем потребление
пропорционально общему размеру репозитория. Для моих 1.5TB данных это
около 4GB RAM при бэкапе.

2. Не умеет бэкапить ACL, extended attributes.

3 Удаление ненужных бэкапов (точнее prune, освобождение места после них) --
штука медленная и, опять же, кушающая много RAM. При этом во время prune
никто не может бэкапиться в этот же репозиторий.

4. Ключи шифрования одни на все хосты (в общем случае любой хост может
прочитать бэкапы 'соседей'). Если сильно нужно и бэкап на 'свой' сервер,
то решается с помощью rest-server --append-only.

5. Восстановление с помощью 'restic restore' очень медленное. Но есть fuse
mount, который просто показывает бэкапы в виде иерархии host/дата.

Я для себя решил что мне более важен удобный backup чем restore.

--
WBR, Dmitry

signature.asc
Description: PGP signature

Re: Backup

2018-02-18 Пенетрантность Artem Chuprina

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. Которого я в глаза не видел.

 >>  >>  >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
 >>  >>  >> понимать, что первое, что тут требуется - это дисциплина. Не такая, 
 >> как
 >>  >>  >> при работе в архиве, но все же изрядная.
 >>  >>  > Она мне, в принципе, требуется.
 >>  >>  > В плане организации я пытаюсь сейчас всё постепенно рассортировать
 >>  >>  > (сейчас закончил

Re: Backup

2018-02-18 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sun, 18 Feb 2018 21:23:52 +0300:

 >>  >>  >>  >> - rsync поддерживает использование ssh как транспорт, 
 >> существуют так же
 >>  >>  >>  >> надстройки разные
 >>  >>  >>  >> 
 >>  >>  >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
 >>  >>  >>  > придётся всё доделывать самостоятельно, а в той же Bacula 
 >> большинство
 >>  >>  >>  > функций реализовано и отлажено.
 >>  >>  >> 
 >>  >>  >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". 
 >> Это всё так
 >>  >>  >>  >> абстрактно...
 >>  >>  >>  >> 
 >>  >>  >>  > 1. Шифрование бэкапов.
 >>  >>  >>  > 2. Репликация в выбранное облако (например, dropbox).
 >>  >>  >> 
 >>  >>  >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное 
 >> шифрование.
 >>  >>  >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
 >>  >>  >>  > репликацию/наличие API спросить не могу.
 >>  >>  >> 
 >>  >>  >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
 >>  >>  >> сети", и "восстанавливать за разумное время" - выберите любые два из
 >>  >>  >> трех.
 >>  >>  > Первые два, но время именно "разумное", я же не говорю "быстро".
 >>  >> 
 >>  >> Я тоже говорю "разумное". Выберите любые два из трех.
 >>  >> 
 >>  > В процессе изучения вопроса я обнаружил, что есть такая технология, как
 >>  > дедупликация на клиенте.
 >>  > И вообще, как ни странно, в случае с файлопомойками, дедап позволяет
 >>  > экономить до 98% дискового пространства.
 >> 
 >> Это, гм, новость. По моим представлениям, дедупликация на файлопомойке
 >> (где вообще-то каждый файл в среднем чуть более чем в одном экземпляре)
 >> дает от силы процентов 10, если она пофайловая, и процентов 20, если
 >> поблочная. А более вероятно - 3 и 5% соответственно. 98% - это надо
 >> чтобы каждый файл (или блок) хранился в среднем в 50 экземплярах. Я могу
 >> себе такое представить на хранилище, откуда работают сотни виртуальных
 >> машин, но на файлопомойке?
 >> 
 > Видимо, там большая файлопомойка с большим числом пользователей.
 > Пользователи, как правило, не создают контент.
 > Потому, файлы (и, тем более, блоки) часто дублируются.

На файлопомойках пользователи как раз обычно создают контент. Если не
сам контент целиком, то выборка-то у всех разная. И для 50-кратного
дублирования надо устраивать очень специфический набор пользователей. Я
бы, пожалуй, взялся только роботами такое обеспечить, причем специально
криво написанными.

 >> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
 >> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
 >> 15). Но не в 50.
 >>
 > Ещё неплохо, чтобы дедупликация делалась на клиенте.

Тут, кстати, палка как минимум о двух концах. Я, например, дома
предпочитаю, чтобы отобранные фотографии из поездок хранились отдельно
от совпадающих с ними файлов из подборки оригиналов даже в бэкапе. Из
соображений "в случае сбоя диска будет второй экземпляр". Если сделать
полную дедупликацию, сбой диска убьет единственный.

Re: Backup

2018-02-18 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sun, 18 Feb 2018 21:36:37 +0300:

 >>  >>  >>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc 
 >> и
 >>  >>  >>  >>> выбранные пользовательские данные.
 >>  >>  >>  >> 
 >>  >>  >>  >> Меня в свое время убедили что не надо экономить те считанные 
 >> гигабайты,
 >>  >>  >>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
 >>  >>  >>  >> восстановления не разбираться если версии конфигурации в /etc 
 >> остались
 >>  >>  >>  >> от чуточку более старых пакетов, чем поставились из 
 >> дистрибутива при
 >>  >>  >>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же 
 >> /usr).
 >>  >>  >>  > Как минимум, две машины (плюс, ещё /opt).
 >>  >>  >>  > В /usr я руками ничего не правлю обычно (за крайне редким 
 >> исключением
 >>  >>  >>  > для Oracle Java на рабочей машине).
 >>  >>  >>  > /var ещё надо бэкапить. Но /usr для чего?
 >>  >>  >> 
 >>  >>  >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав 
 >> бэкап на
 >>  >>  >> чистый диск не получится. Придется ставить систему и накатывать
 >>  >>  >> конфиги. И тут упс... система оказалась поновее, конфиги частично
 >>  >>  >> несовместимы...
 >>  >>  >> 
 >>  >>  > Это не столь серьёзная проблема в моём случае: как правило, система
 >>  >>  > более ли менее новая.
 >>  >> 
 >>  >> Ключевые слова - "более или менее" :)
 >>  > Ok, система достаточно новая. Максимум - месяц без обновлений (это
 >>  > означает, что она не включалась, потому вероятность выхода из строя
 >>  > низка), и как правило, в таком случае я могу себе позволить затратить
 >>  > время на её восстановление. Больше - крайне редкие случаи.
 >> 
 >> Бэкап, с которого восстанавливаемся, может оказаться не офигительно
 >> свежим. Потом, легко забыть забэкапить что-нибудь важное из
 >> /usr/local...
 >> 
 > Если что-то установленное туда я долго не использую, значит оно мне не
 > так и нужно.

У меня там бывают (в /usr/local/sbin) скрипты, которые использую не я, а, 
например, cron...

 >>  >>  >>  >> В общем, анализировать бэкапные решения надо начинать не с "где
 >>  >>  >>  >> хранить" и "какой транспорт использовать" а с "как будет 
 >> выглядеть
 >>  >>  >>  >> процедура восстановления". Причем в двух вариантах 
 >>  >>  >>  >>
 >>  >>  >>  > Да, вообще явного анализа восстановления я не провёл.
 >>  >>  >>  > Неявно, подразумеваю, что буду переустанавливать систему и 
 >> накатывать
 >>  >>  >>  > данные, а не образ.
 >>  >>  >>  > Т.е., мне не требуется "полный бэкап", как это делают с большим 
 >> парком
 >>  >>  >>  > машин.
 >>  >>  >> 
 >>  >>  >> Практика восстановления показывает, что если бэкапятся настройки
 >>  >>  >> системы, то лучше бэкапить всю систему. Восстановление 
 >> работоспособного
 >>  >>  >> состояния получится на порядок быстрее. Пользовательские данные 
 >> можно (и
 >>  >>  >> часто полезно) бэкапить отдельно.
 >>  >>  >> 
 >>  >>  > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
 >>  >>  > Мало того, не всегда мне нужно будет восстанавливать ту же самую
 >>  >>  > систему: на том же железе и в точности с той же конфигурацией, плюс к
 >>  >>  > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся 
 >> Debian.
 >>  >>  > Падение скорости восстановления здесь для меня терпимо.
 >>  >> 
 >>  >> Системы обычно падают в самый неподходящий момент :) И даже если ты
 >>  >> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
 >>  >> прежнюю работоспособную конфигурацию, а потом уже обновлять.
 >>  >> 
 >>  > Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже
 >>  > кем-то решённых).
 >>  > Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
 >>  > (пусть и маленькую).
 >> 
 >>  > Отсюда:
 >> 
 >>  > - Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
 >>  > года не переустанавливалась, редко выключалась, кроме последних лет, и
 >>  > долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
 >>  > заботливо сохранена, и воспроизведётся при каждом полном восстановлении.
 >> 
 >> Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только
 >> конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
 >> быстро восстановиться, если есть бэкап только конфигов, не получится.
 >> 
 > В случае же переустановки, из бэкапа ничего не прилетит.

Очень не факт. Зараза с легкостью может окопаться и в /etc (в случае
винды - системном реестре).

 >> Ну и думай, что дороже: дополнительное дисковое пространство для
 >> хранения бэкапа системы, или твои время и нервы на более сложную
 >> процедуру восстановления.
 >> 
 > С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
 > пространства хранилища, какие-то 50 Гб на машину странно.
 > С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
 > накатил свежую ОС, накатил конфигурацию и пакеты, всё.

Твоих телодвижений больше. "Накатил свежую ОС" - это существенно больше

Re: Backup

>> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
>> ней не слышал. С ней есть какие-то проблемы?
> 
> Я сам его нашел только вчера, но отзывы о нем хорошие, вот например
> известный сервис Backblaze его рекомендует [2].
> 
Любопытно, что рекомендуют, статистику по дискам их я использовал:
сервис серьёзный.

>> Почитал про Minio. Имеет ли смысл? Мне кажется, что в моём случае
>> NextCloud будет лучше?
> 
> Пробуйте всё и выбирайте лучшее, для этого и нужны свободные программы.
> 
> [1]: https://apps.nextcloud.com/apps/audioplayer
> [2]: 
> https://www.backblaze.com/blog/backing-linux-backblaze-b2-duplicity-restic/
> 
Хочется меньше пробовать и сделать, наконец, этот долбаный NAS, чтобы
перейти к другим проектам.

Re: Backup

>  >>  >>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>  >>  >>  >>> выбранные пользовательские данные.
>  >>  >>  >> 
>  >>  >>  >> Меня в свое время убедили что не надо экономить те считанные 
> гигабайты,
>  >>  >>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>  >>  >>  >> восстановления не разбираться если версии конфигурации в /etc 
> остались
>  >>  >>  >> от чуточку более старых пакетов, чем поставились из дистрибутива 
> при
>  >>  >>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же 
> /usr).
>  >>  >>  > Как минимум, две машины (плюс, ещё /opt).
>  >>  >>  > В /usr я руками ничего не правлю обычно (за крайне редким 
> исключением
>  >>  >>  > для Oracle Java на рабочей машине).
>  >>  >>  > /var ещё надо бэкапить. Но /usr для чего?
>  >>  >> 
>  >>  >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап 
> на
>  >>  >> чистый диск не получится. Придется ставить систему и накатывать
>  >>  >> конфиги. И тут упс... система оказалась поновее, конфиги частично
>  >>  >> несовместимы...
>  >>  >> 
>  >>  > Это не столь серьёзная проблема в моём случае: как правило, система
>  >>  > более ли менее новая.
>  >> 
>  >> Ключевые слова - "более или менее" :)
>  > Ok, система достаточно новая. Максимум - месяц без обновлений (это
>  > означает, что она не включалась, потому вероятность выхода из строя
>  > низка), и как правило, в таком случае я могу себе позволить затратить
>  > время на её восстановление. Больше - крайне редкие случаи.
> 
> Бэкап, с которого восстанавливаемся, может оказаться не офигительно
> свежим. Потом, легко забыть забэкапить что-нибудь важное из
> /usr/local...
> 
Если что-то установленное туда я долго не использую, значит оно мне не
так и нужно.

>  >>  >>  >> В общем, анализировать бэкапные решения надо начинать не с "где
>  >>  >>  >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>  >>  >>  >> процедура восстановления". Причем в двух вариантах 
>  >>  >>  >>
>  >>  >>  > Да, вообще явного анализа восстановления я не провёл.
>  >>  >>  > Неявно, подразумеваю, что буду переустанавливать систему и 
> накатывать
>  >>  >>  > данные, а не образ.
>  >>  >>  > Т.е., мне не требуется "полный бэкап", как это делают с большим 
> парком
>  >>  >>  > машин.
>  >>  >> 
>  >>  >> Практика восстановления показывает, что если бэкапятся настройки
>  >>  >> системы, то лучше бэкапить всю систему. Восстановление 
> работоспособного
>  >>  >> состояния получится на порядок быстрее. Пользовательские данные можно 
> (и
>  >>  >> часто полезно) бэкапить отдельно.
>  >>  >> 
>  >>  > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
>  >>  > Мало того, не всегда мне нужно будет восстанавливать ту же самую
>  >>  > систему: на том же железе и в точности с той же конфигурацией, плюс к
>  >>  > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся 
> Debian.
>  >>  > Падение скорости восстановления здесь для меня терпимо.
>  >> 
>  >> Системы обычно падают в самый неподходящий момент :) И даже если ты
>  >> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
>  >> прежнюю работоспособную конфигурацию, а потом уже обновлять.
>  >> 
>  > Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже
>  > кем-то решённых).
>  > Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
>  > (пусть и маленькую).
> 
>  > Отсюда:
> 
>  > - Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
>  > года не переустанавливалась, редко выключалась, кроме последних лет, и
>  > долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
>  > заботливо сохранена, и воспроизведётся при каждом полном восстановлении.
> 
> Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только
> конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
> быстро восстановиться, если есть бэкап только конфигов, не получится.
> 
В случае же переустановки, из бэкапа ничего не прилетит.
Возможно, конечно, бороться "антивирусными" мерами...

> Ну и думай, что дороже: дополнительное дисковое пространство для
> хранения бэкапа системы, или твои время и нервы на более сложную
> процедуру восстановления.
> 
С одной стороны, жалеть на 10 Тб с избыточностью и с дальнейшим ростом
пространства хранилища, какие-то 50 Гб на машину странно.
С другой, я не вижу, чтобы реально усложнилась процедура восстановления:
накатил свежую ОС, накатил конфигурацию и пакеты, всё.
Кроме того,

>  > - В этой старой системе я хочу многое переделать, например дисковую
>  > организацию, что потребует переустановки при сохранении большинства
>  > конфигов.
> 
> Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
> поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
> перегенерировал initrd из чрута до первой перезагрузки, если в разметке
> добавилось что-то новое, драйвера чего в старом initrd отсутствовали.
> 
Там много что надо

Re: Backup



17.02.2018 19:19, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sat, 17 Feb 2018 11:56:37 +0300:
> 
>  >>  >>  >> - rsync поддерживает использование ssh как транспорт, существуют 
> так же
>  >>  >>  >> надстройки разные
>  >>  >>  >> 
>  >>  >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
>  >>  >>  > придётся всё доделывать самостоятельно, а в той же Bacula 
> большинство
>  >>  >>  > функций реализовано и отлажено.
>  >>  >> 
>  >>  >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это 
> всё так
>  >>  >>  >> абстрактно...
>  >>  >>  >> 
>  >>  >>  > 1. Шифрование бэкапов.
>  >>  >>  > 2. Репликация в выбранное облако (например, dropbox).
>  >>  >> 
>  >>  >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное 
> шифрование.
>  >>  >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
>  >>  >>  > репликацию/наличие API спросить не могу.
>  >>  >> 
>  >>  >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
>  >>  >> сети", и "восстанавливать за разумное время" - выберите любые два из
>  >>  >> трех.
>  >>  > Первые два, но время именно "разумное", я же не говорю "быстро".
>  >> 
>  >> Я тоже говорю "разумное". Выберите любые два из трех.
>  >> 
>  > В процессе изучения вопроса я обнаружил, что есть такая технология, как
>  > дедупликация на клиенте.
>  > И вообще, как ни странно, в случае с файлопомойками, дедап позволяет
>  > экономить до 98% дискового пространства.
> 
> Это, гм, новость. По моим представлениям, дедупликация на файлопомойке
> (где вообще-то каждый файл в среднем чуть более чем в одном экземпляре)
> дает от силы процентов 10, если она пофайловая, и процентов 20, если
> поблочная. А более вероятно - 3 и 5% соответственно. 98% - это надо
> чтобы каждый файл (или блок) хранился в среднем в 50 экземплярах. Я могу
> себе такое представить на хранилище, откуда работают сотни виртуальных
> машин, но на файлопомойке?
> 
Видимо, там большая файлопомойка с большим числом пользователей.
Пользователи, как правило, не создают контент.
Потому, файлы (и, тем более, блоки) часто дублируются.

> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
> 15). Но не в 50.
>
Ещё неплохо, чтобы дедупликация делалась на клиенте.

Re: Backup

2018-02-18 Пенетрантность Коротаев Руслан

>  >>  >>  >> - NextCloud
>  >>  >>  > Хотелось бы услышать отзывы, стоит ли его использовать, что оно 
> даёт,
>  >>  >>  > почему называется "облаком", легко ли его интегрировать с той же 
> Bacula
>  >>  >>  > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>  >>  >>  > использовать в составе NAS.
>  >>  >> 
>  >>  >>  >> - SyncThing
>  >>  >>  > Сам уже нашёл.
>  >>  >>  > Хотелось бы о нём услышать отзывы использующих.
>  >>  >>  > По мне: весьма интересная штука.
>  >>  >> 
>  >>  >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не 
> годится.
>  >>  >> 
>  >>  > По каким причинам?
>  >>  > Тут бы неплохо прояснить разницу.
>  >>  > Если из бэкапа требуется доставать отдельные файлы, то границу мне
>  >>  > сложно провести.
>  >> 
>  >> Синхронизатор не отличает намеренное удаление или порчу от
>  >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
>  >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
>  >> засинхронизироваться.
>  >> 
>  > Как отличает система резервного копирования?
>  > Или тоже не отличает, но это компенсируется историей бэкапов?
> 
> Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
> удаляется целиком, либо (если ему повезло оказаться, например, годичным)
> хранится "вечно".
> 
А какова частота полного, декремента и инкремента?

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

>  >>  >> В многолетней практике (man tar, там эта практика еще со времен 
> бэкапов
>  >>  >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
>  >>  >> по временнЫм характеристикам) обычно устраивают комбинированное 
> решение:
>  >>  >> раз в некоторое время гонят полный бэкап, а между ними
>  >>  >> инкрементальный. tar вот даже различает дифференциальный (разница с
>  >>  >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы 
> он
>  >>  >> ни был). Для разумного времени восстановления характерная частота
>  >>  >> полного - раз в месяц, дифференциального - в неделю, инкрементального 
> -
>  >>  >> ежедневно. В результате получается дорого, но не невменяемо дорого.
>  >>  >> 
>  >>  > Любопытно, на основе инструментов, которые тут советовали, возможно это
>  >>  > построить не сильно напрягаясь?
>  >> 
>  >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
>  >> не позволяет, его нужно выкинуть и посмотреть на другой.
>  >> 
>  > Согласен.
>  > Пока не вполне понятно, что из этого выкинуть.
>  > Кроме Bacula, но тут хвалят её форки.
> 
>  >> На глазок, при использовании собственно tar, gpg и любого способа
>  >> копирования такая конструкция собирается за неделю, включая написание
>  >> регламента. Но трафика будет изрядно.
>  >> 
>  > И не вполне портируемо.
> 
> Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на
> винде не будут забэкаплены открытые в данный момент файлы.
> 
Всё-таки, не вижу пока чем хуже urbackup: агенты уже реализованы и
отлажены, web-интерфейс есть, по фичам всё нормально и статей о нём нет
типа "О том, как я неделю вдуплял в BareOS".

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

Re: Backup

В сообщении от [Сб 2018-02-17 23:29 +0300]
artiom  пишет:

> А вот про плеер возможно подробнее?
> Я mpd хочу впилить.

Обычный плеер [1] только в браузере.

> Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
> ней не слышал. С ней есть какие-то проблемы?

Я сам его нашел только вчера, но отзывы о нем хорошие, вот например
известный сервис Backblaze его рекомендует [2].

> Почитал про Minio. Имеет ли смысл? Мне кажется, что в моём случае
> NextCloud будет лучше?

Пробуйте всё и выбирайте лучшее, для этого и нужны свободные программы.

[1]: https://apps.nextcloud.com/apps/audioplayer
[2]: https://www.backblaze.com/blog/backing-linux-backblaze-b2-duplicity-restic/

-- 
Коротаев Руслан
https://blog.kr.pp.ru


smime.p7s
Description: S/MIME cryptographic signature

Re: Backup

2018-02-17 Пенетрантность artiom



17.02.2018 13:29, Коротаев Руслан пишет:
> В сообщении от [Пт 2018-02-16 20:52 +0300]
> artiom  пишет:
> 
>> Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки?
> 
> Nextcloud? Да, конечно. Он всё-в-одном, не нужно носить с собой ноутбук,
> у меня там почта, RSS-читалка, музыкальный плеер, контакты, календарь.
> Для меня это мобильное рабочее место, нужен только браузер
> (двухфакторная аутентификация тоже есть). 
> 
А вот про плеер возможно подробнее?
Я mpd хочу впилить.

> Плюс приватность, когда вы загружаете файлы в публичный сервис, то они
> уже не только ваши, но и чьи-то ещё. Но в Nextcloud есть плагин «внешние
> хранилища», можно дополнительно подключить Dropbox, Amazon S3 …  
> 
Работа с файлами через внешние хранилища даже не обсуждается: они
исключительно для хранения зашифрованного бэкапа.

>> Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке",
>> когда NAS может предоставить их отдельно (подняв FTP сервер, например)?
> 
> Если у вас NAS специально для бекапов, то наверное нет, всё зависит от
> контекста, здесь сколько людей столько и мнений. Для меня NAS это
> хлопотно (нужно думать какое железо под него купить, RAID или ZFS, а
> вдруг не хватит места и всё такое, да ещё вентилятор шумит), с облаками
> проще, больше вариантов использования [1].
> 
Вентиляторы особо не шумят, место занимает мало, но железо пришлось
выбирать долго и ZFS, тут не о чем думать.
Три основные задачи:

- Git.
- Бэкапы.
- Точка синхронизации.

Дополнительно (железо там мощное, пусть работает):

- Закачки.
- DLNA.
- Облако добавилось.
- Возможно, Mumble поставлю.

> Кстати, в этом треде возникла идея разделять синхронизацию и бекап.
> Бекап в отличии от синхронизации имеет дедупликацию, снапшоты,
> шифрование. Я нашел такую прогу — restic [2], он всё это может плюс
> сразу отправляет в облако.
> 
> [1]: https://habrahabr.ru/post/348542/
> [2]: https://restic.net/
> 
Посмотрел про restic: выглядит интересно. Но почему-то я до сих пор о
ней не слышал. С ней есть какие-то проблемы?

Почитал про Minio. Имеет ли смысл? Мне кажется, что в моём случае
NextCloud будет лучше?

Re: Backup

2018-02-17 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sat, 17 Feb 2018 10:39:21 +0300:

 >>  >>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
 >>  >>  >>> выбранные пользовательские данные.
 >>  >>  >> 
 >>  >>  >> Меня в свое время убедили что не надо экономить те считанные 
 >> гигабайты,
 >>  >>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
 >>  >>  >> восстановления не разбираться если версии конфигурации в /etc 
 >> остались
 >>  >>  >> от чуточку более старых пакетов, чем поставились из дистрибутива при
 >>  >>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
 >>  >>  > Как минимум, две машины (плюс, ещё /opt).
 >>  >>  > В /usr я руками ничего не правлю обычно (за крайне редким исключением
 >>  >>  > для Oracle Java на рабочей машине).
 >>  >>  > /var ещё надо бэкапить. Но /usr для чего?
 >>  >> 
 >>  >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
 >>  >> чистый диск не получится. Придется ставить систему и накатывать
 >>  >> конфиги. И тут упс... система оказалась поновее, конфиги частично
 >>  >> несовместимы...
 >>  >> 
 >>  > Это не столь серьёзная проблема в моём случае: как правило, система
 >>  > более ли менее новая.
 >> 
 >> Ключевые слова - "более или менее" :)
 > Ok, система достаточно новая. Максимум - месяц без обновлений (это
 > означает, что она не включалась, потому вероятность выхода из строя
 > низка), и как правило, в таком случае я могу себе позволить затратить
 > время на её восстановление. Больше - крайне редкие случаи.

Бэкап, с которого восстанавливаемся, может оказаться не офигительно
свежим. Потом, легко забыть забэкапить что-нибудь важное из
/usr/local...

 >>  >>  >> В общем, анализировать бэкапные решения надо начинать не с "где
 >>  >>  >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
 >>  >>  >> процедура восстановления". Причем в двух вариантах 
 >>  >>  >>
 >>  >>  > Да, вообще явного анализа восстановления я не провёл.
 >>  >>  > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
 >>  >>  > данные, а не образ.
 >>  >>  > Т.е., мне не требуется "полный бэкап", как это делают с большим 
 >> парком
 >>  >>  > машин.
 >>  >> 
 >>  >> Практика восстановления показывает, что если бэкапятся настройки
 >>  >> системы, то лучше бэкапить всю систему. Восстановление работоспособного
 >>  >> состояния получится на порядок быстрее. Пользовательские данные можно (и
 >>  >> часто полезно) бэкапить отдельно.
 >>  >> 
 >>  > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
 >>  > Мало того, не всегда мне нужно будет восстанавливать ту же самую
 >>  > систему: на том же железе и в точности с той же конфигурацией, плюс к
 >>  > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся 
 >> Debian.
 >>  > Падение скорости восстановления здесь для меня терпимо.
 >> 
 >> Системы обычно падают в самый неподходящий момент :) И даже если ты
 >> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
 >> прежнюю работоспособную конфигурацию, а потом уже обновлять.
 >> 
 > Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже
 > кем-то решённых).
 > Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
 > (пусть и маленькую).

 > Отсюда:

 > - Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
 > года не переустанавливалась, редко выключалась, кроме последних лет, и
 > долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
 > заботливо сохранена, и воспроизведётся при каждом полном восстановлении.

Не "есть риск", а "есть гарантия". Однако, в такой ситуации взять только
конфиги из полного бэкапа можно. А вот взять полную систему, чтобы
быстро восстановиться, если есть бэкап только конфигов, не получится.

Ну и думай, что дороже: дополнительное дисковое пространство для
хранения бэкапа системы, или твои время и нервы на более сложную
процедуру восстановления.

 > - В этой старой системе я хочу многое переделать, например дисковую
 > организацию, что потребует переустановки при сохранении большинства
 > конфигов.

Переустановки-то зачем? Переразметил диск иначе, накатил полный бэкап,
поправил один-единственный /etc/fstab, и поехали. Ну, может быть, еще
перегенерировал initrd из чрута до первой перезагрузки, если в разметке
добавилось что-то новое, драйвера чего в старом initrd отсутствовали.

 >>  >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
 >>  >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
 >>  >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
 >>  >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
 >>  >> квалификацией админа и наличием _регулярно_ времени на эту работу.
 >>  >> 
 >>  > Насколько регулярно и насколько велик объём донастройки?
 >> 
 >> Мне пока не доводилось работать в таком месте, где работодатель считал
 >> бы, что это ему по карману :)
 >> 
 > Если я

Re: Backup

2018-02-17 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sat, 17 Feb 2018 11:16:16 +0300:

 >>  >>  >> - git-annex - то, что и можно предположить: костыль над гитом.
 >>  >>  > `Git's man page calls it "a stupid content tracker". With git-annex, 
 >> git
 >>  >>  > is instead "a stupid filename and metadata" tracker. The contents of
 >>  >>  > annexed files are not stored in git, only the names of the files and
 >>  >>  > some other metadata remain there.`
 >>  >> 
 >>  >>  > Насколько проще с этим будет работать, чем с Bacula?
 >>  >>  > Насколько переносимо и отлажено?
 >>  >>  > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
 >>  >>  > пока не ясно (к примеру, централизованного управления и интеграции в
 >>  >>  > web-интерфейс там, пожалуй, нет).
 >>  >> 
 >>  >> Не путаем бэкап с архивом. Для бэкапа не годится.
 >>  >> 
 >>  > По каким причинам?
 >> 
 >> Требует архивной дисциплины. Я использовал его, ага.
 >> 
 > git-annex?

Да. Архивные, т.е. _не изменяющиеся_, здоровенные бинарники, с
отслеживанием, где и сколько их копий, и комментированием, где что за
хрень. Он придуман для этой задачи, и ее выполняет хорошо.

Потом как-то продолбал дисциплину архивной работы, и теперь уже поди
найди хотя бы один репозиторий, где вся эта информация...

 >>  >>  >> - NextCloud
 >>  >>  > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
 >>  >>  > почему называется "облаком", легко ли его интегрировать с той же 
 >> Bacula
 >>  >>  > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
 >>  >>  > использовать в составе NAS.
 >>  >> 
 >>  >>  >> - SyncThing
 >>  >>  > Сам уже нашёл.
 >>  >>  > Хотелось бы о нём услышать отзывы использующих.
 >>  >>  > По мне: весьма интересная штука.
 >>  >> 
 >>  >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
 >>  >> 
 >>  > По каким причинам?
 >>  > Тут бы неплохо прояснить разницу.
 >>  > Если из бэкапа требуется доставать отдельные файлы, то границу мне
 >>  > сложно провести.
 >> 
 >> Синхронизатор не отличает намеренное удаление или порчу от
 >> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
 >> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
 >> засинхронизироваться.
 >> 
 > Как отличает система резервного копирования?
 > Или тоже не отличает, но это компенсируется историей бэкапов?

Именно. Предыдущий бэкап не изменяется. Либо по мере устаревания
удаляется целиком, либо (если ему повезло оказаться, например, годичным)
хранится "вечно".

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

Минус простота настройки.

 >>  >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
 >>  >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
 >>  >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
 >>  >> раз в некоторое время гонят полный бэкап, а между ними
 >>  >> инкрементальный. tar вот даже различает дифференциальный (разница с
 >>  >> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
 >>  >> ни был). Для разумного времени восстановления характерная частота
 >>  >> полного - раз в месяц, дифференциального - в неделю, инкрементального -
 >>  >> ежедневно. В результате получается дорого, но не невменяемо дорого.
 >>  >> 
 >>  > Любопытно, на основе инструментов, которые тут советовали, возможно это
 >>  > построить не сильно напрягаясь?
 >> 
 >> Скажем так. Если инструмент, заявленный как инструмент для бэкапа, этого
 >> не позволяет, его нужно выкинуть и посмотреть на другой.
 >> 
 > Согласен.
 > Пока не вполне понятно, что из этого выкинуть.
 > Кроме Bacula, но тут хвалят её форки.

 >> На глазок, при использовании собственно tar, gpg и любого способа
 >> копирования такая конструкция собирается за неделю, включая написание
 >> регламента. Но трафика будет изрядно.
 >> 
 > И не вполне портируемо.

Вполне портируемо. Ну, нерутованные андроиды и айфоны не осилят. И на
винде не будут забэкаплены открытые в данный момент файлы.

 >>  >> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
 >>  >> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
 >>  >> при работе в архиве, но

Re: Backup

2018-02-17 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sat, 17 Feb 2018 11:56:37 +0300:

 >>  >>  >> - rsync поддерживает использование ssh как транспорт, существуют 
 >> так же
 >>  >>  >> надстройки разные
 >>  >>  >> 
 >>  >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
 >>  >>  > придётся всё доделывать самостоятельно, а в той же Bacula большинство
 >>  >>  > функций реализовано и отлажено.
 >>  >> 
 >>  >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это 
 >> всё так
 >>  >>  >> абстрактно...
 >>  >>  >> 
 >>  >>  > 1. Шифрование бэкапов.
 >>  >>  > 2. Репликация в выбранное облако (например, dropbox).
 >>  >> 
 >>  >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное 
 >> шифрование.
 >>  >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
 >>  >>  > репликацию/наличие API спросить не могу.
 >>  >> 
 >>  >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
 >>  >> сети", и "восстанавливать за разумное время" - выберите любые два из
 >>  >> трех.
 >>  > Первые два, но время именно "разумное", я же не говорю "быстро".
 >> 
 >> Я тоже говорю "разумное". Выберите любые два из трех.
 >> 
 > В процессе изучения вопроса я обнаружил, что есть такая технология, как
 > дедупликация на клиенте.
 > И вообще, как ни странно, в случае с файлопомойками, дедап позволяет
 > экономить до 98% дискового пространства.

Это, гм, новость. По моим представлениям, дедупликация на файлопомойке
(где вообще-то каждый файл в среднем чуть более чем в одном экземпляре)
дает от силы процентов 10, если она пофайловая, и процентов 20, если
поблочная. А более вероятно - 3 и 5% соответственно. 98% - это надо
чтобы каждый файл (или блок) хранился в среднем в 50 экземплярах. Я могу
себе такое представить на хранилище, откуда работают сотни виртуальных
машин, но на файлопомойке?

Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной
политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук
15). Но не в 50.

 > В моём случае, даже если 20% я сэкономлю - уже неплохо, но только не
 > средствами ZFS.

Re: Backup

2018-02-17 Пенетрантность artiom

>  >>  >> - rsync поддерживает использование ssh как транспорт, существуют так 
> же
>  >>  >> надстройки разные
>  >>  >> 
>  >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
>  >>  > придётся всё доделывать самостоятельно, а в той же Bacula большинство
>  >>  > функций реализовано и отлажено.
>  >> 
>  >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё 
> так
>  >>  >> абстрактно...
>  >>  >> 
>  >>  > 1. Шифрование бэкапов.
>  >>  > 2. Репликация в выбранное облако (например, dropbox).
>  >> 
>  >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное 
> шифрование.
>  >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
>  >>  > репликацию/наличие API спросить не могу.
>  >> 
>  >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
>  >> сети", и "восстанавливать за разумное время" - выберите любые два из
>  >> трех.
>  > Первые два, но время именно "разумное", я же не говорю "быстро".
> 
> Я тоже говорю "разумное". Выберите любые два из трех.
> 
В процессе изучения вопроса я обнаружил, что есть такая технология, как
дедупликация на клиенте.
И вообще, как ни странно, в случае с файлопомойками, дедап позволяет
экономить до 98% дискового пространства.
В моём случае, даже если 20% я сэкономлю - уже неплохо, но только не
средствами ZFS.

Re: Backup

2018-02-17 Пенетрантность artiom



17.02.2018 00:35, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 22:25:22 +0300:
> 
>  >>  >> - git-annex - то, что и можно предположить: костыль над гитом.
>  >>  > `Git's man page calls it "a stupid content tracker". With git-annex, 
> git
>  >>  > is instead "a stupid filename and metadata" tracker. The contents of
>  >>  > annexed files are not stored in git, only the names of the files and
>  >>  > some other metadata remain there.`
>  >> 
>  >>  > Насколько проще с этим будет работать, чем с Bacula?
>  >>  > Насколько переносимо и отлажено?
>  >>  > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
>  >>  > пока не ясно (к примеру, централизованного управления и интеграции в
>  >>  > web-интерфейс там, пожалуй, нет).
>  >> 
>  >> Не путаем бэкап с архивом. Для бэкапа не годится.
>  >> 
>  > По каким причинам?
> 
> Требует архивной дисциплины. Я использовал его, ага.
> 
git-annex?

>  >>  >> - SparkleShare - что-то весьма минималистичное
>  >>  > Неслабо минималистичное: свой Dropbox.
>  >>  > Правда, в качестве хранилища по умолчанию - git.
>  >>  > Интересная штука, но у меня пока слабое представление о том, что с ней
>  >>  > возможно сделать,  решит ли это мои задачи.
>  >> 
>  >> Вообще, должен сказать, что существующие системы контроля версий с
>  >> задачами бэкапа довольно плохо совместимы. Поскольку по построению
>  >> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
>  >> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
>  >> небольшую выборку, а промежуточные состояния периодически удалять.
>  >> 
>  > Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то
>  > так) для внешнего хранения бинарей: они тоже могли реализовать своё
>  > бинарное хранилище, как модуль гита.
> 
> Я поэтому довольно осторожно сказал "плохо", а не "несовместимы". По
> поводу конкретно гита нагуглилось такое:
> 
> https://www.perforce.com/blog/storing-large-binary-files-in-git-repositories
> 
> По косому взгляду, для задач бэкапа одно другого хуже.
> 
Ну да, их много (правда, я думал, что меньше).
И нужны они всё-таки для задач разработки.
Бэкап тут за уши притянут, не спорю.

>  >>  >> - NextCloud
>  >>  > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>  >>  > почему называется "облаком", легко ли его интегрировать с той же Bacula
>  >>  > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>  >>  > использовать в составе NAS.
>  >> 
>  >>  >> - SyncThing
>  >>  > Сам уже нашёл.
>  >>  > Хотелось бы о нём услышать отзывы использующих.
>  >>  > По мне: весьма интересная штука.
>  >> 
>  >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
>  >> 
>  > По каким причинам?
>  > Тут бы неплохо прояснить разницу.
>  > Если из бэкапа требуется доставать отдельные файлы, то границу мне
>  > сложно провести.
> 
> Синхронизатор не отличает намеренное удаление или порчу от
> ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
> отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
> засинхронизироваться.
> 
Как отличает система резервного копирования?
Или тоже не отличает, но это компенсируется историей бэкапов?

>  >>  >> - rsync поддерживает использование ssh как транспорт, существуют так 
> же
>  >>  >> надстройки разные
>  >>  >> 
>  >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
>  >>  > придётся всё доделывать самостоятельно, а в той же Bacula большинство
>  >>  > функций реализовано и отлажено.
>  >> 
>  >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё 
> так
>  >>  >> абстрактно...
>  >>  >> 
>  >>  > 1. Шифрование бэкапов.
>  >>  > 2. Репликация в выбранное облако (например, dropbox).
>  >> 
>  >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное 
> шифрование.
>  >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
>  >>  > репликацию/наличие API спросить не могу.
>  >> 
>  >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
>  >> сети", и "восстанавливать за разумное время" - выберите любые два из
>  >> трех.
>  > Первые два, но время именно "разумное", я же не говорю "быстро".
> 
> Я тоже говорю "разумное". Выберите любые два из трех.
> 
Все три: "отправлять зашифрованное" я могу параллельно с созданием
бэкапа (места должно хватить, плюс снэпшоты ZFS).

>  >> Инкрементальный бэкап, который обеспечивает tar и основные
>  >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
>  >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
>  >> как у rsync, второе и третье ценой невозможности первого. Первое и
>  >> третье можно делать, гоняя каждый раз полный бэкап.
>  >>
>  > Вы не вполне верно поняли требование, либо я не точно выразился.
>  > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
>  > (облако).
>  > Шифровать отдельно при хранении в

Re: Backup



17.02.2018 00:50, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 21:54:34 +0300:
> 
>  >>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>  >>  >>> выбранные пользовательские данные.
>  >>  >> 
>  >>  >> Меня в свое время убедили что не надо экономить те считанные 
> гигабайты,
>  >>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>  >>  >> восстановления не разбираться если версии конфигурации в /etc остались
>  >>  >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>  >>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>  >>  > Как минимум, две машины (плюс, ещё /opt).
>  >>  > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>  >>  > для Oracle Java на рабочей машине).
>  >>  > /var ещё надо бэкапить. Но /usr для чего?
>  >> 
>  >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
>  >> чистый диск не получится. Придется ставить систему и накатывать
>  >> конфиги. И тут упс... система оказалась поновее, конфиги частично
>  >> несовместимы...
>  >> 
>  > Это не столь серьёзная проблема в моём случае: как правило, система
>  > более ли менее новая.
> 
> Ключевые слова - "более или менее" :)
Ok, система достаточно новая. Максимум - месяц без обновлений (это
означает, что она не включалась, потому вероятность выхода из строя
низка), и как правило, в таком случае я могу себе позволить затратить
время на её восстановление. Больше - крайне редкие случаи.

> 
>  >>  >> В общем, анализировать бэкапные решения надо начинать не с "где
>  >>  >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>  >>  >> процедура восстановления". Причем в двух вариантах 
>  >>  >>
>  >>  > Да, вообще явного анализа восстановления я не провёл.
>  >>  > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
>  >>  > данные, а не образ.
>  >>  > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
>  >>  > машин.
>  >> 
>  >> Практика восстановления показывает, что если бэкапятся настройки
>  >> системы, то лучше бэкапить всю систему. Восстановление работоспособного
>  >> состояния получится на порядок быстрее. Пользовательские данные можно (и
>  >> часто полезно) бэкапить отдельно.
>  >> 
>  > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
>  > Мало того, не всегда мне нужно будет восстанавливать ту же самую
>  > систему: на том же железе и в точности с той же конфигурацией, плюс к
>  > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся 
> Debian.
>  > Падение скорости восстановления здесь для меня терпимо.
> 
> Системы обычно падают в самый неподходящий момент :) И даже если ты
> давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
> прежнюю работоспособную конфигурацию, а потом уже обновлять.
> 
Ok. С этим я согласен. Но остаётся несколько проблем (наверняка уже
кем-то решённых).
Бэкап-систему я внедряю не с нуля, а в действующую "инфраструктуру"
(пусть и маленькую).

Отсюда:

- Если какая-то дрянь сейчас поселилась в системе (а система с 2011-го
года не переустанавливалась, редко выключалась, кроме последних лет, и
долго подключена к Интернет), есть риск, что она пойдёт в бэкап, будет
заботливо сохранена, и воспроизведётся при каждом полном восстановлении.
- В этой старой системе я хочу многое переделать, например дисковую
организацию, что потребует переустановки при сохранении большинства
конфигов.

Как решаются эти проблемы?
Надо ли мне, в таком случае, делать полный бэкап?

>  >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
>  >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
>  >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
>  >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
>  >> квалификацией админа и наличием _регулярно_ времени на эту работу.
>  >> 
>  > Насколько регулярно и насколько велик объём донастройки?
> 
> Мне пока не доводилось работать в таком месте, где работодатель считал
> бы, что это ему по карману :)
> 
Если я делаю для себя, читается, как: "Ты не будешь этим заниматься"?

> Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
> на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
> и набор пакетов привел меня к выводу, что потребуется специальный
> бэкап-админ как минимум на полставки. Кончилось регламентом на базе
> tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
> виртуалки с виндой.
> 
А форки, которые здесь рекламируют?
http://www.urbackup.org/
https://time404.ru/1776/

> Ну, то есть, конторы, где эти или подобные технологии применялись, я
> видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
> раз - только потому, что у меня был еще и свой бэкап.
> 
Но ведь система специально заточена под бэкап, долго живёт и развивается.
Почему не было успешно её применение?

Re: Backup

2018-02-16 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 21:54:34 +0300:

 >>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
 >>  >>> выбранные пользовательские данные.
 >>  >> 
 >>  >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
 >>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
 >>  >> восстановления не разбираться если версии конфигурации в /etc остались
 >>  >> от чуточку более старых пакетов, чем поставились из дистрибутива при
 >>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
 >>  > Как минимум, две машины (плюс, ещё /opt).
 >>  > В /usr я руками ничего не правлю обычно (за крайне редким исключением
 >>  > для Oracle Java на рабочей машине).
 >>  > /var ещё надо бэкапить. Но /usr для чего?
 >> 
 >> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
 >> чистый диск не получится. Придется ставить систему и накатывать
 >> конфиги. И тут упс... система оказалась поновее, конфиги частично
 >> несовместимы...
 >> 
 > Это не столь серьёзная проблема в моём случае: как правило, система
 > более ли менее новая.

Ключевые слова - "более или менее" :)

 >>  >> В общем, анализировать бэкапные решения надо начинать не с "где
 >>  >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
 >>  >> процедура восстановления". Причем в двух вариантах 
 >>  >>
 >>  > Да, вообще явного анализа восстановления я не провёл.
 >>  > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
 >>  > данные, а не образ.
 >>  > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
 >>  > машин.
 >> 
 >> Практика восстановления показывает, что если бэкапятся настройки
 >> системы, то лучше бэкапить всю систему. Восстановление работоспособного
 >> состояния получится на порядок быстрее. Пользовательские данные можно (и
 >> часто полезно) бэкапить отдельно.
 >> 
 > Хорошо, но зачем мне 50+ Гб того, что я и так получу?
 > Мало того, не всегда мне нужно будет восстанавливать ту же самую
 > систему: на том же железе и в точности с той же конфигурацией, плюс к
 > этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
 > Падение скорости восстановления здесь для меня терпимо.

Системы обычно падают в самый неподходящий момент :) И даже если ты
давно хотел ее обновить, выгоднее сначала тупо, но быстро восстановить
прежнюю работоспособную конфигурацию, а потом уже обновлять.

 >> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
 >> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
 >> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
 >> машин и есть человек, который регулярно подкручивает эту конструкцию. С
 >> квалификацией админа и наличием _регулярно_ времени на эту работу.
 >> 
 > Насколько регулярно и насколько велик объём донастройки?

Мне пока не доводилось работать в таком месте, где работодатель считал
бы, что это ему по карману :)

Когда я в свое время разрабатывал регламент бэкапов для своей конторы, я
на бакулу и рдифф-бэкап тоже глянул. Косой взгляд на документацию бакулы
и набор пакетов привел меня к выводу, что потребуется специальный
бэкап-админ как минимум на полставки. Кончилось регламентом на базе
tar. Там был тот еще зоопарк, включая аппаратный спарк с солярисом и
виртуалки с виндой.

Ну, то есть, конторы, где эти или подобные технологии применялись, я
видел, а вот чтобы успешно - нет. К счастью, по мне это не било. Один
раз - только потому, что у меня был еще и свой бэкап.

Со своих "велосипедных" бэкапов восстанавливаться несколько раз
приходилось. Однажды полностью, и несколько раз вытаскивать из прошлых
бэкапов пользовательские файлы.

Re: Backup

2018-02-16 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 22:25:22 +0300:

 >>  >> - git-annex - то, что и можно предположить: костыль над гитом.
 >>  > `Git's man page calls it "a stupid content tracker". With git-annex, git
 >>  > is instead "a stupid filename and metadata" tracker. The contents of
 >>  > annexed files are not stored in git, only the names of the files and
 >>  > some other metadata remain there.`
 >> 
 >>  > Насколько проще с этим будет работать, чем с Bacula?
 >>  > Насколько переносимо и отлажено?
 >>  > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
 >>  > пока не ясно (к примеру, централизованного управления и интеграции в
 >>  > web-интерфейс там, пожалуй, нет).
 >> 
 >> Не путаем бэкап с архивом. Для бэкапа не годится.
 >> 
 > По каким причинам?

Требует архивной дисциплины. Я использовал его, ага.

 >>  >> - SparkleShare - что-то весьма минималистичное
 >>  > Неслабо минималистичное: свой Dropbox.
 >>  > Правда, в качестве хранилища по умолчанию - git.
 >>  > Интересная штука, но у меня пока слабое представление о том, что с ней
 >>  > возможно сделать,  решит ли это мои задачи.
 >> 
 >> Вообще, должен сказать, что существующие системы контроля версий с
 >> задачами бэкапа довольно плохо совместимы. Поскольку по построению
 >> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
 >> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
 >> небольшую выборку, а промежуточные состояния периодически удалять.
 >> 
 > Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то
 > так) для внешнего хранения бинарей: они тоже могли реализовать своё
 > бинарное хранилище, как модуль гита.

Я поэтому довольно осторожно сказал "плохо", а не "несовместимы". По
поводу конкретно гита нагуглилось такое:

https://www.perforce.com/blog/storing-large-binary-files-in-git-repositories

По косому взгляду, для задач бэкапа одно другого хуже.

 >>  >> - NextCloud
 >>  > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
 >>  > почему называется "облаком", легко ли его интегрировать с той же Bacula
 >>  > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
 >>  > использовать в составе NAS.
 >> 
 >>  >> - SyncThing
 >>  > Сам уже нашёл.
 >>  > Хотелось бы о нём услышать отзывы использующих.
 >>  > По мне: весьма интересная штука.
 >> 
 >> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
 >> 
 > По каким причинам?
 > Тут бы неплохо прояснить разницу.
 > Если из бэкапа требуется доставать отдельные файлы, то границу мне
 > сложно провести.

Синхронизатор не отличает намеренное удаление или порчу от
ненамеренного, и аккуратно его синхронизирует. Из синхронизатора, в
отличие от бэкапа, нельзя достать файлы, которые были испорчены и успели
засинхронизироваться.

 >>  >> - rsync поддерживает использование ssh как транспорт, существуют так же
 >>  >> надстройки разные
 >>  >> 
 >>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
 >>  > придётся всё доделывать самостоятельно, а в той же Bacula большинство
 >>  > функций реализовано и отлажено.
 >> 
 >>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
 >>  >> абстрактно...
 >>  >> 
 >>  > 1. Шифрование бэкапов.
 >>  > 2. Репликация в выбранное облако (например, dropbox).
 >> 
 >>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное 
 >> шифрование.
 >>  > Т.к. раньше я ими не пользовался, ничего конкретного про
 >>  > репликацию/наличие API спросить не могу.
 >> 
 >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
 >> сети", и "восстанавливать за разумное время" - выберите любые два из
 >> трех.
 > Первые два, но время именно "разумное", я же не говорю "быстро".

Я тоже говорю "разумное". Выберите любые два из трех.

 >> Инкрементальный бэкап, который обеспечивает tar и основные
 >> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
 >> первое и второй ценой невозможности третьего. Обратный инкрементальный,
 >> как у rsync, второе и третье ценой невозможности первого. Первое и
 >> третье можно делать, гоняя каждый раз полный бэкап.
 >>
 > Вы не вполне верно поняли требование, либо я не точно выразился.
 > Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
 > (облако).
 > Шифровать отдельно при хранении в NAS, не требуется.

Я понял. Я как бы намекаю, что при бэкапе на NAS и в облако имеет смысл,
вообще-то, выбирать разные два из трех. Но, естественно, получатся
разные технологии бэкапа :)

 >> В многолетней практике (man tar, там эта практика еще со времен бэкапов
 >> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
 >> по временнЫм характеристикам) обычно устраивают комбинированное решение:
 >> раз в некоторое время гонят полный бэкап, а между ними
 >> инкрементальный. tar вот даже различает дифференциальный (разница с
 >> предыдущим полным) и инкрементальный (разница с предыдущим, каким

Re: Backup



16.02.2018 10:39, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 08:25:39 +0300:
> 
>  >> - git-annex - то, что и можно предположить: костыль над гитом.
>  > `Git's man page calls it "a stupid content tracker". With git-annex, git
>  > is instead "a stupid filename and metadata" tracker. The contents of
>  > annexed files are not stored in git, only the names of the files and
>  > some other metadata remain there.`
> 
>  > Насколько проще с этим будет работать, чем с Bacula?
>  > Насколько переносимо и отлажено?
>  > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
>  > пока не ясно (к примеру, централизованного управления и интеграции в
>  > web-интерфейс там, пожалуй, нет).
> 
> Не путаем бэкап с архивом. Для бэкапа не годится.
> 
По каким причинам?

>  >> - SparkleShare - что-то весьма минималистичное
>  > Неслабо минималистичное: свой Dropbox.
>  > Правда, в качестве хранилища по умолчанию - git.
>  > Интересная штука, но у меня пока слабое представление о том, что с ней
>  > возможно сделать,  решит ли это мои задачи.
> 
> Вообще, должен сказать, что существующие системы контроля версий с
> задачами бэкапа довольно плохо совместимы. Поскольку по построению
> хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
> со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
> небольшую выборку, а промежуточные состояния периодически удалять.
> 
Тут не вполне верно. Гит же достаточно гибкий. Есть git-binary (как-то
так) для внешнего хранения бинарей: они тоже могли реализовать своё
бинарное хранилище, как модуль гита.

>  >> - NextCloud
>  > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>  > почему называется "облаком", легко ли его интегрировать с той же Bacula
>  > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>  > использовать в составе NAS.
> 
>  >> - SyncThing
>  > Сам уже нашёл.
>  > Хотелось бы о нём услышать отзывы использующих.
>  > По мне: весьма интересная штука.
> 
> Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.
> 
По каким причинам?
Тут бы неплохо прояснить разницу.
Если из бэкапа требуется доставать отдельные файлы, то границу мне
сложно провести.

>  >> - rsync поддерживает использование ssh как транспорт, существуют так же
>  >> надстройки разные
>  >> 
>  > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
>  > придётся всё доделывать самостоятельно, а в той же Bacula большинство
>  > функций реализовано и отлажено.
> 
>  >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
>  >> абстрактно...
>  >> 
>  > 1. Шифрование бэкапов.
>  > 2. Репликация в выбранное облако (например, dropbox).
> 
>  > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное 
> шифрование.
>  > Т.к. раньше я ими не пользовался, ничего конкретного про
>  > репликацию/наличие API спросить не могу.
> 
> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
> сети", и "восстанавливать за разумное время" - выберите любые два из
> трех.
Первые два, но время именно "разумное", я же не говорю "быстро".

> Инкрементальный бэкап, который обеспечивает tar и основные
> продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
> первое и второй ценой невозможности третьего. Обратный инкрементальный,
> как у rsync, второе и третье ценой невозможности первого. Первое и
> третье можно делать, гоняя каждый раз полный бэкап.
>
Вы не вполне верно поняли требование, либо я не точно выразился.
Шифровать каналы отправки и шифровать при отправке на внешнее хранилище
(облако).
Шифровать отдельно при хранении в NAS, не требуется.

> В многолетней практике (man tar, там эта практика еще со времен бэкапов
> на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
> по временнЫм характеристикам) обычно устраивают комбинированное решение:
> раз в некоторое время гонят полный бэкап, а между ними
> инкрементальный. tar вот даже различает дифференциальный (разница с
> предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
> ни был). Для разумного времени восстановления характерная частота
> полного - раз в месяц, дифференциального - в неделю, инкрементального -
> ежедневно. В результате получается дорого, но не невменяемо дорого.
> 
Любопытно, на основе инструментов, которые тут советовали, возможно это
построить не сильно напрягаясь?

> Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
> понимать, что первое, что тут требуется - это дисциплина. Не такая, как
> при работе в архиве, но все же изрядная.
Она мне, в принципе, требуется.
В плане организации я пытаюсь сейчас всё постепенно рассортировать
(сейчас закончил только с музыкой и видео, проекты в нормальном
состоянии, книги и документы в процессе сортировки).
Поэтому, что бэкапить, я могу сказать.

> "Результатом автоматизации
> бардака может быть только автоматизированный бардак." В нее, в
> частности,

Re: Backup



15.02.2018 23:31, grey.fenrir пишет:
> 02/15/2018 10:59 PM, artiom пишет:
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
> borgbackup весьма хорош
В Automating backups они предлагают написать bash скрипт.
На скринкасте вижу шифрование, простую работу со снимками архивов и
красивую строку прогресса (в принципе, мне не нужна, я хочу запускать
агенты автоматически и не видеть их работы).
В чём ещё принципиальное отличие от rsync?

>>
>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>> возможно Android планшет.
> работает на macos, порты на win и android были, не знаю, в каком они
> сейчас состоянии.
Скорее всего, требуют неслабой допилки руками.

>>
>> - Должна быть потенциальная возможность репликации в облако (куда, пока
>> не знаю, потому должна быть возможность гибко настроить) с шифрованием
>> бэкапов.
> смотря что в облаке. Если в облако есть возможность поставить серверную
> часть - всё просто. Если это облачное хранилище - тоже просто, но
> вероятнее всего медленно.
> 
Считаю, что это облачное хранилище.
Схема такова:

- Постоянный бэкап на NAS.
- Шифрование.
- Периодическая (раз в месяц, например) загрузка избранных участков в
облачное хранилище.

>> - Должно быть простое централизованное управление бэкапами (в идеале,
>> интеграция в web-интерфейс).
> вебморду к этому тоже пилили, но я не проверял, мне в терминале проще.
> 
>> - Минимум ручной допилки и сложной настройки на сервере.
> весьма дружелюбен
> 
> ps: Отзывы по borg'у собираю.
> 
> ---
> Тарас aka L0ki
>

Re: Backup



16.02.2018 13:38, Михаил Касаджиков пишет:
> artiom <artio...@yandex.ru> писал(а) в своём письме Thu, 15 Feb 2018
> 22:59:07 +0300:
> 
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
>>
>> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
>> Основные машины - PC с Debian и ноут с Debian.
>> Ноут преимущественно подключен через Интернет, PC в локальной сети.
> 
> Я использую backup-manager и скрипт-обвязку для LVN snapshot.
> У меня всё кроме /boot — на LVM. При запуске скрипта происходит следующее:
> 1. создаём lvm snapshot для желаемых разделов;
> 2. монтируем эти снимки в /mnt/root, /mnt/home и тд.;
> 3. монтируем сетевое хранилище в /mnt/backup;
> 4. запускаем backup-manager;
> 5. демонтируем снимки и хранилище;
> 6. убираем снапшоты.
> 
Сразу нет: LVM только на Linux и то не обязательно, а значит я получаю
непортируемое решение.
Кроме того, с двухдисковой конфигурацией LVM всё несколько сложнее.

> Сам backup-manager — обычный bash-скрипт, использующий tar, или dar,
> который делает:
> * добавляет нужные имена архивам;
> * следит за созданием master/increment архивов;
> * удаляет старые архивы:
> * шифрует, при желании, с помощью gpg;
> * заливает архивы на удалённый сервер;
> * …
> 
В итоге, снова я получаю привязку клиента к ОС.
Ладно - сервер. С этим всё ok, но клиента привязывать не хочется.

> На выходе получаем набор архивов, которые нужно последовательно
> распаковать. Если в компе помер винт — нужно его разметить, создать LVM,
> разделы, ФС, смонтировать всё это и последовательно распаковать архивы
> до желаемого момента. Несколько раз уже восстанавливал как отдельные
> файлы, так и машины полностью.
> 
> Пакет в репе так и называется — backup-manager.
> 
>

Re: Backup



16.02.2018 09:13, Сергей Цаболов пишет:
> Доброе утро!
> 
> Я сказал бы что  есть довольное хорошее решение
> 
> https://serveradmin.ru/backup-linux-servera-s-pomoshhyu-duplicity/
> 
Почитал статью, и не понял, что хотел сказать автор.
В начале он rsync упоминает.
Переехал ли он на duplicity, и в чём основная разница с rsync?

> Но  я считаю  что Bareos это лучшее решение.
> 
> Допустим https://time404.ru/1776/
> 
> Главное не все так как описывают со старыми версиями было по другому.
> 
Да, тут ещё хвалили вот это, как лучшую альтернативу BareOS:
http://www.urbackup.org/
https://blog.kr.pp.ru/post/2017-07-25/


> 
> 15.02.2018 22:59, artiom пишет:
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
>>
>> Склоняюсь к следующим вариантам:
>>
>> - Bacula.
>> - BackupPC.
>> - Решения на базе rsync.
>>
>> Изо всего работал только с rsync, о Bacula имею представление, а
>> BackupPC мне неизвестен.
>>
>> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
>> Основные машины - PC с Debian и ноут с Debian.
>> Ноут преимущественно подключен через Интернет, PC в локальной сети.
>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>> возможно Android планшет.
>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> выбранные пользовательские данные.
>>
>> Резервное копирование хотелось бы выполнять:
>> - По расписанию.
>> - По запросу.
>> - При пропуске предыдущего.
>>
>> Условия:
>>
>> - Все каналы должны быть зашифрованы.
>> - Копирование не должно занимать много времени (используется Интернет).
>> - Должна быть потенциальная возможность репликации в облако (куда, пока
>> не знаю, потому должна быть возможность гибко настроить) с шифрованием
>> бэкапов.
>> - Должно быть простое централизованное управление бэкапами (в идеале,
>> интеграция в web-интерфейс).
>> - Минимум ручной допилки и сложной настройки на сервере.
>>
> 
> -- 
> 
> Сергей Цаболов,
> Системный администратор.
> 
> serg...@art-design.ru
> 
> 125009, г. Москва, М. Гнездниковский пер., д. 9, стр. 1
> 
> +7 (495) 956-34-79 (доб. 226)
> 
> «Арт и Дизайн» - Наш мир ОТКРЫТ Каждому
> 
> www.artd.ru <http://www.artd.ru/>
> 
> logo <http://www.artd.ru/>
>

Re: Backup



16.02.2018 10:55, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 08:43:17 +0300:
> 
>  > Кроме того, rsync использует жёсткие ссылки, не на всех ФС есть.
> 
> Он их использует только на бэкап-сервере. Если же их нет на его ФС, то
> вопрос в непрофильную рассылку :)
> 
Да верно, он же дедупликацию на приёмнике таким образом делает.

>  >>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>  >>> возможно Android планшет.
>  >> 
>  >> Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил
>  >> ntfsclone способом "перегрузился в linux, создал клон". Но это для
>  >> ситуации когда пользовательские данные в ней не хранятся. 
>  >> 
>  > А может всё-таки Bacula, NextCloud, etc.?
> 
> Этот вопрос надо задавать тем, кто ими пользуется...
> 
Здесь такие есть.

>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>  >>> выбранные пользовательские данные.
>  >> 
>  >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>  >> восстановления не разбираться если версии конфигурации в /etc остались
>  >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>  > Как минимум, две машины (плюс, ещё /opt).
>  > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>  > для Oracle Java на рабочей машине).
>  > /var ещё надо бэкапить. Но /usr для чего?
> 
> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
> чистый диск не получится. Придется ставить систему и накатывать
> конфиги. И тут упс... система оказалась поновее, конфиги частично
> несовместимы...
> 
Это не столь серьёзная проблема в моём случае: как правило, система
более ли менее новая.

>  >> В общем, анализировать бэкапные решения надо начинать не с "где
>  >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>  >> процедура восстановления". Причем в двух вариантах 
>  >>
>  > Да, вообще явного анализа восстановления я не провёл.
>  > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
>  > данные, а не образ.
>  > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
>  > машин.
> 
> Практика восстановления показывает, что если бэкапятся настройки
> системы, то лучше бэкапить всю систему. Восстановление работоспособного
> состояния получится на порядок быстрее. Пользовательские данные можно (и
> часто полезно) бэкапить отдельно.
> 
Хорошо, но зачем мне 50+ Гб того, что я и так получу?
Мало того, не всегда мне нужно будет восстанавливать ту же самую
систему: на том же железе и в точности с той же конфигурацией, плюс к
этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
Падение скорости восстановления здесь для меня терпимо.

>  >> 1. Сдох жесткий диск, вставляем новый
>  >> 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
>  >> файл, который еще в прошлую субботу точно был.
>  >> 
>  >> Вот по части второго решения на базе rsync вне конкуренции.
>  >> 
>  > А Bacula или OwnCloud чем хуже?
> 
>  > Ещё несколько пунктов для которых процесс восстановления может различаться:
>  > 3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо
>  > восстановить одно из промежуточных состояний.
>  > 4. Большое количество пользовательских данных оказались повреждены (не
>  > ОС, с ней всё в порядке, а то, на что пользователь имеет права).
>  > 5. Требуется восстановить часть данных с одного устройства на другом (с
>  > целью синхронизации, например).
> 
> При вменяемой системе бэкапа все три пункта - это одно и то же. "Надо
> восстановить такое-то место данных за прошлую субботу, а такое - за
> позапрошлый понедельник. Ой, нет, за понедельник не то, давайте
> попробуем за среду."
> 
Так у меня было на rdiff-backup реализовано, но достаточно медленно
(инкрементальные бэкапы), к тому же, восстановлением таким образом я
пользовался редко.
Хотя, это удобно.
Возможно было заходить в каталоги за день в течение месяца, плюс
использовалось сжатие на базе fuse-compress.
Минус был в несколько сложной настройке. Кроме того, изредка бэкапилка
ломалась, приходилось разбираться (к тому, что не хочется снова делать
своё велосипед, лучше взять промышленно изготовленный).

> Решение с обратно-инкрементальным бэкапом на базе rsync дает этот
> результат бесплатно. Остальные - смотр

Re: Backup

> Hexawolf -> debian-russian@lists.debian.org  @ Thu, 15 Feb 2018 23:28:13 
> +0200:
> 
>  > Ещё варианты:
> 
>  > - git-annex - то, что и можно предположить: костыль над гитом.
>  > - SparkleShare - что-то весьма минималистичное
>  > - NextCloud
>  > - SyncThing
>  > - rsync поддерживает использование ssh как транспорт, существуют так же
>  > надстройки разные
> 
> Насколько я понимаю, syncthing (пользуюсь) и *Cloud НЕ являются
> средствами резервного копирования. У syncthing это прямо так, помнится,
> и написано. Это средства _синхронизации_. Они не отличают намеренно
> удаленное от продолбанного.
> 
А разве отличают системы резервного копирования?

> git-annex - не система резервного копирования, а архив с
> резервированием. В смысле, для практической пользы от него к нему нужна
> дисциплина работы в архиве.
> 
>  > Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
>  > абстрактно...
> 
>  > On 15/02/18 21:59, artiom wrote:
>  >> Подскажите, чем возможно выполнять резервное копирование нескольких
>  >> машин по сети, чтобы условия ниже были удовлетворены.
>  >> 
>  >> Склоняюсь к следующим вариантам:
>  >> 
>  >> - Bacula.
>  >> - BackupPC.
>  >> - Решения на базе rsync.
>  >> 
>  >> Изо всего работал только с rsync, о Bacula имею представление, а
>  >> BackupPC мне неизвестен.
>  >> 
>  >> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
>  >> Основные машины - PC с Debian и ноут с Debian.
>  >> Ноут преимущественно подключен через Интернет, PC в локальной сети.
>  >> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>  >> возможно Android планшет.
>  >> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>  >> выбранные пользовательские данные.
>  >> 
>  >> Резервное копирование хотелось бы выполнять:
>  >> - По расписанию.
>  >> - По запросу.
>  >> - При пропуске предыдущего.
>  >> 
>  >> Условия:
>  >> 
>  >> - Все каналы должны быть зашифрованы.
>  >> - Копирование не должно занимать много времени (используется Интернет).
>  >> - Должна быть потенциальная возможность репликации в облако (куда, пока
>  >> не знаю, потому должна быть возможность гибко настроить) с шифрованием
>  >> бэкапов.
>  >> - Должно быть простое централизованное управление бэкапами (в идеале,
>  >> интеграция в web-интерфейс).
>  >> - Минимум ручной допилки и сложной настройки на сервере.
>  >> 
>  >> 
>

Re: Backup



16.02.2018 09:48, kuzminov пишет:
> On 16.02.2018 08:25, artiom wrote:
>>
>>
>>
>>> - SyncThing
>> Сам уже нашёл.
>> Хотелось бы о нём услышать отзывы использующих.
>> По мне: весьма интересная штука.
>>
> Это программа для синхронизации папок, а не резервного копирвания. Очень
> простая и работает как ожидается примерно.
> Версионность неудобная, куча файлов создается с другим именем. Находит
> устройства почти сразу через любое подключение. Постоянно пользуюсь на
> всех компах для синхронизации доков и профиля браузера.
> 
В смысле, как находит устройства?

Но я так понял, для моих целей это неприменимо.

> Есть же urbackup с возможностью работать через интернет (с шифрованием),
> поддержой ZFS И btrfs подтомов, дедупликации, создания образов диска
> (под виндой), восстановления поверх голого железа путем загрузки с 
> лайфсд. И все просто работает сразу, в отличии от бареос, для которой
> надо скрипты писать либо кучу конфигов в ручную для каждого клиента.
Клиент-сервер, неплохо.
Не вполне понятно, в чём заключается поддержка ZFS подтомов?
В смысле, что она взаимодействует с ZFS и бэкапит только необходимое (к
примеру, работает со снэпшотами)?
Восстановление на голом железе у меня пока не планируется, для меня это
лишний функционал, дедап тоже не уверен, что нужен: его может обеспечить
ZFS, хотя я и не буду его включать с целью экономии памяти.

Re: Backup

Ага, отлично. Т.е., имеет смысл ставить его независимо от бэкапилки?
Вопрос по протоколам в том, нужны ли все эти FTPS и прочие в "облаке",
когда NAS может предоставить их отдельно (подняв FTP сервер, например)?

16.02.2018 09:06, Коротаев Руслан пишет:
> В сообщении от [Пт 2018-02-16 08:25 +0300]
> artiom  пишет:
> 
>>> - NextCloud
>> Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
>> почему называется "облаком", легко ли его интегрировать с той же Bacula
>> (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
>> использовать в составе NAS.
> 
> Nextcloud удобен, но он больше для совместной работы, а не для бекапов,
> а облаком он называется потому, что может заменить публичные сервисы
> типа Google Drive, Dropbox, то есть работа с файлами, календарь,
> веб-почта и так далее. Для файлов у него есть WebDAV и приложения для
> Android и iOS.
> 
> Можно ещё добавить к списку Minio [1], отличная штука для бекапа (HTTPS,
> веб-интерфейс, S3 API), ну и старый добрый FTP(S).
> 
> [1]: https://blog.kr.pp.ru/post/2017-07-25/
>

Re: Backup

2018-02-16 Пенетрантность Михаил Касаджиков

Спасибо. Посмотрю.
В чём основная разница с Бакулой?

16.02.2018 09:19, Павел Марченко пишет:
> Bareos это форк Бакулы, причем довольно успешный
> 
> 
> 
> 15 февр. 2018 г. 23:46 пользователь "artiom"  > написал:
> 
> > Без допилов только проприетарщина.
> Однозначно - нет.
> Про всякие Veeam я в курсе: не хочу использовать, т.к. имею
> представление о том, что там внутри.
> Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не
> пришлось делать своё "кастомное решение".
> 
> > В остальном Бакула точнее её форк.
> Какой форк?
> 
> >
> > 15 февр. 2018 г. 22:59 пользователь "artiom"  
> > >> написал:
> >
> >     Подскажите, чем возможно выполнять резервное копирование
> нескольких
> >     машин по сети, чтобы условия ниже были удовлетворены.
> >
> >     Склоняюсь к следующим вариантам:
> >
> >     - Bacula.
> >     - BackupPC.
> >     - Решения на базе rsync.
> >
> >     Изо всего работал только с rsync, о Bacula имею представление, а
> >     BackupPC мне неизвестен.
> >
> >     Резервное копирование хочу выполнять на центральное хранилище, с
> >     FreeNAS.
> >     Основные машины - PC с Debian и ноут с Debian.
> >     Ноут преимущественно подключен через Интернет, PC в локальной
> сети.
> >     Также, в перспективе, могут резервироваться машины с Windows и
> MacOS,
> >     возможно Android планшет.
> >     На Debian-based машинах хочу резервировать конфигурацию в /etc и
> >     выбранные пользовательские данные.
> >
> >     Резервное копирование хотелось бы выполнять:
> >     - По расписанию.
> >     - По запросу.
> >     - При пропуске предыдущего.
> >
> >     Условия:
> >
> >     - Все каналы должны быть зашифрованы.
> >     - Копирование не должно занимать много времени (используется
> Интернет).
> >     - Должна быть потенциальная возможность репликации в облако
> (куда, пока
> >     не знаю, потому должна быть возможность гибко настроить) с
> шифрованием
> >     бэкапов.
> >     - Должно быть простое централизованное управление бэкапами (в
> идеале,
> >     интеграция в web-интерфейс).
> >     - Минимум ручной допилки и сложной настройки на сервере.
> >
> 
>

Re: Backup

artiom <artio...@yandex.ru> писал(а) в своём письме Thu, 15 Feb 2018 22:59:07
+0300:

Подскажите, чем возможно выполнять резервное копирование нескольких
машин по сети, чтобы условия ниже были удовлетворены.

Я использую backup-manager и скрипт-обвязку для LVN snapshot.
У меня всё кроме /boot — на LVM. При запуске скрипта происходит следующее:
1. создаём lvm snapshot для желаемых разделов;
2. монтируем эти снимки в /mnt/root, /mnt/home и тд.;
3. монтируем сетевое хранилище в /mnt/backup;
4. запускаем backup-manager;
5. демонтируем снимки и хранилище;
6. убираем снапшоты.

Сам backup-manager — обычный bash-скрипт, использующий tar, или dar, который
делает:
* добавляет нужные имена архивам;
* следит за созданием master/increment архивов;
* удаляет старые архивы:
* шифрует, при желании, с помощью gpg;
* заливает архивы на удалённый сервер;
* …

На выходе получаем набор архивов, которые нужно последовательно распаковать.
Если в компе помер винт — нужно его разметить, создать LVM, разделы, ФС,
смонтировать всё это и последовательно распаковать архивы до желаемого момента.
Несколько раз уже восстанавливал как отдельные файлы, так и машины полностью.

Пакет в репе так и называется — backup-manager.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: Backup

2018-02-16 Пенетрантность kuzminov


On 16.02.2018 08:25, artiom wrote:





- SyncThing

Сам уже нашёл.
Хотелось бы о нём услышать отзывы использующих.
По мне: весьма интересная штука.

Это программа для синхронизации папок, а не резервного копирвания. Очень 
простая и работает как ожидается примерно.
Версионность неудобная, куча файлов создается с другим именем. Находит 
устройства почти сразу через любое подключение. Постоянно пользуюсь на 
всех компах для синхронизации доков и профиля браузера.


Есть же urbackup с возможностью работать через интернет (с шифрованием), 
поддержой ZFS И btrfs подтомов, дедупликации, создания образов диска 
(под виндой), восстановления поверх голого железа путем загрузки с  
лайфсд. И все просто работает сразу, в отличии от бареос, для которой 
надо скрипты писать либо кучу конфигов в ручную для каждого клиента.


thunderbird.desktop
Description: application/desktop

Re: Backup

2018-02-16 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 08:43:17 +0300:

 > Кроме того, rsync использует жёсткие ссылки, не на всех ФС есть.

Он их использует только на бэкап-сервере. Если же их нет на его ФС, то
вопрос в непрофильную рассылку :)

 >>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
 >>> возможно Android планшет.
 >> 
 >> Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил
 >> ntfsclone способом "перегрузился в linux, создал клон". Но это для
 >> ситуации когда пользовательские данные в ней не хранятся. 
 >> 
 > А может всё-таки Bacula, NextCloud, etc.?

Этот вопрос надо задавать тем, кто ими пользуется...

 >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
 >>> выбранные пользовательские данные.
 >> 
 >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
 >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
 >> восстановления не разбираться если версии конфигурации в /etc остались
 >> от чуточку более старых пакетов, чем поставились из дистрибутива при
 >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
 > Как минимум, две машины (плюс, ещё /opt).
 > В /usr я руками ничего не правлю обычно (за крайне редким исключением
 > для Oracle Java на рабочей машине).
 > /var ещё надо бэкапить. Но /usr для чего?

Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
чистый диск не получится. Придется ставить систему и накатывать
конфиги. И тут упс... система оказалась поновее, конфиги частично
несовместимы...

 >> В общем, анализировать бэкапные решения надо начинать не с "где
 >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
 >> процедура восстановления". Причем в двух вариантах 
 >>
 > Да, вообще явного анализа восстановления я не провёл.
 > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
 > данные, а не образ.
 > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
 > машин.

Практика восстановления показывает, что если бэкапятся настройки
системы, то лучше бэкапить всю систему. Восстановление работоспособного
состояния получится на порядок быстрее. Пользовательские данные можно (и
часто полезно) бэкапить отдельно.

 >> 1. Сдох жесткий диск, вставляем новый
 >> 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
 >> файл, который еще в прошлую субботу точно был.
 >> 
 >> Вот по части второго решения на базе rsync вне конкуренции.
 >> 
 > А Bacula или OwnCloud чем хуже?

 > Ещё несколько пунктов для которых процесс восстановления может различаться:
 > 3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо
 > восстановить одно из промежуточных состояний.
 > 4. Большое количество пользовательских данных оказались повреждены (не
 > ОС, с ней всё в порядке, а то, на что пользователь имеет права).
 > 5. Требуется восстановить часть данных с одного устройства на другом (с
 > целью синхронизации, например).

При вменяемой системе бэкапа все три пункта - это одно и то же. "Надо
восстановить такое-то место данных за прошлую субботу, а такое - за
позапрошлый понедельник. Ой, нет, за понедельник не то, давайте
попробуем за среду."

Решение с обратно-инкрементальным бэкапом на базе rsync дает этот
результат бесплатно. Остальные - смотреть надо. Dropbox вот, например
(если говорить об облачных средствах, которые вообще-то синхронизаторы,
а не бэкаперы), насколько я вижу интерфейс, дает доступ к версиям
отдельных файлов, а запросить с него состояние папки на позавчера
невозможно. Это как бы не его задача.

Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
машин и есть человек, который регулярно подкручивает эту конструкцию. С
квалификацией админа и наличием _регулярно_ времени на эту работу.

Re: Backup

2018-02-15 Пенетрантность Artem Chuprina

Victor Wagner -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 07:49:34 
+0300:

 >> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
 >> возможно Android планшет.

 > Вот windows rsync-ом не забэкапишь.

Систему нет, а пользовательские данные еще как.

 > Windows я в свое время бэкапил ntfsclone способом "перегрузился в
 > linux, создал клон". Но это для ситуации когда пользовательские
 > данные в ней не хранятся.

Re: Backup

2018-02-15 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 08:25:39 +0300:

 >> - git-annex - то, что и можно предположить: костыль над гитом.
 > `Git's man page calls it "a stupid content tracker". With git-annex, git
 > is instead "a stupid filename and metadata" tracker. The contents of
 > annexed files are not stored in git, only the names of the files and
 > some other metadata remain there.`

 > Насколько проще с этим будет работать, чем с Bacula?
 > Насколько переносимо и отлажено?
 > По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
 > пока не ясно (к примеру, централизованного управления и интеграции в
 > web-интерфейс там, пожалуй, нет).

Не путаем бэкап с архивом. Для бэкапа не годится.

 >> - SparkleShare - что-то весьма минималистичное
 > Неслабо минималистичное: свой Dropbox.
 > Правда, в качестве хранилища по умолчанию - git.
 > Интересная штука, но у меня пока слабое представление о том, что с ней
 > возможно сделать,  решит ли это мои задачи.

Вообще, должен сказать, что существующие системы контроля версий с
задачами бэкапа довольно плохо совместимы. Поскольку по построению
хранят _всю_ историю, и в случае хранения изменяющихся бинарников пухнут
со страшной силой. А на задачах бэкапа требуется хранить ее сравнительно
небольшую выборку, а промежуточные состояния периодически удалять.

 >> - NextCloud
 > Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
 > почему называется "облаком", легко ли его интегрировать с той же Bacula
 > (агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
 > использовать в составе NAS.

 >> - SyncThing
 > Сам уже нашёл.
 > Хотелось бы о нём услышать отзывы использующих.
 > По мне: весьма интересная штука.

Два последних: не путаем бэкап с синхронизацией. Для бэкапа не годится.

 >> - rsync поддерживает использование ssh как транспорт, существуют так же
 >> надстройки разные
 >> 
 > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
 > придётся всё доделывать самостоятельно, а в той же Bacula большинство
 > функций реализовано и отлажено.

 >> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
 >> абстрактно...
 >> 
 > 1. Шифрование бэкапов.
 > 2. Репликация в выбранное облако (например, dropbox).

 > Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
 > Т.к. раньше я ими не пользовался, ничего конкретного про
 > репликацию/наличие API спросить не могу.

"Тут ведь как..." "Отправлять зашифрованное", "минимально гонять по
сети", и "восстанавливать за разумное время" - выберите любые два из
трех. Инкрементальный бэкап, который обеспечивает tar и основные
продвинутые инкрементальные средства бэкапа, типа той же бакулы, дает
первое и второй ценой невозможности третьего. Обратный инкрементальный,
как у rsync, второе и третье ценой невозможности первого. Первое и
третье можно делать, гоняя каждый раз полный бэкап.

В многолетней практике (man tar, там эта практика еще со времен бэкапов
на магнитные ленты, но "гнать шифрованное в облако" - это примерно оно
по временнЫм характеристикам) обычно устраивают комбинированное решение:
раз в некоторое время гонят полный бэкап, а между ними
инкрементальный. tar вот даже различает дифференциальный (разница с
предыдущим полным) и инкрементальный (разница с предыдущим, каким бы он
ни был). Для разумного времени восстановления характерная частота
полного - раз в месяц, дифференциального - в неделю, инкрементального -
ежедневно. В результате получается дорого, но не невменяемо дорого.

Но вообще, если уж ты собираешься делать бэкапы как следует, то надо
понимать, что первое, что тут требуется - это дисциплина. Не такая, как
при работе в архиве, но все же изрядная. "Результатом автоматизации
бардака может быть только автоматизированный бардак." В нее, в
частности, входит периодическая тренировка восстановления из
бэкапа. Потому что очень легко настроить бэкап, из которого потом не
получится восстановиться.

Re: Backup

2018-02-15 Пенетрантность Artem Chuprina

Hexawolf -> debian-russian@lists.debian.org  @ Thu, 15 Feb 2018 23:28:13 +0200:

 > Ещё варианты:

 > - git-annex - то, что и можно предположить: костыль над гитом.
 > - SparkleShare - что-то весьма минималистичное
 > - NextCloud
 > - SyncThing
 > - rsync поддерживает использование ssh как транспорт, существуют так же
 > надстройки разные

Насколько я понимаю, syncthing (пользуюсь) и *Cloud НЕ являются
средствами резервного копирования. У syncthing это прямо так, помнится,
и написано. Это средства _синхронизации_. Они не отличают намеренно
удаленное от продолбанного.

git-annex - не система резервного копирования, а архив с
резервированием. В смысле, для практической пользы от него к нему нужна
дисциплина работы в архиве.

 > Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
 > абстрактно...

 > On 15/02/18 21:59, artiom wrote:
 >> Подскажите, чем возможно выполнять резервное копирование нескольких
 >> машин по сети, чтобы условия ниже были удовлетворены.
 >> 
 >> Склоняюсь к следующим вариантам:
 >> 
 >> - Bacula.
 >> - BackupPC.
 >> - Решения на базе rsync.
 >> 
 >> Изо всего работал только с rsync, о Bacula имею представление, а
 >> BackupPC мне неизвестен.
 >> 
 >> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
 >> Основные машины - PC с Debian и ноут с Debian.
 >> Ноут преимущественно подключен через Интернет, PC в локальной сети.
 >> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
 >> возможно Android планшет.
 >> На Debian-based машинах хочу резервировать конфигурацию в /etc и
 >> выбранные пользовательские данные.
 >> 
 >> Резервное копирование хотелось бы выполнять:
 >> - По расписанию.
 >> - По запросу.
 >> - При пропуске предыдущего.
 >> 
 >> Условия:
 >> 
 >> - Все каналы должны быть зашифрованы.
 >> - Копирование не должно занимать много времени (используется Интернет).
 >> - Должна быть потенциальная возможность репликации в облако (куда, пока
 >> не знаю, потому должна быть возможность гибко настроить) с шифрованием
 >> бэкапов.
 >> - Должно быть простое централизованное управление бэкапами (в идеале,
 >> интеграция в web-интерфейс).
 >> - Минимум ручной допилки и сложной настройки на сервере.
 >> 
 >>

Re: Backup

2018-02-15 Пенетрантность Павел Марченко

Bareos это форк Бакулы, причем довольно успешный



15 февр. 2018 г. 23:46 пользователь "artiom"  написал:

> Без допилов только проприетарщина.
Однозначно - нет.
Про всякие Veeam я в курсе: не хочу использовать, т.к. имею
представление о том, что там внутри.
Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не
пришлось делать своё "кастомное решение".

> В остальном Бакула точнее её форк.
Какой форк?

>
> 15 февр. 2018 г. 22:59 пользователь "artiom"  > написал:
>
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
>
> Склоняюсь к следующим вариантам:
>
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
>
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
>
> Резервное копирование хочу выполнять на центральное хранилище, с
> FreeNAS.
> Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.
>
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
>
> Условия:
>
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется
Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда,
пока
> не знаю, потому должна быть возможность гибко настроить) с шифрованием
> бэкапов.
> - Должно быть простое централизованное управление бэкапами (в идеале,
> интеграция в web-интерфейс).
> - Минимум ручной допилки и сложной настройки на сервере.
>

Re: Backup

2018-02-15 Пенетрантность Евгений Кабанов

>> Ещё варианты:

luckybackup - надстройка над rsync, при личном использовании -
никаких нареканий; бэкапит, что скажешь.

-- 
Евгений Кабанов

Re: Backup



16.02.2018 07:49, Victor Wagner пишет:
> В Thu, 15 Feb 2018 22:59:07 +0300
> artiom <artio...@yandex.ru> пишет:
> 
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
>>
>> Склоняюсь к следующим вариантам:
>>
>> - Bacula.
>> - BackupPC.
>> - Решения на базе rsync.
>>
>> Изо всего работал только с rsync, о Bacula имею представление, а
>> BackupPC мне неизвестен.
>>
>> Резервное копирование хочу выполнять на центральное хранилище, с
>> FreeNAS. Основные машины - PC с Debian и ноут с Debian.
>> Ноут преимущественно подключен через Интернет, PC в локальной сети.
> 
> Я использую надстройку над rsync, называющуюся rsnapshot.
> Бэкаплю таким образом и домашнюю машину на USB-диск и виртуалку на
> хостинге на домашную машину (по расписанию)
> 
Да, я помню, вы её предлагали, когда я ещё бэкапилку для одной машин делал.
Я тогда rdiff-backup выбрал, но сейчас бы остановился на rsnapshot.
Тем не менее, доделок много придётся сделать. Для чего мне реализовывать
функционал Bacula самому?
Какие плюсы есть у rsnapshot?
Кроме того, rsync использует жёсткие ссылки, не на всех ФС есть.
Да, возможно извратиться, но зачем?

>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>> возможно Android планшет.
> 
> Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил
> ntfsclone способом "перегрузился в linux, создал клон". Но это для
> ситуации когда пользовательские данные в ней не хранятся. 
> 
А может всё-таки Bacula, NextCloud, etc.?

>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> выбранные пользовательские данные.
> 
> Меня в свое время убедили что не надо экономить те считанные гигабайты,
> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
> восстановления не разбираться если версии конфигурации в /etc остались
> от чуточку более старых пакетов, чем поставились из дистрибутива при
> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
Как минимум, две машины (плюс, ещё /opt).
В /usr я руками ничего не правлю обычно (за крайне редким исключением
для Oracle Java на рабочей машине).
/var ещё надо бэкапить. Но /usr для чего?

> 
> В общем, анализировать бэкапные решения надо начинать не с "где
> хранить" и "какой транспорт использовать" а с "как будет выглядеть
> процедура восстановления". Причем в двух вариантах 
>
Да, вообще явного анализа восстановления я не провёл.
Неявно, подразумеваю, что буду переустанавливать систему и накатывать
данные, а не образ.
Т.е., мне не требуется "полный бэкап", как это делают с большим парком
машин.

> 1. Сдох жесткий диск, вставляем новый
> 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
> файл, который еще в прошлую субботу точно был.
> 
> Вот по части второго решения на базе rsync вне конкуренции.
> 
А Bacula или OwnCloud чем хуже?

Ещё несколько пунктов для которых процесс восстановления может различаться:
3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо
восстановить одно из промежуточных состояний.
4. Большое количество пользовательских данных оказались повреждены (не
ОС, с ней всё в порядке, а то, на что пользователь имеет права).
5. Требуется восстановить часть данных с одного устройства на другом (с
целью синхронизации, например).

>>
>> Резервное копирование хотелось бы выполнять:
>> - По расписанию.
>> - По запросу.
>> - При пропуске предыдущего.
>>
>> Условия:
>>
>> - Все каналы должны быть зашифрованы.
>> - Копирование не должно занимать много времени (используется
>> Интернет).
>> - Должна быть потенциальная возможность репликации в облако (куда,
>> пока не знаю, потому должна быть возможность гибко настроить) с
>> шифрованием бэкапов.
> 
> C шифрованием каналов и репликацией в облако вопрос такой - вот у вас
> сдох жесткий диск со всеми ключами. Вам надо восстановиться из бэкапа.
> Каким образом вы будете восстанавливать доступ к тому месту, где лежит
> бэкап, для того чтобы его достать? Обеспечивает ли применяемый в таком
> случае способ аутентификации надежную защиту ваших данных от сценария
> "кто-то прикинулся вами, сломавшим жесткий диск"?
> 
> Опять же шифрованные бэкапы в облаке обычно не слишком удобны для
> второго из вышеописанных сценариев:
> 
> либо для того, чтобы достать один файл вам нужно скачивать весь бэкап
> (а то и цепочку инкрементальных до последнего полного), либо слишком
> много метаинформации доступно владельцу облака (а также
> правоохранительным органам страны, где расположен этот облачный сервер
> и хакерам, взломавшим облачного провайдера).
> 
> Собственно поэтому я бэкаплюсь на внешний диск, лежащий в тумбочке. Там
> все понятно с авторизацией доступа - она физическая.
> 
> в
> 
>

Re: Backup



16.02.2018 00:28, Hexawolf пишет:
> Ещё варианты:
> 
> - git-annex - то, что и можно предположить: костыль над гитом.
`Git's man page calls it "a stupid content tracker". With git-annex, git
is instead "a stupid filename and metadata" tracker. The contents of
annexed files are not stored in git, only the names of the files and
some other metadata remain there.`

Насколько проще с этим будет работать, чем с Bacula?
Насколько переносимо и отлажено?
По функционалу вижу, что шифрует, хранит метаданные в гите, остальное
пока не ясно (к примеру, централизованного управления и интеграции в
web-интерфейс там, пожалуй, нет).

> - SparkleShare - что-то весьма минималистичное
Неслабо минималистичное: свой Dropbox.
Правда, в качестве хранилища по умолчанию - git.
Интересная штука, но у меня пока слабое представление о том, что с ней
возможно сделать,  решит ли это мои задачи.

> - NextCloud
Хотелось бы услышать отзывы, стоит ли его использовать, что оно даёт,
почему называется "облаком", легко ли его интегрировать с той же Bacula
(агентов, я так понимаю, у NextCloud нет), а также имеет ли смысл
использовать в составе NAS.

> - SyncThing
Сам уже нашёл.
Хотелось бы о нём услышать отзывы использующих.
По мне: весьма интересная штука.

> - rsync поддерживает использование ssh как транспорт, существуют так же
> надстройки разные
> 
Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над ним
придётся всё доделывать самостоятельно, а в той же Bacula большинство
функций реализовано и отлажено.

> Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
> абстрактно...
> 
1. Шифрование бэкапов.
2. Репликация в выбранное облако (например, dropbox).

Т.к. dropbox и подобные - одна сплошная дыра, требуется надёжное шифрование.
Т.к. раньше я ими не пользовался, ничего конкретного про
репликацию/наличие API спросить не могу.

> On 15/02/18 21:59, artiom wrote:
>> Подскажите, чем возможно выполнять резервное копирование нескольких
>> машин по сети, чтобы условия ниже были удовлетворены.
>>
>> Склоняюсь к следующим вариантам:
>>
>> - Bacula.
>> - BackupPC.
>> - Решения на базе rsync.
>>
>> Изо всего работал только с rsync, о Bacula имею представление, а
>> BackupPC мне неизвестен.
>>
>> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
>> Основные машины - PC с Debian и ноут с Debian.
>> Ноут преимущественно подключен через Интернет, PC в локальной сети.
>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>> возможно Android планшет.
>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>> выбранные пользовательские данные.
>>
>> Резервное копирование хотелось бы выполнять:
>> - По расписанию.
>> - По запросу.
>> - При пропуске предыдущего.
>>
>> Условия:
>>
>> - Все каналы должны быть зашифрованы.
>> - Копирование не должно занимать много времени (используется Интернет).
>> - Должна быть потенциальная возможность репликации в облако (куда, пока
>> не знаю, потому должна быть возможность гибко настроить) с шифрованием
>> бэкапов.
>> - Должно быть простое централизованное управление бэкапами (в идеале,
>> интеграция в web-интерфейс).
>> - Минимум ручной допилки и сложной настройки на сервере.
>>
>>
>

Re: Backup

2018-02-15 Пенетрантность Victor Wagner

В Thu, 15 Feb 2018 22:59:07 +0300
artiom  пишет:

> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
> 
> Склоняюсь к следующим вариантам:
> 
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
> 
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
> 
> Резервное копирование хочу выполнять на центральное хранилище, с
> FreeNAS. Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.

Я использую надстройку над rsync, называющуюся rsnapshot.
Бэкаплю таким образом и домашнюю машину на USB-диск и виртуалку на
хостинге на домашную машину (по расписанию)

> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.

Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил
ntfsclone способом "перегрузился в linux, создал клон". Но это для
ситуации когда пользовательские данные в ней не хранятся. 

> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.

Меня в свое время убедили что не надо экономить те считанные гигабайты,
которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
восстановления не разбираться если версии конфигурации в /etc остались
от чуточку более старых пакетов, чем поставились из дистрибутива при
восстановлении системы.

В общем, анализировать бэкапные решения надо начинать не с "где
хранить" и "какой транспорт использовать" а с "как будет выглядеть
процедура восстановления". Причем в двух вариантах 

1. Сдох жесткий диск, вставляем новый
2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
файл, который еще в прошлую субботу точно был.

Вот по части второго решения на базе rsync вне конкуренции.

> 
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
> 
> Условия:
> 
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется
> Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда,
> пока не знаю, потому должна быть возможность гибко настроить) с
> шифрованием бэкапов.

C шифрованием каналов и репликацией в облако вопрос такой - вот у вас
сдох жесткий диск со всеми ключами. Вам надо восстановиться из бэкапа.
Каким образом вы будете восстанавливать доступ к тому месту, где лежит
бэкап, для того чтобы его достать? Обеспечивает ли применяемый в таком
случае способ аутентификации надежную защиту ваших данных от сценария
"кто-то прикинулся вами, сломавшим жесткий диск"?

Опять же шифрованные бэкапы в облаке обычно не слишком удобны для
второго из вышеописанных сценариев:

либо для того, чтобы достать один файл вам нужно скачивать весь бэкап
(а то и цепочку инкрементальных до последнего полного), либо слишком
много метаинформации доступно владельцу облака (а также
правоохранительным органам страны, где расположен этот облачный сервер
и хакерам, взломавшим облачного провайдера).

Собственно поэтому я бэкаплюсь на внешний диск, лежащий в тумбочке. Там
все понятно с авторизацией доступа - она физическая.

в


-- 
   Victor Wagner

Re: Backup

2018-02-15 Пенетрантность Hexawolf

Ещё варианты:

- git-annex - то, что и можно предположить: костыль над гитом.
- SparkleShare - что-то весьма минималистичное
- NextCloud
- SyncThing
- rsync поддерживает использование ssh как транспорт, существуют так же
надстройки разные

Ничего не знаю по поводу "репликации в облко с шифрованием". Это всё так
абстрактно...

On 15/02/18 21:59, artiom wrote:
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
> 
> Склоняюсь к следующим вариантам:
> 
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
> 
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
> 
> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
> Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.
> 
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
> 
> Условия:
> 
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда, пока
> не знаю, потому должна быть возможность гибко настроить) с шифрованием
> бэкапов.
> - Должно быть простое централизованное управление бэкапами (в идеале,
> интеграция в web-интерфейс).
> - Минимум ручной допилки и сложной настройки на сервере.
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: Backup

> Без допилов только проприетарщина.
Однозначно - нет.
Про всякие Veeam я в курсе: не хочу использовать, т.к. имею
представление о том, что там внутри.
Минимальные допилки и настройку воспринимаю спокойно, главное, чтобы не
пришлось делать своё "кастомное решение".

> В остальном Бакула точнее её форк.
Какой форк?

> 
> 15 февр. 2018 г. 22:59 пользователь "artiom"  > написал:
> 
> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
> 
> Склоняюсь к следующим вариантам:
> 
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
> 
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
> 
> Резервное копирование хочу выполнять на центральное хранилище, с
> FreeNAS.
> Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.
> 
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
> 
> Условия:
> 
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда, пока
> не знаю, потому должна быть возможность гибко настроить) с шифрованием
> бэкапов.
> - Должно быть простое централизованное управление бэкапами (в идеале,
> интеграция в web-интерфейс).
> - Минимум ручной допилки и сложной настройки на сервере.
>

Re: Backup

2018-02-15 Пенетрантность Павел Марченко

Плюсом сюда идут вопросы, по только что узнанному мной OwnCloud/NextCloud.

В чём разница с Bacula? Имеет смысл?

Re: Backup

2018-02-15 Пенетрантность grey.fenrir

02/15/2018 10:59 PM, artiom пишет:

borgbackup весьма хорош

Также, в перспективе, могут резервироваться машины с Windows и MacOS,
возможно Android планшет.
работает на macos, порты на win и android были, не знаю, в каком они
сейчас состоянии.

- Должна быть потенциальная возможность репликации в облако (куда, пока
не знаю, потому должна быть возможность гибко настроить) с шифрованием
бэкапов.
смотря что в облаке. Если в облако есть возможность поставить серверную
часть - всё просто. Если это облачное хранилище - тоже просто, но
вероятнее всего медленно.

- Должно быть простое централизованное управление бэкапами (в идеале,
интеграция в web-интерфейс).

вебморду к этому тоже пилили, но я не проверял, мне в терминале проще.

- Минимум ручной допилки и сложной настройки на сервере.

весьма дружелюбен

ps: Отзывы по borg'у собираю.

---
Тарас aka L0ki

Re: Backup

Без допилов только проприетарщина. В остальном Бакула точнее её форк.

15 февр. 2018 г. 22:59 пользователь "artiom"  написал:

> Подскажите, чем возможно выполнять резервное копирование нескольких
> машин по сети, чтобы условия ниже были удовлетворены.
>
> Склоняюсь к следующим вариантам:
>
> - Bacula.
> - BackupPC.
> - Решения на базе rsync.
>
> Изо всего работал только с rsync, о Bacula имею представление, а
> BackupPC мне неизвестен.
>
> Резервное копирование хочу выполнять на центральное хранилище, с FreeNAS.
> Основные машины - PC с Debian и ноут с Debian.
> Ноут преимущественно подключен через Интернет, PC в локальной сети.
> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
> возможно Android планшет.
> На Debian-based машинах хочу резервировать конфигурацию в /etc и
> выбранные пользовательские данные.
>
> Резервное копирование хотелось бы выполнять:
> - По расписанию.
> - По запросу.
> - При пропуске предыдущего.
>
> Условия:
>
> - Все каналы должны быть зашифрованы.
> - Копирование не должно занимать много времени (используется Интернет).
> - Должна быть потенциальная возможность репликации в облако (куда, пока
> не знаю, потому должна быть возможность гибко настроить) с шифрованием
> бэкапов.
> - Должно быть простое централизованное управление бэкапами (в идеале,
> интеграция в web-интерфейс).
> - Минимум ручной допилки и сложной настройки на сервере.
>
>

Backup