[DONE] wml://{security/2005/dsa-674.wml}

2018-02-18 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2005/dsa-674.wml 2017-11-01 10:11:09.371782148 +0500
+++ russian/security/2005/dsa-674.wml   2018-02-19 12:36:55.823198894 +0500
@@ -1,47 +1,48 @@
- -cross-site scripting, directory 
traversal
+#use wml::debian::translation-check translation="1.6" maintainer="Lev Lamberov"
+межсайтовый скриптинг, обход 
каталога
 
- -Due to an incompatibility between Python 1.5 and 2.1 the last mailman
- -update did not run with Python 1.5 anymore.  This problem is corrected
- -with this update.  This advisory only updates the packages updated
- -with DSA 674-2.  The version in unstable is not affected since it is
- -not supposed to work with Python 1.5 anymore.  For completeness below
- -is the original advisory text:
+Из-за несовместимости между Python 1.5 и 2.1 
последнее обновление
+mailman более не работает с Python 1.5. Эта 
проблема исправлена
+в данном обновлении. Данная рекомендация 
лишь обновляет пакеты, обновлённые
+с DSA 674-2. Версия в нестабильном выпуске не 
подвержена указанной проблеме,
+поскольку она не предполагает 
использования с Python 1.5. Для полноты 
информации
+ниже приводится текст изначальной 
рекомендации:
 
 
- -Two security related problems have been discovered in mailman,
- -web-based GNU mailing list manager.  The Common Vulnerabilities and
- -Exposures project identifies the following problems:
+В mailman, веб-менеждере списков рассылки от 
проекта GNU, были обнаружены
+две связанные с безопасностью проблемы. 
Проект Common Vulnerabilities and
+Exposures определяет следующие проблемы:
 
 
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1177;>CAN-2004-1177
 
- -Florian Weimer discovered a cross-site scripting vulnerability in
- -mailman's automatically generated error messages.  An attacker
- -could craft a URL containing JavaScript (or other content
- -embedded into HTML) which triggered a mailman error page that
- -would include the malicious code verbatim.
+Флориан Ваймер обнаружил межсайтовый 
скриптинг в автоматически создаваемых
+сообщениях об ошибках mailman. 
Злоумышленник может
+сформировать специальный URL, содержащий 
код на JavaScript (или другое содержание,
+встроенное в HTML), обработка которого 
приведёт к отображению страницы с ошибкой 
mailman,
+содержащей вредоносный код.
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0202;>CAN-2005-0202
 
- -Several listmasters have noticed unauthorised access to archives
- -of private lists and the list configuration itself, including the
- -users passwords.  Administrators are advised to check the
- -webserver logfiles for requests that contain "/./" and the
- -path to the archives or configuration.  This does only seem to
- -affect installations running on web servers that do not strip
- -slashes, such as Apache 1.3.
+Несколько администраторов списков 
рассылки заметили неавторизованный доступ 
к
+архивам закрытых списков, а также 
настройкам самих списков, включая
+пароли пользователей. Администраторам 
рекомендуется проверить файлы журнала
+веб-сервера на предмет наличия запросов, 
содержащих "/./" и путь
+к архивам или настройкам. Как кажется, 
эта уязвимость касается только
+установок, использующих веб-серверы, 
которые не удаляют косые
+черты (например, Apache 1.3).
 
 
 
 
- -For the stable distribution (woody) these problems have been fixed in
- -version 2.0.11-1woody11.
+В стабильном выпуске (woody) эти проблемы 
были исправлены в
+версии 2.0.11-1woody11.
 
- -For the unstable distribution (sid) these problems have been fixed in
- -version 2.1.5-6.
+В нестабильном выпуске (sid) эти проблемы 
были исправлены в
+версии 2.1.5-6.
 
- -We recommend that you upgrade your mailman package.

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

2018-02-18 Пенетрантность artiom 
>> Посмотрел про 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

2018-02-18 Пенетрантность artiom 
>  >>  >>  >>> На 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

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


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

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

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

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

Re: Backup

2018-02-18 Пенетрантность Коротаев Руслан 
В сообщении от [Сб 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