посоветуйте backup тузлу (сабж)

[gpamozg]

В общем:
/dev/sda1 ntfs
/dev/sdb --полностью под линукс.
Требуется из-под линукса организовать бекап /dev/sda1 т.е c:\
Пробывал dd if=/dev/sda1 of=/home/user/backup_c_date.bak, но бекап получается 50гб.
Нужен какой-то бекапельщик, который будет посекторно копировать информацию с /dev/sda1 и mbr и сжимать его, чтобы не получалось 50гб один бекап. Спасибо за внимание.

[pasis]

если ты хошь бекапить весь раздел, который 50Гб как один образ, то он 50Гб и будет. если хочешь сжать, то не указывай of=, тогда будет вывод в stdout, который перенаправляешь в архиватор, например:

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

dd if=/dev/sda1 | bzip2 > /home/user/backup_c_date.bak.bz2

Но архив все равно выйдет довольно большой. Можно бекапить сами файлы с файловой системы. Для этого смонтировать sda1 и просто запаковать архиватором (например 7z) нужные каталоги. Проблема в том, что ФС разбрасывает файлы и фрагменты и вообще всю служебную инфу по всему разделу, и если ты хочешь бинарный бекап раздела, то тут от большого размера никуда не деться, тем более, что содержимое удаленных файлов находится физически на разделе.

[Atolstoy]

В общем:
/dev/sda1 ntfs
/dev/sdb --полностью под линукс.
Требуется из-под линукса организовать бекап /dev/sda1 т.е c:\
Пробывал dd if=/dev/sda1 of=/home/user/backup_c_date.bak, но бекап получается 50гб.
Нужен какой-то бекапельщик, который будет посекторно копировать информацию с /dev/sda1 и mbr и сжимать его, чтобы не получалось 50гб один бекап. Спасибо за внимание.

Посекторно - это уже создание образа раздела.
А так смотрим тут.

[gpamozg]

Да в основном в linux'e бекап тузлы для бекапа по сети виндовс, но не локальный бекап, а мне нужен именно локальный бекап.

[mirlas]

dump - best of the best of the best (ц)

[serzh-z]

dump - best of the best of the best (ц) smile.gif

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

Очень неприятно бывает узнать, что dump не поддерживает ext4, хотя пишет "operation successfully finished", спустя несколько дней, начав попытку восстановления носителя из дампа и обнаружив там сотни гигабайт зарезервированных файлов с одинаковым мусором внутри вместо данных.

[Flaming]

Но архив все равно выйдет довольно большой. Можно бекапить сами файлы с файловой системы. Для этого смонтировать sda1 и просто запаковать архиватором (например 7z) нужные каталоги. Проблема в том, что ФС разбрасывает файлы и фрагменты и вообще всю служебную инфу по всему разделу, и если ты хочешь бинарный бекап раздела, то тут от большого размера никуда не деться, тем более, что содержимое удаленных файлов находится физически на разделе.

Можно сначала примонтировать файловую систему на sda1, удалить оттуда весь мусор и временные файлы (можно автоматизировать скриптом), оставить только нужное. Затем создать пустой файл, забитый нулями на весь остаток файловой системы.
dd if=/dev/zero of=/mnt/sda1/filezero.bin
Когда место закончется, работа dd прервётся, этот файл можно будет удалить, отмонтировать ФС, и начать бекапить.
Вместо bzip2 лучше указать gzip (он быстрее). Нули всё равно будут сжиматься хорошо, а нам, как я понял, важнее скорость, чем объём.
Ещё хорошо бы дефрагментировать, но из-под линукса сделать уже вряд ли получится.

[ormorph]

неплохая команда еще dcfldd - переделанная dd но работает быстрее, плюс много добавлений, специально для исследования
если необходимо разрезать образ на отдельные файлы то подойдет утилита split
пример образ длиною 1603899392 байт:

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

# split --bytes=699m test.img sys

разрезает образ на файлы размером 699m

ls #вывод(результат работы split)

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

test.img
sysaa
sysab
sysac

чтобы собрать обратно несколько файлов в один, то следует выполнить

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

cat sysaa sysab sysac >disk.img

вот еще некоторые утилиты которые тоже могут быть использованны как для сохранения данных, так и востановления данных с испорченных носителей:
ddrescue
dd_rescue
safecopy
думаю что способов довольно много, также можно использовать просто cat и cp если данные на жестком диске целые.
ну а для сжатия можно просто использовать gzip или bzip2

[Flaming]

неплохая команда еще dcfldd - переделанная dd но работает быстрее, плюс много добавлений, специально для исследования

Например? Чем она лучше dd? И чем отличается от ddrescue?

[ormorph]

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

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

dcfldd if=/dev/hdb1 of=test.img

в случае с ddrescue по возможности востановления данных уступает, но в dcfldd присутствует такая вещь, как распечатка хеша md5 полученных данных в логфайл.
пример команды:

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

dcfldd if=/dev/hdb5 of=test.img bs=4096 hashwindow=732954624 hashlog=hashlog conv=noerror,sync

параметр bs создает режим записи по блокам размером 4096, параметр hashwindow в данном случае будет генерировать хеш для каждых 699 мегабайт с использаванием алгоритма md5 и распечатывать в логфайл, параметр hashlog создает логфайл в который идет распечатка информации, noerror пропускает ошибочные байты, sync заменяет ошибочные байты нулями
в принципе не сильно отличается от команды dd, просто есть кое какие дополнения.

[Flaming]

ну и по сравнению с dd показывает вывод в консоли сколько уже скопированно.

А вот это интересно... Поднадоело молчаливый dd =) ща поставлю.

[mirlas]

dump - best of the best of the best (ц) smile.gif

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

Очень неприятно бывает узнать, что dump не поддерживает ext4, хотя пишет "operation successfully finished", спустя несколько дней, начав попытку восстановления носителя из дампа и обнаружив там сотни гигабайт зарезервированных файлов с одинаковым мусором внутри вместо данных.

Не стоит говорить "не стоит давать такие советы" В вашем примере может быть проблема не с dump, а собственно, с ext4, которая как известно показывала пока зубки. Это раз. Потом не вижу отрицающего аргумента, говоря что это древнее средство. Да - древнее (прикиньте, и до сих пор развивается) - и это плюс, т.к. код стабильный. Всегда пользовался dump'ом и крайне доволен. Как известно, популярные средства, типа Amanda, тоже на нем базируются. Какое средство предложите вы? Кстати, dd (если уже говорить о древности и магичности, что подтверждает и ее синтаксис) - самая старая программа для "бэкапа", т.к. была написана еще для перфокарт и делать образ диска, когда нужно бэкапить некоторые каталоги - не самое хорошее решение.

[gpamozg]

dump - best of the best of the best (ц) smile.gif

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

Очень неприятно бывает узнать, что dump не поддерживает ext4, хотя пишет "operation successfully finished", спустя несколько дней, начав попытку восстановления носителя из дампа и обнаружив там сотни гигабайт зарезервированных файлов с одинаковым мусором внутри вместо данных.

Не стоит говорить "не стоит давать такие советы" В вашем примере может быть проблема не с dump, а собственно, с ext4, которая как известно показывала пока зубки. Это раз. Потом не вижу отрицающего аргумента, говоря что это древнее средство. Да - древнее (прикиньте, и до сих пор развивается) - и это плюс, т.к. код стабильный. Всегда пользовался dump'ом и крайне доволен. Как известно, популярные средства, типа Amanda, тоже на нем базируются. Какое средство предложите вы? Кстати, dd (если уже говорить о древности и магичности, что подтверждает и ее синтаксис) - самая старая программа для "бэкапа", т.к. была написана еще для перфокарт и делать образ диска, когда нужно бэкапить некоторые каталоги - не самое хорошее решение.

Самый ее большой недостаток в том, что она не умеет пропускать нули. К примеру у меня раздел 50гб и он заполнен только на 5%, мне нужно забекапить именно эти 5% информации. Бекап получается не 5гб, а полные 50. Вопрос: зачем бекапить нули ? PS: раздел ntfs

[drBatty]

Самый ее большой недостаток в том, что она не умеет пропускать нули.

сожмите.
Кстати, cp на ext3 умеет создавать разряжённые файлы - если там так много нулей, то после копирования файл в 50Гб займёт 5.

7z для бекапов плохая идея - бекапится надо часто, восстанавливаться - никогда (в идеале). 7z и прочие архиваторы (xz,bzip2,...) дают копеечный выигрыш, однако жмут в разы дольше, и всё тормозят (даже с nice, из-за их пожирания памяти, 1-2Гб это немного для сжатия). gzip даст намного более лучший результат.

Для бекапа у команды cp имеется множество опций, посмотрите мануал...

Кстати, tar тоже хорош для бекапов, он сохранит и права, и времена, и ссылки.

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

угу. особенно когда полно других почти таких-же древних утилит вроде tar'а (это уже для магнитных лент).

[gpamozg]

некоторые вещи на нтфс прочитать можно только на уровне секторном, так что метод с архиваторами просто напросто отпадает. Кстати мбр не скопируешь таром заодно, ну если только dd не копировать мбр и всовывать в бекап(хихи), но выше аргумент который и это рубит на корню(применение архиваторов для живого виндовозерного раздела).

[enko]

Может стоит посмотреть app-backup/luckybackup ?

[Flaming]

Для бекапа у команды cp имеется множество опций, посмотрите мануал...

Тогда уж rsync.
gpamozg, а смысл mbr таром копировать? Это может сделать dd за одну секунду. Да там и сжимать нечего...
dd if=/dev/sdb1 of=/path/to/image bs=512 count=1
И сжимать смысла нет - 512 байт, а кластеры на большинстве ФС всё равно от 4 килобайт идут.

[drBatty]

некоторые вещи на нтфс прочитать можно только на уровне секторном

а зачем бекапить мбр и прочее? лично мне достаточно только своих данных.

Это может сделать dd за одну секунду. Да там и сжимать нечего...
dd if=/dev/sdb1 of=/path/to/image bs=512 count=1

тоже верно.

[mirlas]

На самом деле, мне кажется, что делать бэкап нтфс из под линуха - не совсем правильно. Во-первых, права все равно не сохранятся. Во-вторых восстанавливать все равно придется под виндой скорее всего. По этому, бэкап маздайского раздела лучше делать чем-то вроде встроенного NT-backup (очень даже ничего прога) либо каким-нить nnbackup или кучей других бесплатных утилей. А если уже так нужно бэкапить данные с раздела нтфс, то лучше всего, наверно дейстивительно tar/gzip/bzip2/cp/cpio/dump и т.д. Оно и логичнее - сохранить нужно файловые объекты, а не абстрактные сущности NTFS. Так ведь?
Кстати, не совсем понятно, почему в мане по дампу написано бэкап ext2/ext3, когда эта программа появилась за долго до этих файловых систем. Собственно у меня она делает бэкапы на freebsd. Может конечно, ГНУтая версия лишена некоторого функционала. В любом случае, это легко проверить...

[gpamozg]

выполняется с 20:04 до теперешнего часа
dd if=/dev/sda1 | bzip2 -9 > /mnt/d/backup_c_14.01.2010.bak

dd if=/dev/sda1 | bzip2 -9 > /mnt/d/backup_c_14.01.2010.bak
^C70153913+0 records in
70153912+0 records out
35918802944 bytes (36 GB) copied, 12589.3 s, 2.9 MB/s

мухаха, из 50гю только 36 скопировалось и запаковалось. Прям "вертолет", что еще могу сказать. Паковалось все на коре2дуо.

Еще варианты есть ? Просто вы не понимаете говоря скопировать все с помощью cp или программ, которые работать будут на уровне фс, на уровне фс cp и подобные полностью все не забекапят т.к некоторые вещи cp отписывается что нет доступа к ним. Так что нужно копировать на низком уровне блоки винта, а потом паковать. Вообще о чем мы говорим ? Мы будем бить по воробьям из пушки. Вы предлагаете паковать все данные, а их по сути дела ненужно паковать, потому что там всё бинарное и пакование даст ~3-5% сжатия в лучшем случае. Гараздо лучший алгоритм таков(интересно почему это не реализовано до сих пор в dd):
1) методично перебираем на низком уровне блоки
2) если появилилось большое кол-во нулей(сканируем к примеру 1000 нулей), то возвращаемся -1000, далее делаем запись, что с вот этого блока по вот этот 10000 нулей, а можно просканить все нули до появления данных и потом сделать запись что вот эти блоки и вот эти пустые и потом прыгнуть сразу на бинарные данные и далее тупо копировать т.е по сути дела просто игнорить нули и делать записи о блоках пустых. Млять, вот это есть правильный алгоритм dd, а не тот, что есть сейчас т.е ответьте мне на вопрос: зачем нужно бекапить пустые блоки если можно просто записать в бекап инфу о месторасположении пустых блоков и все. С таким алгоритмом 50гб раздел заполненный на половину - бекап без сжатия будет 25гб+1%(на запись о пустых блоках, а то и меньше), а в оригинальном dd будет 50гб бекап. Разницу ощущаете ?

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

[serzh-z]

Не стоит говорить "не стоит давать такие советы" wink.gif В вашем примере может быть проблема не с dump, а собственно, с ext4, которая как известно показывала пока зубки. Это раз.

Это проблема dump. Я не доверяю приложению, которое попробовало забекапить ФС неизвестного ей формата, *не проверила структуры и информацию о версии ФС и после этого радостно отрапортовала что-то типа "SUCCESS, BACKUP DONE"*. Это просто непростительная халатность разработчиков dump.

[gpamozg]

Не стоит говорить "не стоит давать такие советы" wink.gif В вашем примере может быть проблема не с dump, а собственно, с ext4, которая как известно показывала пока зубки. Это раз.

Это проблема dump. Я не доверяю приложению, которое попробовало забекапить ФС неизвестного ей формата, *не проверила структуры и информацию о версии ФС и после этого радостно отрапортовала что-то типа "SUCCESS, BACKUP DONE"*. Это просто непростительная халатность разработчиков dump.

Это не проблема, это - КАТАСТРОФА.

[serzh-z]

Это не проблема, это - КАТАСТРОФА.

Именно. Лучше НЕРАБОТАЮЩЕЕ приложение, любым способом отрапортовавшее об ошибке/несовместимых структурах и т.д., после чего остановившееся, чем приложение, работающее НЕПРАВИЛЬНО и сообщающее пользователю, что всё ОК.

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

А разве это секрет? dd, tar, cpio и все прочие утилиты UNIX - родом из бородатых 70-х, и до сих пор ориентированны на поддержку ленточных носителей.

[drBatty]

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

матчасть учить нужно вам: dd делает точный слепок поверхности диска. если вам нужны нули - так они и не займут места на диске (ext3 поддерживает разряжённые файлы, т.ч. этот ваш алгоритм просто никому не нужен - зачем упаковывать нули, которые и так не хранятся). Если у вас нули занимают место - воспользуйтесь cp, или сожмите gzip'ом. Зачем вы решили жать bzip2??? Этот сжиматель для текстовых и похожих файлов, массивы нулей BWT жмёт плохо, и ооочееень доооолгоооо.

И ещё, кто вам сказал, что пустое место на диске из нулей?! На самом деле оно из удалённых файлов, а из нулей оно только сразу после команды dd if=/dev/zero.

Кстати, перед тем как хаять dd удосужитесь мануал к ней прочитать. там написано про bs=..., вы бы ещё по 1 биту копировали...

[drBatty]

Это проблема dump. Я не доверяю приложению, которое попробовало забекапить ФС неизвестного ей формата, *не проверила структуры и информацию о версии ФС и после этого радостно отрапортовала что-то типа "SUCCESS, BACKUP DONE"*. Это просто непростительная халатность разработчиков dump.

наверное в мане перечислены доступные ФС. Хотя да - недоработка :(

А разве это секрет? dd, tar, cpio и все прочие утилиты UNIX - родом из бородатых 70-х, и до сих пор ориентированны на поддержку ленточных носителей.

да ладно! прекрасно они работают. только лишние ключи остались (вроде -f из tar'а). и умолчания для перфокарт (512 байт вроде в dd)

[mirlas]

Не стоит говорить "не стоит давать такие советы" wink.gif В вашем примере может быть проблема не с dump, а собственно, с ext4, которая как известно показывала пока зубки. Это раз.

Это проблема dump. Я не доверяю приложению, которое попробовало забекапить ФС неизвестного ей формата, *не проверила структуры и информацию о версии ФС и после этого радостно отрапортовала что-то типа "SUCCESS, BACKUP DONE"*. Это просто непростительная халатность разработчиков dump.

Программа сделала ровно то, о чем ее просили. Быть может, версия dump, которая у вас была про ext4 не знала, а т.к ext4 из одной линейки со всеми ext'ами, то бэкап и был произведен. Непростительная халатьность, как правило у того, кто не проверяет бэкапы Т.к. любая ОБСАЛЮТНО программа может дать сбой. По поводу dump, дам ссылку и приведу цитату:
http://www.freebsd.org/doc/ru/books/handbo...kup-basics.html

17.12.7. Какая программа резервного копирования самая лучшая?

dump(8) Точка. Elizabeth D. Zwicky протестировала все программы резервного копирования, обсуждаемые здесь. Беспроигрышным вариантом для сохранения всех ваших данных и особенностей файловых систем UNIX является dump. Элизабет создала файловые системы, содержащие большое количество необычных элементов (и некоторых не так уж необычных) и тестировала каждую из программ, выполняя резервное копирование и последующее восстановление этих файловых систем. В число необычных элементов входили: файлы с дырами, файлы с дырами и блоком пустого места, файлы с необычными символами в их именах, нечитаемые и незаписываемые файлы, устройства, меняющие свой размер во время резервного копирования, файлы, создаваемые и удаляемые во время копирования и тому подобное. Она представила результаты на конференции LISA V в октябре 1991 года. Посмотрите ссылку на сайте torture-testing Backup and Archive Programs.

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

По приводимой ранее ссылке, первым в списке находится сайт:
http://www.linuxlinks.com/article/20090105...803/Backup.html

Где вы так же можете узнать про "плохую, бородатую" dump. И думаю, если бы дела с dump были так плохи, об этом было бы широко известно.

[rm_]

<censored> partimage <censored>, <censored> вашу <censored>!
Edit: пардон, не сдержался, но это все равно что если бы в теме "чем бы забить гвоздь", после двух страниц никто так и не вспомнил про молоток.

[kma21]

rm_, Вас могут наказать за шрифт =)

gpamozg, поначалу понимал, что Вы хотите (моя версия Windows+программы для быстрой развЁртки при случае краха системы или ещЁ чего-то). Но потом, честно говоря, стал не понимать. Вроде дали архиваторы для образов dd, ещЁ пару программ привели в пример, однако Вы делаете не правильно и возмущаетесь...

[serzh-z]

как правило у того, кто не проверяет бэкапы

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

[drBatty]

Беспроигрышным вариантом для сохранения всех ваших данных и особенностей файловых систем UNIX является dump

а теперь объясните: зачем сохранять особенности ФС???
солить их что-ли? ну зачем они вам?

программы для быстрой развЁртки при случае краха системы

ну и зачем нужна "быстрая развёртка"? у вас крах системы раз в неделю по пятницам?
почему все так борются за "быстроту" не там где надо?
как маздайщики: ставить чистую корпоративку, потому пихать туда кучу софта, потом всё это акрониксом на 5 DVD... 3 дгня работы, за то восстановление за 2 минуты.
только это восстановление системы, со старыми программами.
А нужны - данные пользователя. ВАМ они нужны, ОС и так поставить можно, и это не маздай, Linux не падает сам по себе.

ЗЫЖ систему тоже надо бекапить, для того, что-бы не настраивать её после краха. Именно для этого все настройки хранятся в /etc
(в идеале конечно)