RE: backup bike
Bacula. Все перечисленное может. Складывает в девайс или в указанную фс. -Исходное сообщение- От: "9211297" <9211...@gmail.com> Отправлено: 27.11.2016 5:27 Кому: "debian-russian@lists.debian.org" Тема: backup bike Приветствую. Хочу строить велосипед, но думаю, что зря - должно же быть что-то именно такое. Прошу подтвердить или опровергнуть. Задача: инкрементальные автоматизированные бэкапы некоторых частей $HOME на одном, максимум - двух хостах (соответственно, могут быть не совсем автоматизированы, что-то можно свалить на пользователя, то есть меня). Инкрементальность - ключевой момент, ибо будет литься в сеть. Файловые системы - строго наитивные (сейчас фактически только ext4). Разумеется, через некоторое время (или размер инкремента) – полный бэкап. Отдельные уровни резервирования (по частоте, например) для данных разной важности/размера (пароли, документы, фотографии, ...). Хранение локально и онлайн, соответственно, под пароль всё, что кидается на dropbox/googledisk/etc. Время восстановления - не особо критично, несколько часов вполне годится. А вот время бэкапа по возможности хотелось бы сократить. Написать могу, но времени жалко, а главное надежность на себе проверять придется. Рассмотрю подсказки в стороны файловых систем тоже, но я с трудом могу представить на них инкремент. - Лев Б.
Re: backup bike
Посмотрите на rdiff-backup. Может инкрементить локально, может по ssh. Всегда хранится актуальная копия, а прошлые снимки как последовательные инктеременты к с самому свежему. -- Дмитрий telegram: @dmitryrw 9211297 <9211...@gmail.com> 27 ноября 2016 г. 7:27:11 написал: Приветствую. Хочу строить велосипед, но думаю, что зря - должно же быть что-то именно такое. Прошу подтвердить или опровергнуть. Задача: инкрементальные автоматизированные бэкапы некоторых частей $HOME на одном, максимум - двух хостах (соответственно, могут быть не совсем автоматизированы, что-то можно свалить на пользователя, то есть меня). Инкрементальность - ключевой момент, ибо будет литься в сеть. Файловые системы - строго наитивные (сейчас фактически только ext4). Разумеется, через некоторое время (или размер инкремента) – полный бэкап. Отдельные уровни резервирования (по частоте, например) для данных разной важности/размера (пароли, документы, фотографии, ...). Хранение локально и онлайн, соответственно, под пароль всё, что кидается на dropbox/googledisk/etc. Время восстановления - не особо критично, несколько часов вполне годится. А вот время бэкапа по возможности хотелось бы сократить. Написать могу, но времени жалко, а главное надежность на себе проверять придется. Рассмотрю подсказки в стороны файловых систем тоже, но я с трудом могу представить на них инкремент. - Лев Б.
backup bike
Приветствую. Хочу строить велосипед, но думаю, что зря - должно же быть что-то именно такое. Прошу подтвердить или опровергнуть. Задача: инкрементальные автоматизированные бэкапы некоторых частей $HOME на одном, максимум - двух хостах (соответственно, могут быть не совсем автоматизированы, что-то можно свалить на пользователя, то есть меня). Инкрементальность - ключевой момент, ибо будет литься в сеть. Файловые системы - строго наитивные (сейчас фактически только ext4). Разумеется, через некоторое время (или размер инкремента) – полный бэкап. Отдельные уровни резервирования (по частоте, например) для данных разной важности/размера (пароли, документы, фотографии, ...). Хранение локально и онлайн, соответственно, под пароль всё, что кидается на dropbox/googledisk/etc. Время восстановления - не особо критично, несколько часов вполне годится. А вот время бэкапа по возможности хотелось бы сократить. Написать могу, но времени жалко, а главное надежность на себе проверять придется. Рассмотрю подсказки в стороны файловых систем тоже, но я с трудом могу представить на них инкремент. - Лев Б.
Re: права андроида
https://ru.wikipedia.org/wiki/SELinux
Re: замена диска в mdadm-raid-1 с расширением массива
25.11.2016 21:57, dimas пишет: каков должен быть порядок действий? Создаёшь на новом 1Т диске два раздела. Один на 300-500м под /boot, второй для всего остального под lvm Метишь их что они linux raid Создаёшь два "битых" рейда (можно указать что один из дисков missing На первом создаёшь фс и копируешь туда /boot, второй используешь как pv для lvm Переносишь всё своё барахло внутрь lvm, Удаляешь старую разметку на старом 1Т диске Переразбиваешь старый диск так же как новый Добавляешь его в рейд к новому. Не забудь про загрузчик в mbr. Перейдя на lvm ты забудешь про описанные тобой проблемы и всё это будет решаться даже без выключения компа если диски нагорячую можно менять. и еще бонусный вопрос: старый 500Г диск хочу оставить и иногда rsync-ать на него содержимое массива (допустим, за вычетом кинца, когда оно превысит 400Г). можно как-то превратить его из половинки рейда в просто раздел, чтобы фс со всем файлОм осталась при этом как есть? типа обнулить там рейд-суперблок, чтоб был просто раздел и на нем просто фс? Я бы его одной большой фс примонтировал. signature.asc Description: OpenPGP digital signature
Re: права андроида
sergio -> debian-russian@lists.debian.org @ Sat, 26 Nov 2016 15:08:21 +0300: > Всем привет. > Вот есть андроид. На нём есть директория. В директории лежат два файла. Самая интересная для вопроса информация - версия андроида - забыта. Впрочем, боюсь, я содержательного ответа на вопрос все равно не дам, ибо про эту жопу знаю в основном только, что она существует, и что от 4.3, кажется, до 5 было совсем плохо, а с 5 стало просто плохо. > Один файл, был создан программой и с ним всё хорошо. А второй я > скопировал туда рутом. > С точки зрения ls -l и lsattr файлы имеют одинаковые права: > (u0_a83:u0_a83, -rw---, ---A-) > Но проблема в том, что программа, которая создала хороший файл, не может > ни открыть ни переименовать плохой. (File is empty, File cannot be > renamed, и подобная муть). > Если взять хороший файл, сказать на него рутом mv в другой файл, а потом > cat в него плохой файл, то полученный файл будет читаться и > переименовываться. > То есть проблема именно в правах, а не в том, что программа при создании > запоминает название файла в ещё каком-нить месте и потом от этого зависит. Это не программа. Это андроид. Там файловая система - какая-то кастомная фусешечка... Ну, то есть, как я понимаю, вполне документировано, какая, но я эту документацию не читал. И где-то начиная с 4.3 у нее есть подсмотренная в IOS возможность разграничить файловую систему на "мое" и "не мое" по приложениям. > P.S. > Конкретно эту программу зовут OsmAnd, а файл gpx трек, но это далеко не > первый раз, когда я натыкаюсь на подобные проблемы с андроидом. > P.P.S. > Если сказать su u0_a83, то с плохим файлом всё хорошо > (переименовывается, читается). > ps | grep u0_a83 показывает, что OsmAnd запущен от u0_a83.
права андроида
Всем привет. Вот есть андроид. На нём есть директория. В директории лежат два файла. Один файл, был создан программой и с ним всё хорошо. А второй я скопировал туда рутом. С точки зрения ls -l и lsattr файлы имеют одинаковые права: (u0_a83:u0_a83, -rw---, ---A-) Но проблема в том, что программа, которая создала хороший файл, не может ни открыть ни переименовать плохой. (File is empty, File cannot be renamed, и подобная муть). Если взять хороший файл, сказать на него рутом mv в другой файл, а потом cat в него плохой файл, то полученный файл будет читаться и переименовываться. То есть проблема именно в правах, а не в том, что программа при создании запоминает название файла в ещё каком-нить месте и потом от этого зависит. P.S. Конкретно эту программу зовут OsmAnd, а файл gpx трек, но это далеко не первый раз, когда я натыкаюсь на подобные проблемы с андроидом. P.P.S. Если сказать su u0_a83, то с плохим файлом всё хорошо (переименовывается, читается). ps | grep u0_a83 показывает, что OsmAnd запущен от u0_a83. -- sergio
