1 (04.02.2011 11:28:24 отредактировано roman_k)

Окончательно разочаровавшись в различного рода гуёвых бэкаперах с их кнопками "сделать зашибись" (поскольку бэкапы, ими создаваемые, в тяжёлых ситуациях не спасали, и служили более для самоуспокоения; в последнюю пару месяцев – так и вовсе приходилось жить совсем без бэкапов, но это уже другая история...), решился я всё-таки научиться пользоваться для этого tar-ом.


Предварительно перелопатив кучу форумов и руководств и создав в своей голове полнейщую мешанину, предпочёл на практике ограничиться одними лишь указаниями с wiki ubuntu... Руководствоваться мешаниной – довольно затруднительно, а там – одна последовательная инструкция, да и источник, как мне казалось, заслуживает большего доверия, чем сотни разрозненных комментов на десятках форумов. Забегая вперёд, отмечу, что инструкцию я выполнил, а получилась, тем не менее, лажа. Я постараюсь максимально подробно описать свои действия и их результат и надеюсь, что вы поможете мне проанализировать их и понять, что я сделал не так.


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


Гружусь с LiveCD... Создаю точки монтирования и прикручиваю к ним разделы:

sudo mkdir /mnt/{linroot,tera}
sudo mount /dev/sdb1 /mnt/tera    //монтирую в /mnt/tera большой ntfs раздел, на котором и будет храниться бэкап (здесь и далее за четырьмя пробелами и двойным слэшем - комменты, которые в консоль я, естественно не писал)
sudo mount /dev/sda7 /mnt/linroot -o ro    //монтирую корневой раздел своей Кубунты в /mnt/linroot в режиме "read only"
sudo mount /dev/sda5 /mnt/linroot/home -o ro    //home - на подобающее ему место

Затем, создаю папку под бэкап и, собственно, сам бэкап:

sudo mkdir -p /mnt/tera/BackUp/Linux/Full    //папки BackUp и Linux на диске существуют заблаговременно, Full - создаётся
sudo tar -cvzpf /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz /mnt/linroot --exclude=/mnt/linroot/home/user1/Музыка --exclude=/mnt/linroot/home/user2/Музыка    //имена юзеров изменены, в остальном - строка передана буквально

Архив создал, решаю проверить, что получилось... Создаю на том же ntfs разделе папку для тестовой разпаковки:

sudo mkdir -p /mnt/tera/BackUp/Linux/Test
sudo mkdir -p /mnt/tera/BackUp/Linux/Test/root

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

sudo tar --same-owner -xvpf -C /mnt/tera/BackUp/Linux/Test/root /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz

Получаю в ответ: "Нет такового файла или каталога", - а, заметьте, делал это строго по инструкции в авторитетном источнике (блин, я что, единственный, кто её прочёл?). Чешу репу, думаю: "Логично..." - и, матеря коллективный разум авторов упомянутого wiki, ставлю источник после f, а назначение после -С

sudo tar --same-owner -xvpf /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz -C /mnt/tera/BackUp/Linux/Test/root

Процесс пошёл и продолжался приблизительно столько же времени, сколько и архивация, но завершился прекрасной в своей лаконичной информативности фразой: "Выход с ошибкой из-за предыдущих ошибок". Провёл поиск по консольному выводу (он сохранялся полностью) буквосочетанием "ошиб" и никаких соответствующих сообщений в процессе разархивации не обнаружил. Поиск по "error" не осилил по причине обилия в архиве файлов "error.png". Этот факт можно считать проблемой №1: уважаемые, чем мог быть обусловлен выход с подобным сообщением и как бы это выявить? Какова связь таковой концовки с кривостями восстановленной информации, приведёнными ниже?

Далее, проверяю, что получилось. В каталоге /mnt/tera/BackUp/Linux/Test/root, который я воображаю своим линуксовым корневым разделом, наблюдаю не привычные папки линуксового корня, а одинокий каталог mnt, за ним - linroot и только в нём - папки корня. КО нашёптывает мне, что если бы такое дерево выросло у меня на линуксовом разделе в реальных условиях, то работать бы "восстановленная" система не стала... Это можно назвать проблемой №2: я сделал что-то не так при создании архива, его распаковке или, если распаковка будет проводиться непосредственно в /mnt/linroot, то дублирующих существующую структуру элементов не создастся? В любом случае, как добиться того, чтобы папок /mnt/linroot в архиве не создавалось, а распаковка происходила непосредственно туда, куда я указываю (вдруг я в следующий раз точки монтирования иначе поименую)?


