Бэкапы на большой внешний USB-винт, отформатированный в FAT32 (prealfa-версия "проекта", для немного знакомых с шеллом)

[infra_hdc]

Сейчас в ходу USB-винты 160Гбайт и выше, и в гетерогенных средах логично использовать файловую систему FAT32 (NTFS не подходит хотя бы потому, что ту версию ntfs-3g, которую я юзал, на 95% загружает мой прескотт-3.00 ГГц). Но проблема в том, что в FAT32 нельзя создать файл размером более 4 Гбайт.

Решение: разбивать архив кусками не более 4Гбайт.

Скрипт для бэкапа:

Код:

#!/bin/sh # - do bigtemp backup - mkfifo /tmp/bigtemp.fifo split -b 2G /tmp/bigtemp.fifo bigtemp/bigtemp.tar. & tar -cvf /tmp/bigtemp.fifo /mnt/bigtemp >bigtemp.out 2>bigtemp.err rm -f /tmp/bigtemp.fifo # done

Скрипт для развертывания (на основе предыдущего, но обленился и ввел переменные, в первом параметре надо вбить "имя" архива, на основании которого даются имена файлов, каталогов и т.п.; к тому же, переменные == гибкость и меньше ошибок при вводе параметров):

Код:

#!/bin/sh # - do extract - AR_NAME=$1 AR_FIFO=/tmp/${AR_NAME} AR_MYDIR=/mnt/tmp-c/backups/askinfra-20090124-001 cd / mkfifo ${AR_FIFO} tar -xvf ${AR_FIFO} >${AR_MYDIR}/${AR_NAME}.extr.out \ 2>${AR_MYDIR}/${AR_NAME}.extr.err & cat ${AR_MYDIR}/${AR_NAME}/${AR_NAME}.tar.* >${AR_FIFO} rm -f ${AR_FIFO} sync ; sync # done

[serzh-z]

infra_hdc
И как в Windows это всё обратно сливать? Установить Cygwin с кучей утилит, тратить время на сливание? Спасибо. Я лучше драйвер ext2fsd установлю в Windows.

[Portnov]

serzh-z
Виндовая copy умеет объединять файлы - copy file1+file2+file3 file4. Хотя в случае десятков файлов это, мягко говоря, неудобно :)

[rm_]

Код: Выделить всё

#!/bin/sh
# - do bigtemp backup -
mkfifo /tmp/bigtemp.fifo
split -b 2G /tmp/bigtemp.fifo bigtemp/bigtemp.tar. &
tar -cvf /tmp/bigtemp.fifo /mnt/bigtemp >bigtemp.out 2>bigtemp.err
rm -f /tmp/bigtemp.fifo
# done

Мдя.

А теперь внимание, правильный ответ:

Код: Выделить всё

#!/bin/sh
tar -cvO /my-precious-data/ | split -b 2G - /mnt/usb-hdd/backup.tar.part-

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

[infra_hdc]

_rm !!!

А теперь внимание, правильный ответ:

Код: Выделить всё

#!/bin/sh
tar -cvO /my-precious-data/ | split -b 2G - /mnt/usb-hdd/backup.tar.part-

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

Прошу обратить внимание на то, что я привел готовый рабочий скрипт, лично протестированный. Этот скрипт помог решить мне конкретную практическую проблему: слить на внешний USB-жескарь инфу с двух рядом стоящих разделов, разных файловых систем: NTFS и ext3, потом грохнуть эти разделы и на их месте создать новый раздел ext3, размер которого равен сумме размеров предыдущих и закачать данные с бэкапа на новый раздел. Конечно, я не гарантирую, что в вашей конкретной системе скрипт будет работать, хотел просто показать идею.

