Показаны сообщения с ярлыком Восстановление. Показать все сообщения
Показаны сообщения с ярлыком Восстановление. Показать все сообщения

понедельник, 19 апреля 2010 г.

Винтовые проблемы

Давненько я не заходил в этот блог. Так получилось, что времени было мало а дел много. А еще серьезно трухануло меня после того, как Убунта на моем домашнем компе стала виснуть или вываливаться в ребут. Оказалось, что стал сбоить винчествер. Первое, что пришло в голову - надо спасать данные. Кое-что пергнал на DVD и флешки, но многое оказалось не подъемным. Например хомяк моей дочери, где только "полезной" ей информации скопилост больше 50 гигов.

В общем, протестровал винт и понял, что не лишне купить новый. Ну и купил - WD 3.5 SATAII 500GB 7200rpm 16Mb Cache Caviar Blue. Потом попытался поставить Ubuntu 10.04 beta 2, но неудачно, о чем рассказывал здесь. Но линуксойды не сдаются, и я таки втулил, еще одну Убунту, но 9.10 и прямо из под винды, и на виндовый раздел, но зато на НОВЫЙ винт :).

Это временная мера. Ща жду когда зарелизится Ubuntu 10.04 и надеюсь, что все нормализуется. Кстати, на старом винте проблемы в основном на разделах FAT. Я большинство информации скопировал, но все же очень хочется привести старый винт в порядок и использовать в дальнейшем.

Но задуматься о механизмах, позволяющих сделать восстановление данных с жесткого диска полным и безопасным, все же нужно. Знаю что в Линуксе есть решения. Сам пока не использовал, но боюсь что придется. И под винду таких программ не мало. Есть даже универсальные решения. Например Hetman Uneraser позволяет сделать восстановление информации после форматирования, а это тоже бывает очень полезно, если сгоряча форматнул винт а потом вспомнил, что не сбэкапился :)

воскресенье, 17 января 2010 г.

Восстановление данных по вызову

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

Нашел в сети сайт www.datarc.ru - восстановление данных с любых возможных видов цифровых устройств, а также восстановление RAID массивов и серверов, и еще восстановление информации с жестких дисков HDD, флешек и цифровых фотографий.Все это для жителей Москвы, Питера, Омска и Екатеринбурга.

вторник, 27 октября 2009 г.

Резервное копирование и восстановление MBR

Вам никогда не приходилось восстанавливать затертый MBR? Мне приходилось, и использовал я для этого какие-то утилиты из виндовых загрузочных сборников. А тут нашел рецепт от linuxdzen, за что спасибо.

Сохраняем mbr на дискету:
# dd if=/dev/hdx of=/dev/fd0 bs=512 count=1
где /dev/hdx - жесткий диск, на котором хранится mbr
Пишем mbr обратно:
# dd if=/dev/fd0 of=/dev/hdx bs=512 count=1
Сохраняем mbr в файл:
# dd if=/dev/hdx of=mbr.bak bs=512 count=1
Пишем mbr обратно:
# dd if= of=/dev/hdx bs =512 count=1
Файл лучше хранить в надёжном месте, например на CD или флешке:)


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

Если вам нужны натяжные и подвесные потолки в Екатеринбурге, то обратите внимание на эту ссылку. Доверяйте монтажные работы профессионалам.

четверг, 5 марта 2009 г.

Восстановление файла с поврежденного ext3 раздела

Восстановление файла с поврежденного ext3 раздела

Представьте себе ситуацию: файловая система повреждена, раздел не монтируется, вместо корневого каталога нули.

# mount /dev/md1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/md1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Хорошо, что есть бэкап. Вы смотрите как дела обстоят с бэкапом, и тут вдруг обнаруживаете, что в бэкапе нет одного очень нужного файла. И если можно где-то найти этот файл - то только в недрах погибшего раздела. Оказавшись в подобной ситуации я сразу пожалел, о том что, ранее не интересовался внутренним устройством ext3fs. Что я собственно знаю о ней? Да похоже ничего, иноды там какие-то…