Проблема №3, делающая созданный мной бэкап полностью непригодным к использованию: все файлы и каталоги получили владельца root и разрешающие права "всем на всё". Заметим, что p и --same-owner я не пропускал, выполняя инструкцию с дотошностью, достойной истинного арийца. Как? Почему? За что мне это?

Флажки "исполняемости" на месте (блин, хоть что-то), но атрибуты суидности (а вместе с ними, вероятно, и гуидности, и липкости - просто я не помнил наизусть ни одного файла, у которого они должны были быть проставлены) отвалились... Полагаю, что описывать, чем именно это затруднит работу с восстановленной системой, было бы излишним. И это проблема №4. Какие составные части нужной магической формулы скрыли от профанов составители wiki?

И, наконец, проблема пятая и самая весёлая: размер разархивированного бэкапа вырос по сравнению с оригиналом с 7 749 892 338 байт до 10 119 811 031, количество файлов возросло с 198 343 до 281 008 и даже папок (мой мозг! это-то как может произойти!) тысчёнки четыре прибавилось! Это чудесно, когда после краха системы и восстановления из бэкапа мы получаем в утешение и награду за труды не только спасённое старое, но и кучу нового, только было бы это новое чем-то полезным... Прирост наблюдается как в директориях корневого раздела, так и в пользовательских. tar настоящий джентльмен, поэтому больше всего любит делать подарки прекрасным дамам: если в корне и в моей пользовательской папке прирост был около двухкратного, то количество файлов в директории жены увеличилось приблительно в 50 раз. На примере той же пользовательской директории жены было выявлено, что прирост кроется где-то в скрытых папках - нескрытые числом и размером оригиналу соответствовали. Симлинки (единственная возможная причина, пришедшая мне в голову, хотя и это могло бы объяснить лишь размер, но не количество файлов), при этом, внешне остались симлинками.


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

P.S. Да, ещё один вопрос. Очень интересно, сколько народу из прочивших это сорвалось проверять свои бэкапы, и что они в это время говорили?

2

roman_k пишет:

sudo tar --same-owner -xvpf -C /mnt/tera/BackUp/Linux/Test/root /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz

Опция «x» извлекает файлы из архива.
Для создания архива используется «c» (create) совместно с «z» или «j» (если нужно сжать).

Был, был и весь вышел...

3

Lupo Alberto пишет:

Опция «x» извлекает файлы из архива.
Для создания архива используется «c» (create) совместно с «z» или «j» (если нужно сжать).

Спасибо, Кэп ab)

А, если серьёзно, то это Вы к чему?

4

roman_k пишет:

А, если серьёзно, то это Вы к чему?

Не в ту строчку глянул  :o
Вам не подойдёт готовое решение — http://clonezilla.org/ ?

Был, был и весь вышел...

5

roman_k пишет:

проблемой №2: я сделал что-то не так при создании архива, его распаковке или, если распаковка будет проводиться непосредственно в /mnt/linroot, то дублирующих существующую структуру элементов не создастся?

У меня тоже подобные проблемы возникали: не мудрствуя лукаво, я перед архивацией переходил в архивируемый каталог и в нём запускал команду.

Был, был и весь вышел...

6

Lupo Alberto пишет:

Вам не подойдёт готовое решение — http://clonezilla.org/ ?

Всё-таки, задачу "научиться пользоваться tar-ом" считаю для себя принципиальной... Это же основы Линукса, можно сказать...

7

Lupo Alberto пишет:

У меня тоже подобные проблемы возникали: не мудрствуя лукаво, я перед архивацией переходил в архивируемый каталог и в нём запускал команду.

Угу, я об этом думал... Но это, вероятно, касается только проблемы №2 - появления лишних вложенностей. Но у меня источник бэкапа и сам бэкап при архивации и бэкап и назначение при восстановлении - неизбежно будут на разных разделах и в разных точках монтирования. Как тут не мудрствовать - придумать не могу.

Опять же, остальных проблем из списка это не отменяет. Владельцы/права и суидность беспокоят больше всего...

8

roman_k пишет:

Проблема №3, делающая созданный мной бэкап полностью непригодным к использованию: все файлы и каталоги получили владельца root и разрешающие права "всем на всё". Заметим, что p и --same-owner я не пропускал, выполняя инструкцию с дотошностью, достойной истинного арийца. Как? Почему? За что мне это?

Не может быть в этом виновата используемая вами файловая система ntfs?

roman_k пишет:

sudo tar -cvzpf /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz /mnt/linroot --exclude=/mnt/linroot/home/user1/Музыка --exclude=/mnt/linroot/home/user2/Музыка

roman_k пишет:

sudo tar --same-owner -xvpf /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz -C /mnt/tera/BackUp/Linux/Test/root

Архив вы создаёте со сжатием, а извлекаете — без.
Не пробовали извлекать без опции  --same-owner?

Был, был и весь вышел...

9

roman_k пишет:

Как тут не мудрствовать - придумать не могу.

Вы попробуйте, структура каталогов сохраняется и разархивирование в нужный каталог с опцией -C прекрасно работает.

Был, был и весь вышел...

10 (31.01.2011 22:23:09 отредактировано Lupo Alberto)

roman_k пишет:

И, наконец, проблема пятая и самая весёлая: размер разархивированного бэкапа вырос по сравнению с оригиналом с 7 749 892 338 байт до 10 119 811 031, количество файлов возросло с 198 343 до 281 008 и даже папок (мой мозг! это-то как может произойти!) тысчёнки четыре прибавилось!

Вы не проверяли, исключены ли из архива каталоги /mnt/linroot/home/user1/Музыка и  /mnt/linroot/home/user2/Музыка?
В момент создания архива в каталог /mnt/linroot/mnt ничего не примонтировано?

Был, был и весь вышел...

11

Вот один из созданных до вас и иногда используемых мной «велосипедов».
Если заинтересуетесь и что-то будет непонятно, могу объяснить подробнее.

Был, был и весь вышел...

12

Lupo Alberto пишет:

Не может быть в этом виновата используемая вами файловая система ntfs?

Может, наверное... Очень плохо будет, если это так...

Я вот что подумал... Не может ли быть в этом виновато

sudo mkdir -p /mnt/tera/BackUp/Linux/Full

и

sudo mkdir -p /mnt/tera/BackUp/Linux/Test/root

?

Директории создаются, как раз-таки, с владельцем root и правами "всем на всё", хоть с -p, хоть без него. В случае с точками монтирования - это и вовсе неизбежно... Может, содержимое тупо перенимает владельца/права своего каталога? Как тогда с этим бороться?


Lupo Alberto пишет:

Архив вы создаёте со сжатием, а извлекаете — без.

А ведь да!.. Однако же, файлы у меня получались разжаты - я и по директориям там ходил, и даже картинку какую-то открывал.

Lupo Alberto пишет:

Не пробовали извлекать без опции  --same-owner?

Не пробовал. Записал в список "попробовать".

Lupo Alberto пишет:

Вы попробуйте, структура каталогов сохраняется и разархивирование в нужный каталог с опцией -C прекрасно работает.

Уже в том же списке...

Lupo Alberto пишет:

Вы не проверяли, исключены ли из архива каталоги /mnt/linroot/home/user1/Музыка и  /mnt/linroot/home/user2/Музыка?

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

Lupo Alberto пишет:

В момент создания архива в каталог /mnt/linroot/mnt ничего не примонтировано?

Специально не проверял, но я так понимаю, что туда физически не могло быть ничего примонтировано. Я же это из-под LiveCD всё делал.

13

Итак... Методом длительного и последовательного, упорного, можно сказать, научного тыка, корни и предполагаемые решения проблем №№2-5 были предположительно выявлены.


Проблема №2 (появление лишних директорий по пути к нужной), как и подсказал Lupo Alberto, решается преварительным переходом в архивируемую папку и выполнением

sudo tar -cvzpf /путь/к/папке/назначения/архив.tar.gz ./

, если архивировать нужно содержание директории, но не саму директорию, или переходом в родительскую директорию относительно нужной и выполнением

sudo tar -cvzpf /путь/к/папке/назначения/архив.tar.gz ./директория-источник

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


Проблемы №3 и №4, похоже, локализованы - научный тык показал, что архивация/разархивация на ext4 даёт-таки сохранение владельца, прав и суидности, а на ntfs - не даёт, сколько и как ни бейся. Честно говоря, я бы не удивился, если бы ntfs не поддерживала системы линуксовых прав, в принципе; ан нет ведь - сами категории владельцев и прав сохраняются, только меняются на root и "всем всё можно".

Очень жаль, честно говоря: места нужно то под торренты побольше, то под линуксовые бэкапы, а плавающую перемычку между файловыми системами не поставить. Что ж, придётся отгрызать от ntfs увесистый ломоть (впрочем, неизвестно, получится ли у меня сделать полный бэкап на ext4; для теста у меня свободного места сейчас не достаточно). Во всяком случае, те, кто будут пытаться делать линуксовые бэкапы на виндовый диск, пусть учтут, что я об эту задачу побился изрядно, однако стены не прошиб.


Проблема №5 оказалась ещё смешнее, чем я предполагал... Krusader-а с sudo-mode на Live-CD, естественно, нет; размеры директорий и количество файлов и поддиректорий в них считались Долфином, запускающимся от умолчального юзера. Так вот, мне в голову не могло прийти, что когда я смотрю Долфином количество свободного места на разделе, то получаю совершенно неадекватную оценку.

Суть в следующем: у директорий типа .kde, .mozilla, .wine (неслабо, к слову, весящих) и им подобных в правах стоит запрет на вход всем, кроме владельца; Долфин, запущенный от имени другого юзера, в них и не входит, не считая их содержимое за занятое дисковое пространство. В случае же со сбитыми в бэкапе разрешениями, Долфин препятствий на своём пути в скрытые папки не встречает, и подсчёт происходит корректно. В общем, если приложение, запущенное под юзером, сообщает Вам, что у Вас 6 свободных Гектар на домашнем разделе, не спешите ему верить - может, у другого юзера на том же разделе имеется кэш Мозиллы на 5.9 Гектар... ab


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

14

Lupo Alberto пишет:

Архив вы создаёте со сжатием, а извлекаете — без.

что, кстати, абсолютно правильно ab
пусть tar сам разбирается.

roman_k пишет:

Проблема №3, делающая созданный мной бэкап полностью непригодным к использованию: все файлы и каталоги получили владельца root и разрешающие права "всем на всё". Заметим, что p и --same-owner я не пропускал, выполняя инструкцию с дотошностью, достойной истинного арийца. Как? Почему? За что мне это?

я тут мануал читал, оказывается ВНЕЗАПНО, что опция -p не нужна ab
потому-что она по дефолту установлена (для рута. для всех остальных не установлена, но тоже обычно не нужна - менять владельца может только рут). Права NTFS совершенно другие, не такие как в Linux FS, tar вместе с ntfs-3g пытались вам помочь, но вы-же понимаете, всему есть предел. Пишите на www.microsoft.com, может в Windows 8 наконец сделают нормальные права доступа  ah

roman_k пишет:

Честно говоря, я бы не удивился, если бы ntfs не поддерживала системы линуксовых прав, в принципе; ан нет ведь - сами категории владельцев и прав сохраняются, только меняются на root и "всем всё можно".

ага. владельцы там есть и права какие-то тоже есть. они просто ДРУГИЕ. тар пытался как-то привести линуксовые к вендовым, но...

roman_k пишет:

Так вот, мне в голову не могло прийти, что когда я смотрю Долфином количество свободного места на разделе, то получаю совершенно неадекватную оценку.

количество свободного места Ъ линуксоиды смотрят командой df, занимаемый объём командой du, посчитать все файлы в каталоге - командой find dir | wc -l (только учтите, это ВСЕ файлы, например ещё и хардлинки вроде точка и две точки). Баги в дельфине отправляйте по адресу https://bugs.kde.org/

roman_k пишет:

Долфин препятствий на своём пути в скрытые папки не встречает, и подсчёт происходит корректно.