Автор срочно прочитал маны и выяснил с помощью команды man tar | grep -- -v, что используемый в Вашем примере ключ -v выводит более подробную инфу в ходе копирования. Куда выводит, не в stdout ли? Вот по этому поводу есть сомнения, т.к. в мане вообще нет инфы, конфликтуют ли ключи -v и -O или как-то хитро интеллектуально подстраиваются друг под друга. Более того, насчет параметра -O в мане черным по белому написано, что он предназначен для того, чтобы файлы "разжимались" в stdout, а Вы в вашем примере использовали ключ -с, который предназначен не для разжимания файлов из архива, а для сжимания их в архив; таким образом, у меня складываются сомнения также и в том, что Вы правильно употребили сочетания ключей -O и -c в своей команде.

rm_, Вы уверены, что со stdout команды tar через конвеер на stdin команды split не попадет смесь "лога" и "бекапа" ?? Очень прошу, пожалуйста проверьте это практически, и сообщите, чтобы не быть голословным

[rm_]

Вы уверены, что со stdout команды tar через конвеер на stdin команды split не попадет смесь "лога" и "бекапа" ?? Очень прошу, пожалуйста проверьте это практически

Вы вместо того чтоб флудить таким количеством умных букв, пошли бы, и проверили бы мой вариант сами.
Хинт: он работает нормально.

[infra_hdc]

Вы уверены, что со stdout команды tar через конвеер на stdin команды split не попадет смесь "лога" и "бекапа" ?? Очень прошу, пожалуйста проверьте это практически

Вы вместо того чтоб флудить таким количеством умных букв, пошли бы, и проверили бы мой вариант сами.
Хинт: он работает нормально.

1. Из Вашей репликти немного непонятно что Вы хотите: сказать что Ваш скрипт работает нормально, и чтобы я в это поверил, или чтобы я его протестировал и доложил Вам? Какой смысл его тестировать если он и так работает? Но в таком случае вы должны уметь подробно объяснить почему он работает, хотя работать, как я показал, не должен.
1.1. Жду ответа на сомнения по поводу ключа -O
2. Ничего, что я как зачинатель проекта позволю себе немного покомандовать в этой теме?

[rm_]

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

[infra_hdc]

infra_hdc
И как в Windows это всё обратно сливать? Установить Cygwin с кучей утилит, тратить время на сливание? Спасибо. Я лучше драйвер ext2fsd установлю в Windows.

В Windows ничего сливать не надо, т.к. я мыслил в другом направлении == по возможности избавиться от Windows вообще. Оставил двойную загрузку только потому, что для моей модели резалки DVD ASUS DRW-1814BL до сих пор время от времени выходят обновления прошивки, и они в виде exe-файла, виндового == по-другому как из-под Windows не прошьешь. На моем USB-жескаре == мухи (Windows) отдельно котлеты (Linux) отдельно. И бэкапы у каждого свои. Но для Винды отдельный USB-жескарь делать будет большой честью. Разумеется, драйвер ext2/3 для Windows == в некоторых случаях разумное решение.

[infra_hdc]

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

Файлы архива на внешнем диске занимают примерно 82%. Команда простого чтения сырого раздела в "заглушку"

Код: Выделить всё

time dd if=/dev/sdg1 of=/dev/null

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

[rm_]

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

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

[infra_hdc]

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

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

Конечно практический опыт хорош, но давить батоны == удел виндузятников.
Я разобрался в том, как работает Ваш скрипт, проделав эту работу вместо Вас: при использовании ключа -O весь вывод логов идет в stderr. Об этом можно было написать в манах?? Вот так, без объявления войны взяли и переправили на другой дескриптор, ничего не сказав конечному пользователю . Для сравнения, в моих скриптах == все логи выводит в stdout, а файлы логов stderr == нулевые.

Код: Выделить всё

#!/bin/sh
PATH_FROM=/mnt/bigtemp/oldstore/NIX/T2/7.0-rc2/
tar -cvO ${PATH_FROM} 2>backup.log | split -b 2G - store/backup.tar.part-

Выводы:
1. Читать маны == не панацея (кстати, даже в info tar нет этой полезной инфы).
2. rm_ объявляю благодарность