The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Использование dump/restore и типы фс."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Файловые системы, диски / Linux)
Изначальное сообщение [ Отслеживать ]

"Использование dump/restore и типы фс."  +/
Сообщение от stakado email(ok) on 29-Июл-09, 13:16 
Здравствуйте!
Решил пока есть возможность и свежепоставленный линух попробовать создавать/восстанавливать резервные копии, для этой цели выбрал dump/restore.

Резерные копии сделались, вроде всё хорошо. Решил попробовать восстановить и тут возникли проблемы. Для экспериментов выбрал /home (уст-во /dev/md2).
В мане про restore описана опция r - восстановление полностью файловой системы. Как описано в мане отформатировал раздел:
mkfs -t ext4 /dev/md2
Примаунтил, зашёл в эту папочку:
mount /dev/md2 /mnt
cd /mnt
И натравил туда restore:
restore rf /temp/home-2009-07-29.dump
Он вроде выполнился успешно, ни на что не ругался. Но когда начал смотреть содержимое /mnt увидел, что все папки на месте, а вот в содержимом файлов появились изменения. Файлик stakado/.bashrc стал иметь следующий вид:
[root@zeus mnt]# cat stakado/.bashrc
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww[root@zeus mnt]#
Что явно не верно, таким он не был. Так же перед бекапом создал текстовый файлик с небольшим текстом, после восстановление этот текст тоже изменился:
[root@zeus stakado]# cat before.txt
wwwwwwwwwwwww[root@zeus stakado]#
Посдкажите, пожалуйста, что сделал не правильно.

Так же есть ещё вопросик. Есть два винта - sda, sdb, на них одинаковые разделы sdX1, sdX2, sdX5, sdX6. Из них сделаны рейды1:
[root@zeus stakado]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid1 sda7[0] sdb7[1]
      231295680 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      521984 blocks [2/2] [UU]

md1 : active raid1 sda6[0] sdb6[1]
      8184960 blocks [2/2] [UU]

Всё вроде работает, всё ок. fdisk выводит следующее:
[root@zeus stakado]# fdisk -l

Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0001ade7

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          65      522081   fd  Linux raid autodetect
/dev/sda2              66       30401   243673920    5  Extended
/dev/sda5              66         587     4192933+  82  Linux swap / Solaris
/dev/sda6             588        1606     8185086   fd  Linux raid autodetect
/dev/sda7            1607       30401   231295806   fd  Linux raid autodetect

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          65      522081   fd  Linux raid autodetect
/dev/sdb2              66       30401   243673920    5  Extended
/dev/sdb5              66         587     4192933+  82  Linux swap / Solaris
/dev/sdb6             588        1606     8185086   fd  Linux raid autodetect
/dev/sdb7            1607       30401   231295806   fd  Linux raid autodetect


А вот blkid говорит, что партишены sda1, sda5 имеют тип ехт3, а должно быть mdraid:
[root@zeus stakado]# blkid
/dev/sr0: LABEL="Free-20091-x86_64" TYPE="iso9660"
/dev/sda1: UUID="2e6ee609-a2d9-47e3-9d75-29f133107d59" TYPE="ext3" SEC_TYPE="ext2"
/dev/sda5: TYPE="swap" UUID="54860126-f1ed-4e8f-8820-4327640c0cfa"
/dev/sda6: UUID="82bdc1ee-13a7-45a4-805b-64fa4732f8d0" TYPE="ext3" SEC_TYPE="ext2"
/dev/sda7: UUID="e7ded5da-b4b1-684b-da96-f4eca5790866" TYPE="mdraid"
/dev/sdb1: UUID="ed3db3d2-0f6d-30b2-2606-9de751fb5995" TYPE="mdraid"
/dev/sdb6: UUID="66dc3b1e-2ed9-9cbd-8c66-eaf738f3bc87" TYPE="mdraid"
/dev/sdb7: UUID="e7ded5da-b4b1-684b-da96-f4eca5790866" TYPE="mdraid"
/dev/md0: UUID="2e6ee609-a2d9-47e3-9d75-29f133107d59" TYPE="ext3"
/dev/md2: UUID="7e2cf99c-e0d0-433a-9196-9cbb80d5e9b0" TYPE="ext4"
/dev/md1: UUID="82bdc1ee-13a7-45a4-805b-64fa4732f8d0" TYPE="ext3"

Это просто blkid врет или всё же где-то что-то сделано не верно и в дальнейшем может родить сложности?

