Феерически кривой бэкап tar-ом: что я делаю не так? [Решено] (истина в комментариях)
Окончательно разочаровавшись в различного рода гуёвых бэкаперах с их кнопками "сделать зашибись" (поскольку бэкапы, ими создаваемые, в тяжёлых ситуациях не спасали, и служили более для самоуспокоения; в последнюю пару месяцев – так и вовсе приходилось жить совсем без бэкапов, но это уже другая история...), решился я всё-таки научиться пользоваться для этого 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 - создаётся
<b>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/Музыка</b> //имена юзеров изменены, в остальном - строка передана буквально
Архив создал, решаю проверить, что получилось... Создаю на том же 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, а назначение после -С
<b>sudo tar --same-owner -xvpf /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz -C /mnt/tera/BackUp/Linux/Test/root
</b>
Процесс пошёл и продолжался приблизительно столько же времени, сколько и архивация, но завершился прекрасной в своей лаконичной информативности фразой: "Выход с ошибкой из-за предыдущих ошибок". Провёл поиск по консольному выводу (он сохранялся полностью) буквосочетанием "ошиб" и никаких соответствующих сообщений в процессе разархивации не обнаружил. Поиск по "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. Да, ещё один вопрос. Очень интересно, сколько народу из прочивших это сорвалось проверять свои бэкапы, и что они в это время говорили?
Сложно как-то пишешь... А если говорить о размере, то TAR это формат архива с правами файлов, но ничто другое... то есть говоря проще tar -это только перечень файлов в "контейнере" и только, БЕЗ сжатия... соотвественно он будет БОЛЬШЕ размера сжимаемых данных...
Видимо, действительно, сложно пишу :)
Да, я понимаю, что tar это формат архива, но кроме того - утилита, которая этот архив делает (в тексте я употребляю это слово преимущественно в значении утилиты). То, что архивация и компрессия - суть разные операции я также понимаю, но отправляя утилите tar параметр -z, я одновременно с архивированием произвожу и компрессию методом gz.
И про размер - всё смешнее... Если упрощать, то я заархивировал+закомпрессовал (если Вам непременно нужно это указание) папку А в архив B, потом разархивировал+раскомпрессовал архив В в папку С, и получилось, что папка С весит больше чем папка А... И файлов в ней больше, чем я засовывал в архив... Причём, в полтора раза...
Если много мелких файлов, то может быть и меньше...
Пара вариантов бэкапа системы описана тут команды для tar -а по сравнению с вашими немного отличаются но в чем отличие если честно разбираться лень
Я это читал, да... Просто некропостертвовать не захотелось. Но, в целом, по всей логике, или бэкап должен работать у нас обоих, или у обоих же должна получаться лажа... Но лажа получается только у меня, по крайней мере, Вы пишете, что из такого архива восстановление производили, а не верить Вам я не могу...
Что я заметил по Вашему варианту и его отличиям от моего... Во-первых, Вы не печатаете чёрточку перед аргументами команды, но так делают - знаю... Ещё вы зачем-то пишете v дважды; очевидно, просите двойного консольного вывода :)
Во-вторых, как при архивации, так и при разархивации, Вы игнорируете ключи сохранения владельцев и прав, но, при этом, владельцы и права слетают у меня, а не у Вас :)
В-третьих, Вы оправляете в архив файлы списком (очевидно, плоским), а я - пихаю туда дерево вложенных каталогов со всем их содержимым. Здесь уже может что-то скрываться.
В-четвёртых, Вы, по всей видимости, распаковываете файлы из архива в ту же точку монтирования/директорию, откуда их в архив забирали. Третье и четвёртое может обусловить то, что у Вас не создаётся двух лишних "вложенностей" из моей "проблемы №1".
Однако, остальных моих проблем это не отменяет... Очень жаль, что Вам лень... Здесь чрезвычайно занятненькая головоломка здесь вырисовывается.
Вообще-то если исходить из ваших слов
то я бы посоветовал clonzillo-й просто бэкапить нужные разделы например корень / и /home на специально отведённый для этих целей раздел. Кстати сжимает она очень неплохо где-то раза в два. Лично я с корнем так и поступаю. Просто в домашней папке я не вижу смысла бэкапить музыку фильмы и прочий "хлам" там мне нужны только настройки программ и приведённые две команды вполне справляются хотя я иногда сгенерированый первой командой файл arhiv.txt могу ещё и ручками подредактировать для достижения желаемого эффекта. На счёт прав владельца я не особо беспокоился поскольку являюсь единственным владельцем системы и тот список директорий который сохраняется у меня имеет одни и теже права. А на счет второго v команду для tar я тоже подсмотрем на какомто форуме и причем довольно старом может в своё время это имело смысл :-)
Естественно это не освобождает от изучения man-ов...
Ну уж так я себе задачу поставил - освоить tar, ибо это основы... К тому же, очень сильно сомневаюсь, что мои задачи нельзя решить при помощи tar-а, просто уметь им надо пользоваться. А, чтобы научиться, требуется вынести мозг себе и другим :)
Ваши цели при создании тех двух строк вполне понятны, и им эти строки прекрасно отвечают. Только вот не ясно, почему мои средства не достигают моих целей, при том, что внешне (по крайней мере, в моём ограниченном восприятии) то, что я ввожу в консоль, ничуть не менее правильно, чем Ваш пример.
А man по tar-у, кстати, поразительно малоинформативная штука.
clonezilla -вещь!!!!!!!
посмотри тут мне помогло
Что именно помогло? Там не один вариант скрипта, там их - куча... Причём первый из них - никакого отношения к tar-у не имеет.
В тех же скриптах, где tar встречается, написан он так же, как у меня (по крайней мере, мне разница там не представляется принципиальной), но только у меня, почему-то, у одного результат кривой.
Итак... Методом длительного и последовательного, упорного, можно сказать, научного тыка, корни и предполагаемые решения проблем №№2-5 были предположительно выявлены.
Проблема №2 (появление лишних директорий по пути к нужной), решается предварительным переходом в архивируемую папку и выполнением
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 Гектар... :)
Надеюсь, что бэкап на ext4 (когда я его создам) проблем уже не вызовет, а этот мой отчёт поможет кому-нибудь в сходной ситуации. Впрочем, есть вероятность, что на этом мои мучения ещё не закончились: добиться "выхода с ошибкой из-за предыдущих ошибок" у меня не получилось, а значит - корень проблемы №1 по-прежнему скрыт, и может задать ещё какую-нибудь головоломную задачку.
Она и не поддерживает: всё, что вы создадите от root, сможете менять под пользователем.
Alt+F2 :
kdesudo dolphinПри этом поддерживая их видимость и заставляя думать, что не срабатывает аргумент -p или --same-owner tar-a :)
Благодарю Вас, я знаю, как запускать приложения из-под рута, что не трудно понять по тексту верхнего поста :)) Не знал, что лишь это нужно было сделать. Честно говоря, вообще в первый раз увидел запрет не на изменение, а на сам вход в директорию; к тому же, думал, что для подсчёта занятого места обращение идёт не данным (к коим и относятся права), а описательным метаданным.
Скажите, а Вы знали, почему у меня слетали права и не сходилось значения "веса" директорий источника и назначения? Если знали, то почему не сказали? Если не сказали тогда, то почему говорите сейчас? Тогда для этого нужно было подумать? Или Вы остановились ещё раньше - на "прочитать"?
Просто сильно не вчитывался и/или не задумывался. Извиняюсь за своё суперзапоздалое прозрение. Для меня эти действия почти как магия (я не айтишник), поэтому в общей массе я не усмотрел корень проблемы.
Просто есть люди, которые пользуются в консоли sudo, но не знают о существовании kdesudo для запуска графических приложений.
Возможно, и я слишком остро среагировал... Хотел было донести до Вас, на что именно, но стёр; если Вы уже сделали какие-то выводы, то это было бы излишне, а если нет, то вряд ли мои "нравоучения" привели бы к чему-то полезному.
Блин а ведь действительно внимательнее читать надо пост...
и тут
А ведь о том что ntfs не поддерживает линуксовые права здесь уже писали...
Видимо люди писавшие tar - не учли что народ бэкапы создавать начнёт на враждебной файловой системе ;-)
:) Боюсь, что, как раз, учли... И присобачили попытку преобразования ext-овых прав в ntfs-ные, результаты которого я и наблюдал.
Удивительно, что этого не учли составители той инструкции, по которой я делал бэкап, и множества прочих подобных; о такой несовместимости я раньше "слышал краем уха", но вот прямого предупреждения не встречал никогда. А, в то же время, мне представляется, что более половины домашних пользователей именно так и делают, только, в отличие от меня, не проверяют работоспособность своих бэкапов ещё до прихода песца.
Подведу итоги... Создал ещё один ext4. Несколько удивило, что на свежеразмеченном и только что примонтированном 78-гектарном разделе оказались сразу же заняты чем-то категорически невидимым 4 Гектара. Что это?
Ну да ладно, забэкапил туда. Права сохранены. Ошибки при завершении не декларируется.
В процессе архивации были "проигнорированы" 3 сокета: 2 от Akonadi - шиш с ним, с Аконади, 1 из /tmp - по размещению судя - тоже шиш с ним.
Несколько настораживает различие между размерами источника и тестово-распакованного архива в 3.5 мегабайта (считал Krusader-ом, df и du ещё не освоил), причём разница обнаруживается, в том числе между каталогами /usr.
Поскольку ничего другого не остаётся, буду считать этот варианта бэкапа условно пригодным к использованию. До первого восстановления, а там - и увидим...
5% места (по умолчанию) бронируется для суперпользователя [типа пруф]. Это на всякий случай, процент можно поменять.
Если размер кластера на разделах отличается, то размеры папок с одинаковыми файлами могут и не сойтись.
Огромное спасибо! Вы, кстати, только что спасли форум от очередного моего IT-детектива :) А то я уже было собирался тему открывать - для Гугла такой вопрос не больно-то выформулируешь.
Размер кластера... Хм-м... Как вариант. Ещё раз спасибо.
Всегда пожалуйста.
Кстати о правах при создании архива на ntfs опция
--numeric-owner
не помогает ?
Архив то на ней можно создавать, а вот распаковывать файлы, упакованные с лин-раздела не стоит - права послетают.
Я - кретин! Ох, какой же я кретин...
Действительно же!.. Ладно, полный бэкап я не мог на ext4 распаковывать из-за нехватки места, но что мне мешало какой-нибудь из мелких тестовых архивов, которых я тоже кучу насоздавал на ntfs, распаковать непосредственно на ext4.
*бьётся лбом о стол*
С LiveCD они, по понятной причине, изначально в виде uid виделись и обрабатывались - юзеров-то соответствующих в лайв-системе нет.
Благодаря DarkneSS, предыдущий вывод значительно скорректирован.
Создать на ntfs-ном разделе архив, внутри которого сохранятся права, всё-таки можно, и при распаковке на ext4 они останутся на месте. Лажа происходит на стадии распаковки такого архива на ntfs - только тогда права "конвертятся" в ntfs-ные.
Топик спас меня вчера от неудачного обновления дистрибутива :-)
Заметил только пару шероховатостей.
cd /mnt/linroot && sudo tar -cvzpf /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz ./потому что у меня в архиве создались папки mnt/linroot, и распаковка привела к тому, что на разделе данные также легли в mnt/linroot - делал вырезать/вставить, благо это происходит практически мгновенноУгу... У меня это где-то к комментах было обозначено, что сначала перейти в нужную директорию, а потом тарить.
Рад, что топик помог, и в двойне рад, что помог именно Вам. Вы тогда принимали активное участие обсуждении, и я рад, что потраченное время обернулось пользой, в том числе, и Вам самому.
А на какой, кстати?
Уупс... ))Не записал: три часа ночи и всё такое =) вылетело из головы, попробую на досуге, отчитаюсь.
Итак для разархивирования переходил в целевой каталог и делал
sudo tar --same-owner -xvpf /откуда/бэкап.tar.gzИначе получалPS Ух, полгода прошло)Ну так, правильно... Путь к директории назначения не указан же...
Или он указывался-таки? Как выглядела строчка, где был -C ?
P.S. Ах, да, вспомнил... У меня тоже было "no such file", если -C /путь/к_назначению писать между -xvpf и файлом источника. Нужно писать -С и путь к назначению в конце, после указания на источник. Иначе, видимо, tar думает, что -С - это есть архив, который нужно растаривать.
У меня это даже в посте было...
Было
sudo tar --same-owner -xvpf -C /media/disk /откуда/бэкап.tar.gzкак и написано в топике =)Ага :) Там в топике в следующей строчке, как раз, написано, что мне было ответом...
Я уж сам-то и забыл об этой тонкости. Если бы сам тогда не описал, едва ли вспомнил бы...
sudo tar --same-owner -xvpf /mnt/tera/BackUp/Linux/Full/full-30-01-11.tar.gz -C /mnt/tera/BackUp/Linux/Test/rootМда, многа букаф)
Архивация это сжатие... а то, что вы делаете называется упаковкой... tar как рах это и делает, есои не указать, что ещё и сжимать надо. Только тогда это будет архивация. Но там не передаётся аргументов сжимающей проге она запускается по умолчанию. Поэтому вначале пакуют, а потом сжимают. Хотя некоторые делают наоборот. Но это этого меньше эффкта. Для чего это надо? Можно ведь просто скопировать!!! Там всё сохраняется и всё восстанавливается, даже аттрибуты ACL, если они у тебя есть. Тебе не приходила в голову такая идея? Или на удалённом компе есть ещё утилита rsync. Ну почти тоже копирование, только она поэффективнее гибче и работает удалённо. Ешё варианты. Есть система версионности CVS, subvsrson, git и т.п. Здесь уже речь не о размере, а о том, чтобы сохранить всё, с учётом версий. Понятно, что размер будет больше и может намного оригинала. Однако мы можем проследить как он менялся. Ха это приходится платить а сжимают для экономии места. Но сжимают всегда упаковку. tar на самом деле уникален. Он довольго хорошо работает. Есть конечно свои проблемы, но немного. Попробуй ISO. Это практически та же упаковка. Только её можно монтировать. Но там столько заморочек, что вполне вероятно, что ты испортишь данные. Я долгое время считал что tar так же можно монтировать. Ещё есть jar. Это уже явовские штучки. Но тут я не силён... А вобще если место позволяет, то копируй и ты избавишься от многих проблем подобного типа! И как показывает практика архивация толго не стоит. Мы получаем выигрыш ха счёт сжатия, но это обычно неважно. Важнее правильно восстановить данные без искажений.
Отправить комментарий