Но делать что-то надо. Детально разбираться времени уже нет, так что погуглив на тему ext3fs, выясняю следующее:

Основные составляющие ext3fs:

  • каталоги
  • указатели inode
  • блоки данных

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

Самое важное, что хранит в себе inode:

  • размер файла
  • id владельца
  • id группы
  • даты модификации/доступа
  • список блоков данных, где собственно и хранится файл

Жаль имени файла нет, было бы удобнее, но почему нет - понятно, имен-то (hardlink-ов) может быть много. А хранятся имена, естественно, в каталогах. Каталог по сути тот же inode, только другого типа, в нем есть та же самая информация о владельце и датах, а главное, в блоках данных хранится список имен файлов и каталогов с номерами соотвествующих inode.

Так же, особо надо отметить, что в списке есть и ссылка на родительский каталог, таким образом, если найти какой-либо каталог на диске, то по ссылкам на родительский каталог, можно будет перемещатся по структуре каталогов. Если конечно структура эта не повреждена.

Это несколько упрощенный взгляд на ext3fs, но сейчас не до деталей и подробностей, файл нужно доставать.

Главный инструмент который нам поможет - debugfs.

debugfs -c /dev/md1
debugfs 1.39 (29-May-2006)
/dev/md1: catastrophic mode - not reading inode or group bitmaps

Посмотрим что там в суперблоке:

debugfs: stats
Filesystem volume name:
Last mounted on:
Filesystem UUID: 24c5e529-02c4-4775-bb9f-e0c1f1b4a676
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: resize_inode dir_index filetype sparse_super large_file
Default mount options: user_xattr acl
Filesystem state: not clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 121831424
Block count: 121806816
Reserved block count: 6090340
Free blocks: 117940889
Free inodes: 121831413
First block: 0
Block size: 4096

В данном случае, размер блока 4096, кол-во инодов - 121831424

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

Создадим файл stat.cmd с содержимым вида:

stat <1>
stat <2>
...
stat <кол-во inode>

Выполним:

# debugfs -f stat.cmd -c /dev/md1 | grep 'Type: dir'

Получим список каталогов:

...
Inode: 32957 Type: directory Mode: 0755 Flags: 0x0 Generation: 1325685135
Inode: 32987 Type: directory Mode: 0755 Flags: 0x0 Generation: 1325685176
Inode: 33025 Type: directory Mode: 0755 Flags: 0x0 Generation: 1325685227
...

Теперь можем посмотреть содержимое каталога:

# debugfs -f stat.cmd -c /dev/md1
debugfs: ls <32957>
32957 (12) . 2590762 (44) .. 32956 (24) china-util.elc
32958 (20) chinese.elc 32959 (24) cyril-util.elc
...

Видим список файлов и что очень важно, видим inode родительского каталога - 2590762, т.е. можем просмотреть его содержимое:

debugfs: ls <2590762>
2590762 (12) . 2590642 (4084) .. 2590760 (20) abbrev.elc
2590765 (20) align.elc 2590771 (20) autoarg.elc
...

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

Но к сожалению, не все так просто когда структура каталогов повреждена, да и посмотрите на кол-во inode в данном случае, поиск всех директорий для 500Gb диска времени займет слишком много.

Другой путь - найти блок данных принадлежащий искомому файлу, с помощью debugfs узнать номер inode, и если все сложилось удачно, вытащить содержимое файла.

Например, нам удалось выяснить что блок 94844 принадлежит искомому файлу, спросим у debugfs номер inode c помошью команды icheck:

debugfs: icheck 94844
Block Inode number
94844 69267

Подумав некоторое время debugfs сказал что inode - 69267. Запросим информацию об этом inode:

debugfs: stat <69267>
Inode: 69267 Type: regular Mode: 0444 Flags: 0x0 Generation: 2933723684
User: 0 Group: 0 Size: 15214
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 32
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x47f3754b -- Wed Apr 2 16:00:11 2008
atime: 0x48002a85 -- Sat Apr 12 07:20:37 2008
mtime: 0x47f3754b -- Wed Apr 2 16:00:11 2008
BLOCKS:
(0-3):94844-94847
TOTAL: 4

Скорее всего по владельцу, группе и размеру уже станет ясно, искомый файл это или нет. Теперь попросим debugfs вытащить содержимое файла, с помощю команды dump:

debugfs: dump <69267> /tmp/69267.file

Если все сложилось удачно, в /tmp/69267.file лежит то, что мы искали.

Остается открытым вопрос, как найти блок данных, принадлежащий файлу. Естественно, придется искать по какой-то подстроке, которую как мы предполагаем, содержит файл.

Первое что приходит в голову - воспользоватся hexdump и grep, например вот так:

cat /dev/sda1 | hexdump -C | grep Linux
...
001fc830 64 69 74 0a 23 20 4c 69 6e 75 78 20 6b 65 72 6e |dit.# Linux kern|
00205470 20 49 53 44 4e 34 4c 69 6e 75 78 0a 23 0a 43 4f | ISDN4Linux.#.CO|
002092d0 63 65 64 20 4c 69 6e 75 78 20 53 6f 75 6e 64 20 |ced Linux Sound |
...

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

Работает она примерно вот так:

cat /dev/sda1 | ./bfind Linux
...
5214 +300 20 2e 63 6f 6d 70 2e 73 6f 66 74 2e 6c 69 6e 75 | .comp.soft.linu|
5214 +376 6d 70 2e 73 6f 66 74 2e 6c 69 6e 75 78 2e 6e 69 |mp.soft.linux.ni|
5214 +423 70 2e 73 6f 66 74 2e 6c 69 6e 75 78 2e 6e 69 78 |p.soft.linux.nix|
...

И главное, работает быстро. Первый столбец - это и есть номер 4k-блока данных.
Если понадобится уточнить содержимое найденных блоков, можно воспользоваться утилитой fsgrab.

fsgrab -b 4096 -c 4 -s 105633828 -f /dev/md1 > /tmp/105633828.block

В данном случае 4 блока по 4096 байта, начиная с 105633828-го будут сохранены в указанный файл.

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

понедельник, 27 октября 2008 г.

Восстановление данных с Windows-систем с использованием Linux

Юникс и другие » Blog Archive » Восстановление данных с Windows-систем с использованием Linux

У всех бывали случаи, когда Windows отказывается грузиться по той или иной причине. Проблема может заключаться в программном или аппаратном обеспечении компьютера и, зачастую, может показаться безнадежной. Однако во многих случаях вам может помочь Linux, имеющий необходимый комплект утилит для восстановления данных, которые могли быть безвозвратно утеряны.

Другой вариант использования Linux - это создание образа отказавшего HDD для последующего его анализа. Конечно же, эти образы не идеальны (для подобных работ используется специально оборудование), но могут помочь разобраться с причинами выхода из строя.
Предполагается, что все восстанавливаемые данные можно скопировать на машину с Linux либо имеется USB-диск достаточного объема. В любом случае для попытки успешного восстановления данных необходимо иметь объем свободного места, равный объему диска для восстановления и плюсом, по меньшей мере, 2 гигабайта. Чем больше у вас свободного места, тем легче будет работать с данными. В обратном случае вероятность успешного заверешения процесса снижается.
Если ситуация становится совсем критичной, то рекомендую вам попробовать сторонние утилиты, такие как Coroner's Toolkit, но им необходимо гораздо больше свободного места для успешной работы. Как правило, необходимый объем места для подобных программ равняется удвоенному размеру диска, который необходимо восстановить.

Я предполагаю, что читатель свободно себя чувствует в командной строке Linux и может выполнять базовые операции по работе с файловой системой (т.е знаком с такими командами как, например, cp, mv, rm, ls и т.п.) В данном случае командная строка является более предпочтительным интерфейсом, нежели GUI. Когда на карту поставлены данные, лучше пользоваться узкоспециализированными утилитами для выполнения всех действий и иметь полный контроль над процессом.

Команды, используемые в этом документе, являются общеупотребительными в среде Unix и могут легко использоваться на многих платформах. Но некоторые сложные скрипты могут потребовать повторного прочтения man-страниц.

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

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

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

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

Самое простое - это создать собственный образ для каждого восстанавливаемого раздела.

Жесткие диски в Linux обычно находятся в каталоге /dev/ и имеют некоторые правила именования, которые нужно запомнить. IDE диски начинаются с букв "hd". Третья буква означает "статус" диска. a (hda) - это primary master, b (hdb) - primary slave, c (hdc) - secondary master и d (hdd) - secondary slave. Все остальные устройства хранения данных (к ним относятся USB, SATA и SCSI-диски) подключаются через SCSI-интерфейс и начинаются с букв "sd" В ядре версии 2.4 была возможность подсоединить IDE-привод через SCSI-интерфейс, но нам это не понадобится.

После подготовки всех "кандидатов" на восстановление, их неплохо бы проверить при помощи команды sfdisk -l Это лучше, чем fdisk, так как посылаемые команды более просты и выполняются в неинтерактивном режиме. Команда требует привилегий суперпользователя.

bash# /sbin/sfdisk -l /dev/hda

Вывод команды содержит информацию о винчестере (количество головок, секторов и цилиндров) и список доступных разделов с краткой информацией о них.
Разделы должны начинаться и заканчиваться на границе цилиндров. К сожалению, старые версии Windows имеют проблемы с дисками, у которых несколько головок и большое количество цилиндров, в результате чего некоторые версии BIOS передавали неверную информацию о реальном положении дел. Поскольку Linux считывает информацию о диске напрямую с винчестера, а windows использует информацию, предоставленную BIOS, то эти данные могут иметь отличаться для различных ОС.

Вот вывод этой команды для винчестера с установленным Linux:

Disk /dev/hda: 9729 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes,
counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/hda1 * 0+ 12 13- 104391 83 Linux
/dev/hda2 13 9728 9716 78043770 8e Linux LVM
/dev/hda3 0 - 0 0 0 Empty
/dev/hda4 0 - 0 0 0 Empty

А вот для винчестера, на котором Linux и Windows находятся в режиме DualBoot:

Disk /dev/sda: 19457 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes,
counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sda1 0+ 891 892- 7164958+ 27 Unknown
/dev/sda2 * 892 10196 9305 74742412+ 6 FAT16
/dev/sda3 10197 10209 13 104422+ 83 Linux
/dev/sda4 10210 19456 9247 74276527+ 5 Extended
/dev/sda5 10210+ 19456 9247- 74276496 8e Linux LVM

Раздел с меткой FAT16 в приведенном примере на самом деле отформатирован в NTFS. Не стоит слишком доверять меткам на разделах. Очень часто windows-разделы имеют метки FAT16, W95 FAT32, NTFS или похожие на них.

Основная команда для создания образа - это:

bash# dd if=[device] of=[imagename] conv=noerror

dd производит чтение из входного файла (if - input file), пропускает данные через указанные фильтры и записывает в конечный файл (of - output file). Если опция of не указана, то вывод производится в стандартный поток. Опция conv=noerror говорит о том, что dd следует продолжить считывание несмотря на ошибки чтения, которые, в большинстве случаев, присутствуют на поврежденных дисках.

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

простейшая команда для переноса образа на примонтированный раздел выглядит так:

bash# dd conv=noerror if=/dev/sda1 of=/root/recovery.img

Эта команда скопирует содержимое раздела /dev/sda1 в файл /root/recovery.img Этот файл может быть примонтирован как стандартное устройство loopback.

Так как dd может писать в стандартный поток, мы можем использовать пайп для передачи информации на удаленную систему, посредством ssh. Это делается так:

bash# dd conv=noerror if=/dev/sda1 | ssh user@host 'cat >
recover.img'

Для уменьшения объема передаваемой информации можно воспользоваться архиватором:

bash# dd conv=noerror if=/dev/sda1 | gzip | ssh user@host
'gunzip > recover.img'

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

Монтирование образа
После создания образа необходимо сделать две папки (для точки монтирования и для восстановления):

bash# mkdir recover_src recover_dst

После чего можно примонтировать туда образ (как стандартное устройство loopback) при помощи следующей команды:

bash# mount -t [type] -o loop /path/to/image recover_src

К примеру, если ваш образ recovery.img снят с NTFS-раздела, то замените [type] на ntfs. Все FAT-разделы монтируются как vfat.

Не все дистрибутивы Linux имеют встроенную поддержку NTFS. Например, у Knoppix она есть, у Fedora нет. Вы можете найти драйвера для поддержки NTFS на сайте сторонних производителей или пересобрать ваше ядро с поддержкой этой файловой системы. (довольно нетривиальная задача для новичка в linux - прим. переводчика) Если вы не можете найти драйвера, используйте Knoppix.

В linux обеспечена поддержка лишь чтения с NTFS-разделов. Запись на них из linux считается небезопасной и может привести к повреждению или полной потере данных. Тем не менее имеются решения для записи на NTFS из linux. Однако их обзор вызодит за рамки этой статьи.

Восстановление данных в безопасное место
Как только образ примонтирован, вы можете использовать cp или подобную команду для копирования ваших данных в безопасное место. Также вы можете записать их на CDROM или перенести на USB-диск.

Или вы можете перенести данные на flash-диск, примонтировать его и продолжать процесс восстановления уже используя его в качестве носителя.

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

Несколько слов о mkisofs и cdrecord
Часто необходимо записать восстановленную информацию на CDROM. Из командной строки это делают с помощью двух утилит: mkisofs и cdrecord На компакт-дисках используется файловая система, определенная стандартом ISO 9660. Это ФС со многими возможностями, но и с довольно большими ограничениями (например на длину имени файла, имена файлов нечувствительны к регистру, не сохраняет права доступа к файлам) Для того, чтобы немного снизить имеющиеся ограничения были разработаны два расширения для нее: это Joilet, используемое в Windows и RockRidge, используемое в UNIX.

Мы рекомендуем использовать оба расширения для улучшения переносимости.

Следующая команда создает iso-образ recovery.iso из содержимого директории recovery_dst:

bash# mkisofs -JR -o recovery.iso recovery_dst

Однако полученный образ еще и необходимо записать на диск. Это делается при помощи cdrecord:

bash# cdrecord dev=/dev/cdrom –data recovery.iso

Для более подробной информации о процессе копирования можно использовать ключ -v

После проверки записанного диска смонтируйте его и проверьте его читаемость. Я заметил, что некоторые CD-R плохо читаются после записи на высоких скоростях. Поэтому можно искусственно ограничить скорость записи диска:

bash# cdrecord dev=/dev/cdrom speed=4 -v –data recovery.iso

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

Coroner's Toolkit (TCT) - так называется набор приложений для работы с теми файловыми системами, которые настолько повреждены (например после "горячего" выключения), что не видятся штатными средствами ОС. Этот набор можно найти на http://www.porcupine.org/forensics/tct.html

В Coroner's Toolkit входит несколько утилит для "экстремального" восстановления данных. Одна из них, lazarus, мощный кроссплатформенный инструмент. Она читает структуры данных напрямую с поверхности диска и пытается восстановить файловую систему по полученным результатам. Иногда она находит фрагменты, которые будут использованы намного позже, а в некоторых случаях, если не было перезаписи, находятся фрагменты удаленных файлов, которые в большинстве случаев могут быть восстановлены.

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

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

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

Оригинальный текст

среда, 27 февраля 2008 г.

Сохраним свой LINUX - бэкап партиции с помощью PING (Partimage Is Not Ghost) | Kubuntu

Сохраним свой LINUX - бэкап партиции с помощью PING (Partimage Is Not Ghost) | Kubuntu

Bazilio написал 24 Февраля, 2008 - 14:56 |

Мне надоело переустанавливать Kubuntu после каждого неудачного эксперимента. А поскольку я эксперементирую довольно часто, доволно часто случается так, что первоначальное состояние системы уже не востановить.
Я решил сделать бэкап настроенной и рабочей системы. Но не с помощью всяких там "Keep - Backup System", ведь иногда и загрузиться то не удаётся нормально, а путём копирования партиции жёсткого диска, куда установлен Linux.
Сначала была идея сделать это с помощью винды, но нашёл ничего бесплатного и юзабельного. Погуглив, натолкнулся на такую шикарную вещь, как PING (Partimage Is Not Ghost). "PING is a live Linux ISO, based on the excellent Linux From Scratch (LFS)" - PING это Live CD, базирующийся на LFS.
Взять это чудо можно тут http://ping.windowsdream.com/ping/download.html

А вот как этим пользоваться:
Для начала нужно записать iso образ на диск. Далее следуем по шагам:
1) Загружаемся с этого диска
2) На первый вопрос (или предложение :) ) нажимаем Enter
3) Далее OK (нажатием Enter)
4) Нас спрашивают, что сделать, когда мы закончим. Я выбрал перезагрузку
5) Выбираем, где хранить\от куда востанавливать. Я выбрал локально, сетевое расположение не пробовал.
6) Выбираем партицию, которую хотим забэкапить. (Для востановления надо выбрать первую опцию) (Нужный пункт выбирается с помощью пробела)
7) Выбираем партицию, на которую хотим сохранить наш бэкап
8) Выбираем название каталога, куда сохраняь. Я выбрал "\"
9) Выбираем последний пункт: Create_New_Image
10) Вводим имя образа. (Будет создан каталог с этим именем, а в нём уже файлики бэкапа, созданные системой)
11) Выбираем сжимать или не сжимать наш образ. Я выбрал не сжимать, чтобы это всё побыстрей произошло.
12) NO
13) YES

Мой образ занял всего 3.85 Гигабайт. Заметьте, что делается образ не всей партиции (у меня она 25 гигов весит), а только занятого места!
По времени это заняло 5 минут.

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

четверг, 7 февраля 2008 г.

10 способов восстановления удалённых файлов в linux


From: Александр Саввин <savvin@mail.ru.>

Newsgroups: email
Date: Mon, 4 Feb 2008 14:31:37 +0000 (UTC)
Subject: 10 способов восстановления удалённых файлов в linux


Источник: Блог http://www.goitexpert.com, 10 Ways To Recover Deleted Files In Linux
Перевод: Александр Саввин (savvin@mail.ru)
Оригинал перевода

Я никого не знаю, кто хотя бы раз случайно не удалил файл и не попытался бы
его восстановить. В Windows восстановление файлов - относительно легкая операция.
Но как это сделать в Linux? Точнее, если что-то было удалено из командной строки
в экране Терминала, как восстановить этот файл? В некоторых дистрибутивах Linux,
таких как Ubuntu, существует корзина, но в большинстве других её нет. Удалённые файлы
просто отправляются в небытье.

Вот хороший совет для новичков - измените команду rm:

alias rm='rm -i'


Таким образом при каждом удалении файла система будет запрашивать подтверждение.

Второй совет - делать резервные копии. Для копирования важных каталогов
и файлов на другую систему или раздел можно воспользоваться утилитой rsync.
С помощью crontab это можно делать ежедневно или даже ежечасно.

Итак, рассмотрим 10 способов восстановления удалённых файлов:

1. Recover - автоматизирует
некоторые шаги восстановления утерянного файла, описанные в
Linux Ext2fs Undeletion Mini-HOWTO
(перевод).
Эта утилита значительно увеличит эффективность восстановления. Она рекомендуется тем,
кто не знает, как восстанавливать файлы.

2. athena-delete - была написана для
проекта Athena по запросам множества новых пользователей UNIX, случайно удалявших
нужные им файлы.

3. unrm - небольшая
консольная утилита, которая при некоторых условиях, может восстановить почти 99% удалённых
данных (похожа на утилиту undelete в DOS). Перед её использованием внимательно прочитайте
файл FAQ и желательно Linux Ext2fs Undeletion Mini-HOWTO .

Применение:

unrm [-b (no block padding)][-e (every block)][-f fstype][-vW] device [block...]


4. gET_iT_i_sAY - средство восстановления
файлов для файловых систем Ext2/Ext3. После установки могут быть восстановлены текущие
файлы и новые созданные файлы в /root и /home. Она позволяет пользователям восстановить все
удалённые файлы, восстанавливать файлы, принадлежащие указанному пользователю, выводить
(dump) данные из местанахождения файлов и восстанавливать файлы определённого типа, типа
текста или MP3. Имеется также анализатор, помогающий пользователям во время восстановления.

5. e2undel - интерактивный консольный инструмент
для восстановления данных из удалённых файлов в файловой системе ext2 в Linux. Включает в
себя библиотеку, позволяющую восстанавливать удалённые файлы по именам. e2undel не
управляет внутренними структурами ext2 и не требует дополнительных средств. Она может быть
полезна без знания внутреней структуры ext2.

Применение:

e2undel -d device -s path [-a][-t]


-d файловая система, где искать удалённые файлы
-s каталог, в который сохранять восстановленные файлы
-a работать на всех файлах
-t попытаться определить тип удалённых файлов без имён
-l просто выдать список валидных файлов в лог-файл undel

Устройство должно быть отмонтировано и путь не должен указываться вместе с устройством.

6. anyfs-tools - позволяет восстанавливать и
конвертировать файловые системы с минимальным использованием дополнительного дискового
пространства. В отличие от других средств восстановления anyfs-tools не копирует все
обнаруженные файлы на другие диски (или разделы), а просто сохраняет информацию о
размещении блоков файлов во внешней таблице inode. После восстановления пользователь может
примонтировать повреждённую файловую систему с помощью anyfs и внешней таблицей inode и
затем работать со всеми восстановленными файлами в любой программе.

7. rfs - консольный скрип для создания и
обновления локального запасного системного диска. Основное назначение - быстрое
восстановление работающей системы после падения. В данном случае "быстрое" означает время,
затрачиваемое им до перезагрузки машины. rfs является сокращением от 'replication of
filesystem' (копия файловой системы). Аналогично rsyncbackup, rfs основан на rsync.

8. e2retrieve - средство восстановление
данных Ext2, работающее с обрезанными или частичными файловыми системами. Оно очень
полезно для получения данных при повреждении диска из LVM. Оно не восстанавливает
файловую систему, но извлекает и копирует большинство данных, которые оно может получить
из "сырых" данных Ext2.

9. findfile - набор средств для восстановления
файлов в файловых системах с разрушенными каталогами, таблицами размещения и т.п. Он может
быть полезен при разрушенной таблице разделов (или больше) жёсткого диска или при повреждённой
карте памяти от цифровой камеры.

10. TestDisk - средство для проверки и
восстановления разделов. Работает со следующими разделами: FAT12, FAT16, FAT32, Linux,
Linux swap (версий 1 и 2), NTFS (Windows NT/W2k/2003), BeFS (BeOS), UFS (BSD), JFS, XFS и
Netware.