вот потому и призываю вас считать файлы командой find - она вам напишет, что её куда-то не пустили. Кстати, само понятие "файл" вы понимаете не полностью, по вендовому, в мире Linux всё файлы, потому не удивляйтесь, если ваш бекап будет включать в себя вообще ВСЁ (память, клавиатуру, все диски, а может даже пол-интернета)

roman_k пишет:

Процесс пошёл и продолжался приблизительно столько же времени, сколько и архивация, но завершился прекрасной в своей лаконичной информативности фразой: "Выход с ошибкой из-за предыдущих ошибок". Провёл поиск по консольному выводу (он сохранялся полностью) буквосочетанием "ошиб" и никаких соответствующих сообщений в процессе разархивации не обнаружил. Поиск по "error" не осилил по причине обилия в архиве файлов "error.png". Этот факт можно считать проблемой №1: уважаемые, чем мог быть обусловлен выход с подобным сообщением и как бы это выявить? Какова связь таковой концовки с кривостями восстановленной информации, приведёнными ниже?

тут я вижу целых 2 проблемы:

1) об ошибках тар пишет в /dev/stderr (второй поток), потому вы можете отправить ошибки в какой-нибудь файл

 Консоль:
tar <...> 2>errors.txt

2) у grep есть ключик -v
 Консоль:
tar <...> | grep -v "errors.png" | grep "error"

но вам это всё равно не поможет: дело вот в чём: сам по себе tar не умеет упаковывать, а умеет в данном случае gzip. Очевидно, что для упаковки файл надо прочитать, но это невозможно из-за недостатка прав (а может невозможно из-за того, что в какой-то каталог не войти, тоже из-за прав).

вы-бы запустили-бы свой тар на маленькой кошке, и всё-бы поняли:

 Консоль:
$ tar -cvvf a.tar * 1>/dev/null
tar: a.tar: файл является архивом; не сброшен
tar: l: Функция open завершилась с ошибкой: Отказано в доступе
tar: Завершение работы с состоянием неисправности с из-за возникших ошибок

А вот и причина:

 Консоль:
$ ls -ld l
d--------- 2 doc users 4096 2011-01-13 15:47 l/

не получилось войти в этот каталог. Кроме того, не получилось сохранить в архиве a.tar архив a.tar (сами наверное знаете почему).

Вот потому, хотя и архив успешно создан, команда завершена с ошибкой - ибо в бекап не попали некоторые важные файлы.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

15

ЗЫЖ
кстати, что-бы не ломать голову с поиском ошибок, ищите:

 Консоль:
grep -E "^tar: "

Эта команда отфильтровывает лишь строчки, которые начинаются на "tar: ", и не забывайте о том, что PIPE отправляет только лишь первый поток, потому
 Консоль:
$ tar -cvvf a.tar * | grep --color -E "^tar: "

НЕ работает

правильно так:

 Консоль:
$ tar -cvvf a.tar * 2>&1 | grep --color -E "^tar: "

тут я отправил второй поток в первый

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

16

drBatty пишет:

я тут мануал читал, оказывается ВНЕЗАПНО, что опция -p не нужна ab

Да, я его тоже читал... А ещё - читал примеры, в которых она есть... Подумал, пусть будет - мне ж не жалко ab

Кстати, иногда вижу как удваивают -v (в частности, и у Вас). Не подскажете, зачем это делается?


drBatty пишет:

количество свободного места Ъ линуксоиды смотрят командой df, занимаемый объём командой du

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


drBatty пишет:

Баги в дельфине отправляйте по адресу https://bugs.kde.org/

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


drBatty пишет:

Кстати, само понятие "файл" вы понимаете не полностью, по вендовому, в мире Linux всё файлы, потому не удивляйтесь, если ваш бекап будет включать в себя вообще ВСЁ (память, клавиатуру, все диски, а может даже пол-интернета)

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


drBatty пишет:

не получилось войти в этот каталог. Кроме того, не получилось сохранить в архиве a.tar архив a.tar (сами наверное знаете почему).

Эти-то два варианта я учёл. Загрузка с LiveCD - против обращения к чему-то работающему; sudo - против недостаточности прав; раздел с назначением к разделу с источником не примонтирован.


drBatty пишет:

правильно так:
Консоль:

$ tar -cvvf a.tar * 2>&1 | grep --color -E "^tar: "

тут я отправил второй поток в первый

Спасибо. Полностью я написанного Вами, признаюсь, не понял, но это практикой познаётся... Если не познается само, переспрошу.

17

roman_k пишет:

А ещё - читал примеры, в которых она есть... Подумал, пусть будет - мне ж не жалко

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

roman_k пишет:

Кстати, иногда вижу как удваивают -v (в частности, и у Вас). Не подскажете, зачем это делается?

иногда v утраивают, и даже учетверяют ab

2. Чья бы корова мычала...Ну это фишка известная, но для галочки упомяну :)
Набираем:
$apt-get moo

Далее:
$aptitude -v moo
There really are no Easter Eggs in this program.

Далее...
$aptitude -vv moo
Didn't I already tell you that there are no Easter Eggs in this program?

...
$aptitude -vvv moo
Stop it!

...
$aptitude -vvvv moo
Okay, okay, if I give you an Easter Egg, will you go away?

...
$aptitude -vvvvv moo
All right, you win.
sssssssssssssssssssssssssssssss/-----\
sssssssssssssssssssssss---------/ssssss\
ssssssssssssssssssssss/ssssssssssssss\
sssssssssssssssssssss/sssssssssssssss|
sss------------------------/ssssssssssssssss--------\
sss--------------------------------------------------------

И последний раз:
$aptitude -vvvvvv moo
What is it? It's an elephant being eaten by a snake, of course.

ag
( http://welinux.ru/post/2675/ )

roman_k пишет:

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

хочу вас заранее предупредить, что ФС это не ящик с картошкой. Часто сложно понять существует-ли файл вообще, а уж про его объём...

roman_k пишет:

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

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

roman_k пишет:

Или я ошибаюсь, и что-то, всё-таки, необходимо исключить даже при бэкапе системы, которая не запущена?

по идее можно и не исключать. в работающей надо исключить /proc, /sys, /dev. Причём бекап нужно делать по живому, т.к. разделов обычно больше одного, и у меня например корень - просто набор точек монтирования для остальных разделов. Ну а если система не работает (мы смотрим на диск с лайва), то логичнее сделать образ всего диска командой dd.

tar -cvvf a.tar * 2>&1 | grep --color -E "^tar: "

-сvvf создание архива a.tar
2>&1 отправка ошибок(2) в стандартный поток(1)
| передача стандартного потока другой команде
grep -E --color "^tar: " фильтрация  "tar: ", но это регулярное выражение, тут символ ^ нужен что-бы ловилось только "tar: " первое в строке. А тар специально не пишет никогда первым в строке "tar: ". Это позволяет выдирать сообщения от тара из лога, в который пишет не одна программа, а множество.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

18

| передача стандартного потока другой команде
grep -E --color "^tar: " фильтрация  "tar: ", но это регулярное выражение, тут символ ^ нужен что-бы ловилось только "tar: " первое в строке. А тар специально не пишет никогда первым в строке "tar: ". Это позволяет выдирать сообщения от тара из лога, в который пишет не одна программа, а множество.

Да. В общем-то, я как запустил, так и понял сразу. Теперь думаю, как при этом и вывод на консоли сохранить: не по логу же, на этот раз ищем - на ходу-то хотелось бы и видеть, мимо чего едем. С другой стороны, тогда и подсветка спасает слабо; лучше потом журнал грепнуть...


______________



Подведу итоги... Создал ещё один ext4. Несколько удивило, что на свежеразмеченном и только что примонтированном 78-гектарном разделе оказались сразу же заняты чем-то категорически невидимым 4 Гектара. Что это?

Ну да ладно, забэкапил туда. Права сохранены. Ошибки при завершении не декларируется.

В процессе архивации были "проигнорированы" 3 сокета: 2 от Akonadi - шиш с ним, с Аконади, 1 из /tmp - по размещению судя - тоже шиш с ним.

Несколько настораживает различие между размерами источника и тестово-распакованного архива в 3.5 мегабайта (считал Krusader-ом, df и du ещё не освоил), причём разница обнаруживается, в том числе между каталогами /usr.

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

19

roman_k пишет:

Да. В общем-то, я как запустил, так и понял сразу. Теперь думаю, как при этом и вывод на консоли сохранить: не по логу же, на этот раз ищем - на ходу-то хотелось бы и видеть, мимо чего едем. С другой стороны, тогда и подсветка спасает слабо; лучше потом журнал грепнуть...

вывод можно отправить в файл командой tee, а потом, за рюмкой чая проанализировать. Команды cat и more  не портят цвета. less тоже не портит, но ей ключ какой-то надо, не помню какой (ещё она умеет цветные маны показывать).

roman_k пишет:

Подведу итоги... Создал ещё один ext4. Несколько удивило, что на свежеразмеченном и только что примонтированном 78-гектарном разделе оказались сразу же заняты чем-то категорически невидимым 4 Гектара. Что это?

3.9 это как раз рутовый резерв в 5%. доступ туда только руту. нужен на всякий случай. например ошибка в ошибке. требуется на разделах /var в корне и в /tmp. в /home и на дополнительных дисках обычно не нужен. выставляется mkfs -m5 (5%) при создании ФС, или tune2fs потом.

roman_k пишет:

Несколько настораживает различие между размерами источника и тестово-распакованного архива в 3.5 мегабайта (считал Krusader-ом, df и du ещё не освоил), причём разница обнаруживается, в том числе между каталогами /usr.

возможно это разряжённые файлы (они есть и в венде) sparace_super. Ну и при распаковке файлы могли быть уложены по другому (да и вообще много чего могло быть. df запускается без параметров, или с параметром -h ("пиши по человечески!" значит). Попробуйте

 Консоль:
du -sh /var/*

roman_k пишет:

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

когда контролируют каталоги бекапа используют хеш, который сохраняют вместе с бекапом

 Консоль:
find /dir/ -type f -exec md5sum {} \; | tee MD5SUMS.txt

проверка:
 Консоль:
md5sum -c MD5SUMS.txt

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

20

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

Создать на ntfs-ном разделе архив, внутри которого сохранятся права, всё-таки можно, и при распаковке на ext4 они останутся на месте. Лажа происходит на стадии распаковки такого архива на ntfs - только тогда права "конвертятся" в ntfs-ные.

Блин, ладно, полный бэкап я не мог на ext4 распаковывать из-за нехватки места, но что мне мешало какой-нибудь из мелких тестовых архивов, которых я тоже кучу насоздавал на ntfs, распаковать непосредственно на ext4! Соответственно, бОльшая часть моих мучений обусловлена исключительно моей дурной головой и была совершенно бесполезна. Ну да ладно - как получилось, так получилось. А большой линуксовый раздел, в любом случае не помешает.


____________________


3.9 это как раз рутовый резерв в 5%. доступ туда только руту. нужен  на всякий случай. например ошибка в ошибке. требуется на разделах /var в корне и в /tmp. в /home и на дополнительных дисках обычно не нужен. выставляется mkfs -m5 (5%) при создании ФС, или tune2fs потом.

Угу, спасибо... Значит, всё-таки, не журнал... А то нифига себе журнальчик был бы (в интернетах такая версия присутствовала).

Воспользовался tune2fs-ом (sudo tune2fs -m 1 /dev/sdxY), уменьшил резерв до процента на /home и хранилище.

21

roman_k пишет:

Угу, спасибо... Значит, всё-таки, не журнал... А то нифига себе журнальчик был бы (в интернетах такая версия присутствовала).

журнал - это отдельный специальный файл. но он невидим. ещё есть суперблоки, а также иноды (inode) - области, где хранится информация про файлы (атрибуты файлов, но не имена). причём число (и размер) инодов фиксировано, и задаётся только при создании ФС, или для ext4 командой tune2fs если есть нужная фича. попробуйте

 Консоль:
tune2fs -l /dev/sdXY

чтобы узнать полную информацию о вашей ФС.

если есть маленький и быстрый HDD, то можно создать там журнал. Тогда скорость работы существенно увеличится (если конечно сервер умеет писать одновременно сразу на 2 диска). на самом деле, журнал маленький, и его просто незаметно на современных дисках. вот инодов много. например на одном моём разделе в 6,5G имеются 427392 инодов (свободно 405328), причём каждый из них в 256байт.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)