Заранее благодарен.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Использование dump/restore и типы фс."  +/
Сообщение от BlackHawk (ok) on 29-Июл-09, 13:22 
>[оверквотинг удален]
>/dev/sdb6: UUID="66dc3b1e-2ed9-9cbd-8c66-eaf738f3bc87" TYPE="mdraid"
>/dev/sdb7: UUID="e7ded5da-b4b1-684b-da96-f4eca5790866" TYPE="mdraid"
>/dev/md0: UUID="2e6ee609-a2d9-47e3-9d75-29f133107d59" TYPE="ext3"
>/dev/md2: UUID="7e2cf99c-e0d0-433a-9196-9cbb80d5e9b0" TYPE="ext4"
>/dev/md1: UUID="82bdc1ee-13a7-45a4-805b-64fa4732f8d0" TYPE="ext3"
>
>Это просто blkid врет или всё же где-то что-то сделано не верно
>и в дальнейшем может родить сложности?
>
>Заранее благодарен.

dump сделан тоже из ext4?
есть подозрение, что дамп из ext3...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Использование dump/restore и типы фс."  +/
Сообщение от stakado email(ok) on 29-Июл-09, 13:26 
>[оверквотинг удален]
>>/dev/md2: UUID="7e2cf99c-e0d0-433a-9196-9cbb80d5e9b0" TYPE="ext4"
>>/dev/md1: UUID="82bdc1ee-13a7-45a4-805b-64fa4732f8d0" TYPE="ext3"
>>
>>Это просто blkid врет или всё же где-то что-то сделано не верно
>>и в дальнейшем может родить сложности?
>>
>>Заранее благодарен.
>
>dump сделан тоже из ext4?
>есть подозрение, что дамп из ext3...

Да да, забыл указать, что исходная фс была ехт4.
При этом складывается впечатление, что dump/restore не умеют работать с ext4. Пробовал восстанавливать не всю фс, а лишь файлы - эффект такой же. Попорбовал восстановить бекап другого раздела, на котором ехт3 - всё нормально, никаких косяков.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Использование dump/restore и типы фс."  +/
Сообщение от Брызгалов Константин email(ok) on 24-Дек-11, 14:18 
Ошибка описана здесь

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511651

Как я понял ошибка присуща конкретной версии, очень обидная так как никогда не сталкивался - потерял много времени и нервов


>[оверквотинг удален]
>>>
>>>Заранее благодарен.
>>
>>dump сделан тоже из ext4?
>>есть подозрение, что дамп из ext3...
> Да да, забыл указать, что исходная фс была ехт4.
> При этом складывается впечатление, что dump/restore не умеют работать с ext4. Пробовал
> восстанавливать не всю фс, а лишь файлы - эффект такой же.
> Попорбовал восстановить бекап другого раздела, на котором ехт3 - всё нормально,
> никаких косяков.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Использование dump/restore и типы фс."  +/
Сообщение от stakado email(ok) on 29-Июл-09, 13:33 
>[оверквотинг удален]
>>/dev/md2: UUID="7e2cf99c-e0d0-433a-9196-9cbb80d5e9b0" TYPE="ext4"
>>/dev/md1: UUID="82bdc1ee-13a7-45a4-805b-64fa4732f8d0" TYPE="ext3"
>>
>>Это просто blkid врет или всё же где-то что-то сделано не верно
>>и в дальнейшем может родить сложности?
>>
>>Заранее благодарен.
>
>dump сделан тоже из ext4?
>есть подозрение, что дамп из ext3...

Попробовал переформатить в ехт3, эффект таков же:
[root@zeus /]# mkfs -t ext3 /dev/md2
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
14458880 inodes, 57823920 blocks
2891196 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
1765 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[root@zeus /]# mount /dev/md2 /mnt/
[root@zeus /]# cd /mnt/
[root@zeus mnt]# restore rf /temp/home
home-2009-07-29.dump  home-2009-07-29.list
[root@zeus mnt]# restore rf /temp/home-2009-07-29.dump
Dump tape is compressed.
[root@zeus mnt]# cat stakado/before.txt
wwwwwwwwwwwww[root@zeus mnt]# cat stakado/.bashrc
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww[root@zeus mnt]#

Видимо содержимое самого бекапа корявое. Может всё же dump не умеет работать с ext4 или стоило ему хотя бы руками указать тип фс, с которой он образ делает.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру