LINUX.ORG.RU

FreeBSD/zfs: исчезновение данных на 600+ GB

 ,


0

2

Как создавал xfs и устанавливал на нее систему:
делал все по этому мануалу.
Ставил все на один диск. затем, скопировал все свои документы (фотки 10летней давности, ролики, доки по работе) с временного диска на FreeBSD по самбе. Когда скопировал, диск обнулил дискдайпом и обратно вернул своему другу.
Достал второй диск и решил сделать зеркало. Для надежности.
ada1 - второй диск.
zpool labelclear /dev/ada1 (на всякий случай)
gpart create -s gpt ada1
gpart add -b 34 -s 94 -t freebsd-boot ada1
gpart add -t freebsd-zfs -l wd_old ada1
zpool attach zroot /dev/gpt/wd_7tys_ryb /dev/gpt/wd_old
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
ресильверинг прошел успешно.

Понадобилось выключить компьютер. вынуть видеокарту и оставить встроенную.
Когда включил, то не понял. по самбе никуда не могу попасть. полез в шелл - а в корневом каталоге документов полная пустота. документы лежали в /home/iron/1
сам домашний раздел похудел на ~620GB - это все, что было накоплено еще под Slackware с 2002 года. Filesystem Size Used Avail Capacity Mounted on
zroot 2.7T 380M 2.7T 0% /
devfs 1.0k 1.0k 0B 100% /dev
zroot/tmp 2.7T 176k 2.7T 0% /tmp
zroot/usr 2.7T 2.6G 2.7T 0% /usr
zroot/usr/home 2.7T 280M 2.7T 0% /usr/home
zroot/usr/ports 2.7T 1.4G 2.7T 0% /usr/ports
zroot/usr/ports/distfiles 2.7T 787M 2.7T 0% /usr/ports/distfiles
zroot/usr/ports/packages 2.7T 144k 2.7T 0% /usr/ports/packages
zroot/usr/src 2.7T 509M 2.7T 0% /usr/src
zroot/var 2.7T 1M 2.7T 0% /var
zroot/var/crash 2.7T 148k 2.7T 0% /var/crash
zroot/var/db 2.7T 157M 2.7T 0% /var/db
zroot/var/db/pkg 2.7T 14M 2.7T 0% /var/db/pkg
zroot/var/empty 2.7T 144k 2.7T 0% /var/empty
zroot/var/log 2.7T 296k 2.7T 0% /var/log
zroot/var/mail 2.7T 148k 2.7T 0% /var/mail
zroot/var/run 2.7T 380k 2.7T 0% /var/run
zroot/var/tmp 2.7T 152k 2.7T 0% /var/tmp

iron:[~]$zpool status -v
pool: zroot
state: ONLINE
scan: resilvered 665G in 1h47m with 0 errors on Sat Aug 31
10:31:13 2013
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
gpt/wd_7tys_ryb ONLINE 0 0 0
gpt/wd_old ONLINE 0 0 0

errors: No known data errors

Люди. Это же неубиваемая файловая система. лет 15 жил под другими фс, но что я сделал не так?
Есть ли возможность как-то все вернуть?



Последнее исправление: cetjs2 (всего исправлений: 1)

Есть ли возможность как-то все вернуть?

Конечно, восстановить из бэкапа

Harald ★★★★★
()

При создании зеркала ты снес файлуху и сделал новую. Тоже самое, что отформатировать разделы.

ССЗБ.
Как починить - не знаю, на 90% фатально.

tazhate ★★★★★
()
Ответ на: комментарий от tazhate

Ну, так везде так советуют. Прошел ресильверинг (около 1.5 часа) - данные все оставались на месте. читал их спокойно.

Karharot
() автор топика
Ответ на: комментарий от Karharot

Как же тогда уцелели все остальные датасеты. usr, как было 2.6, так и осталось. Система грузится без ругани.

Karharot
() автор топика

Как вернуть, к сожалению, я подсказать не могу, но могу посоветовать впредь не пользоваться такими хитрожопыми методами повышения «надёжности». Вот, честное слово, придётся признать, что хранить все свои наработки за 10 лет на разделе с NTFS в данном случае намного надёжнее, именно потому что она не умеет хитрых операций, которыми можно выстрелить себе в ногу. И восстановлялок для неё в интернете как мусора.

Alve ★★★★★
()
Ответ на: комментарий от Alve

ntfs подразумевает windows, а это уже вирусня и все прочее. Просто, я ни одного плохого слова не слышал ни от кого. про zfs.
Полно руководств по таким операциям. Блогов. Как пример: http://freebsdhosting.ru/zamena-diska-v-zfs-gpt-odin-disk-v-pule/

им и руководствовался. А как еще. Читать всю документацию по матчасти. Пока прочитаешь до середины, забудешь с чего начинал читать и куда, вообще, смотреть. (не теория, а практика).

Новедь! надежной! считается. всеми!
значит, сложно ошибиться?
Что прочитал, так и поступил.
блин.

Karharot
() автор топика
Ответ на: комментарий от Karharot

Новедь! надежной! считается. всеми!
значит, сложно ошибиться?

Неа. Надёжной - значит драйвер файловой системы и утилит обслуживания вылизан до состояния «ошибок нету или так мало, что они неспособны развалить ФС». Это мало относится к шансу ошибиться в ИСПОЛЬЗОВАНИИ этих утилит или функций драйвера. Так что, сочувствую, сам бывало терял инфу.

Alve ★★★★★
()
Ответ на: комментарий от Alve

2 Alve

Мне ее никогда, видимо, не изучить. реально.

завидую белой завистью тем, у кого мозг способен это освоить.

Ее изучить - это надо брать отпуск. где-то на месяц. брать все rfc по ней и не только и уезжать читать все это. зубрить. в тихой обстановке.
в слепую «слушать» блоги, или советы на форумах по ней - ссзб. С год назад уже терял все на ней. Тогда, вообще ничего не делал. С год проработала и вдруг процентов 70 данных исчезло. зеркало из двух дисков. Хорошо, все мегаценное сохранил.
Вернулся на нее, ибо считается надежной.
Ну, ясно. Блоги не читать, как и форумы. искать rfc и сидеть переводить и с год гонять в виртуалке, постоянно экспериментируя.

Karharot
() автор топика
Ответ на: комментарий от unC0Rr

метка диска wd_old - это новый, присоединяемый диск, если что. он был очищен и выставлен в команде последним.

теперь я не знаю, как вообще работать и чему верить.

Karharot
() автор топика
Ответ на: комментарий от Karharot

Ее изучить - это надо брать отпуск. где-то на месяц. брать все rfc по ней и не только и уезжать читать все это. зубрить. в тихой обстановке.

А ты уверен, что это настолько необходимо? Имхо, не настолько это распространённая и фундаментальная штука...

Alve ★★★★★
()
Ответ на: комментарий от Karharot

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

zfs list -r zroot

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)

отключи диск, попробуй востановить данные при помощи какой нибудь recovery-утилиты.

splinter ★★★★★
()
Ответ на: комментарий от iZEN

Сначала дать команду «zfs list» — можно посмотреть, все ли ФС смонтировались в свои точки. Если не все, то можно вручную по дной смонтировать: «zfs set mountpoint=/tmp zroot/tmp» и т.д.

Вообще же, не исключена ситуация, когда корневая файловая система пула монтируется «не туда» или вообще не имеет точки монтирования «none», хотя должна быть смонтирована в корень «/». Так бывает, если что-то напутали со свойствами пула или не задали корневую точку монтирования.

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от Karharot

Просто, я ни одного плохого слова не слышал ни от кого. про zfs.

Это объясняется очень просто.

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

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

Что характерно, эти два множества сильно пересекаются.

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

Если хотите надёжность хранения данных, то лучше избыточности ещё ничего не придумали. Контрольные суммы не спасут ваши данные, они только укажут на их повреждение, когда будет уже поздно пить боржоми. Так что стройте raid и не выделывайтесь. А в качестве ФС используйте ufs2+su.

anonymous
()
Ответ на: комментарий от iZEN

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

не пул целиком, а отдельный датасет?
это как?

Karharot
() автор топика
Ответ на: комментарий от Karharot

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

iZEN ★★★★★
()
Ответ на: комментарий от anonymous

На деле же ZFS - это жирный монстр, нарушающий все принципы разделения уровней

Как пользователь этой ФС с многолетним стажем скажу, что вы не правы. XFS гораздо монструознее и подыхает от дёрганья рубильника.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

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

Karharot
() автор топика
Ответ на: комментарий от iZEN

XFS гораздо монструознее и подыхает от дёрганья рубильника.

Вот не надо грязи. Относительно давно, с ubuntu-server 8.04 используем XFS на серверах, данные по причине разрушения ФС не теряли ни разу. Кстати, в каком месте код xfs «монструознее» zfs?

King_Carlo ★★★★★
()
Ответ на: комментарий от anonymous
zfs list
NAME                        USED  AVAIL  REFER  MOUNTPOINT
zroot                      10,2G  2,67T   380M  /
zroot/swap                 4,13G  2,67T    72K  -
zroot/tmp                   176K  2,67T   176K  /tmp
zroot/usr                  5,56G  2,67T  2,58G  /usr
zroot/usr/home              281M  2,67T   281M  /usr/home
zroot/usr/ports            2,21G  2,67T  1,44G  /usr/ports
zroot/usr/ports/distfiles   788M  2,67T   788M  /usr/ports/distfiles
zroot/usr/ports/packages    144K  2,67T   144K  /usr/ports/packages
zroot/usr/src               509M  2,67T   509M  /usr/src
zroot/var                   174M  2,67T  1020K  /var
zroot/var/crash             148K  2,67T   148K  /var/crash
zroot/var/db                171M  2,67T   157M  /var/db
zroot/var/db/pkg           14,6M  2,67T  14,6M  /var/db/pkg
zroot/var/empty             144K  2,67T   144K  /var/empty
zroot/var/log               300K  2,67T   300K  /var/log
zroot/var/mail              148K  2,67T   148K  /var/mail
zroot/var/run               372K  2,67T   372K  /var/run
zroot/var/tmp               152K  2,67T   152K  /var/tmp

все смонтировано, но от этого не легче. use 281M.

Karharot
() автор топика
Ответ на: комментарий от King_Carlo

Кстати, в каком месте код xfs «монструознее» zfs?

Код XFS имеет такой же объём, что и код ZFS. Только непонятно почему XFS намного менее функциональна.

iZEN ★★★★★
()
Ответ на: комментарий от Karharot

use 281M.

Не показатель. Сжатие на ФС включали? Ещё учтите, что ZFS оперирует по умолчанию блоками до 128k.

iZEN ★★★★★
()
Ответ на: комментарий от Karharot

И ни одной ошибки при загрузке. все подгружается. работает.

был .profile в /usr/home/iron/. менял его раньше. все так и осталось. то есть, это не новый профайл. да и все остальные конфиг файлы живы. убилась именно директория с документами. все внутри попросту исчезло. как не было. и произошло это именно после перезагрузки. за считанные секунды, до перезагрузки, открывал еще текстовик в textmate с os x, по смб. тут не ошибаюсь.
самба смтрела лишь на яблокомпьютер. с внешней стороны к ней доступ закрыт роутером. никаких пробросов на нее извне.

один в один была история с год назад. тогда исчезло правда не все, а процентов 70. по крохам восстанавливал. и самое интересное, все один в один и в снимках, которым месяц идалее! то же пусто.

Karharot
() автор топика
Ответ на: комментарий от iZEN

если 760 GB сжались в 200 MB, то я ее буду всю жизнь изучать, что бы использовать.
Только вот, как выдернуть оттуда файлы.
смонтировать датасет еще раз, если он уже смонтирован.

Karharot
() автор топика
Ответ на: комментарий от iZEN

создание пула было таковым:

zfs create zroot/usr/home
без доп. опций.

«zpool scrub zroot» запустите, может что интересного напишет.
попробую.

Karharot
() автор топика
Ответ на: комментарий от Karharot

если 760 GB сжались в 200 MB, то я ее буду всю жизнь изучать, что бы использовать.

Нет, конечно. Скорее всего имело место быть человеческая ошибка: вы копировали данные на ada1 (который может был под другим именем), а потом очистили его и включили в пул.

iZEN ★★★★★
()
Ответ на: комментарий от Karharot

создание пула было таковым:

zfs create zroot/usr/home

Так создаются датасеты (файловые системы в пуле), а не пул.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

вы копировали данные на ada1 (который может был под другим именем), а потом очистили его и включили в пул.

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

Karharot
() автор топика
Ответ на: комментарий от Karharot

В пути /home/iron/1 был смонтирован какой-нибудь датасет ZFS? Датасет может иметь другое имя, не обязательно совпадающее с именем в файловой системе.

iZEN ★★★★★
()
Ответ на: комментарий от Karharot
zpool scrub zroot
zpool status -v
  pool: zroot
 state: ONLINE
  scan: scrub in progress since Sat Aug 31 18:45:45 2013
        1,87G scanned out of 6,11G at 35,4M/s, 0h2m to go
        0 repaired, 30,55% done
config:

	NAME                 STATE     READ WRITE CKSUM
	zroot                ONLINE       0     0     0
	  mirror-0           ONLINE       0     0     0
	    gpt/wd_7tys_ryb  ONLINE       0     0     0
	    gpt/wd_old       ONLINE       0     0     0

errors: No known data errors
zpool status -v
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0 in 0h3m with 0 errors on Sat Aug 31 18:49:22 2013
config:

	NAME                 STATE     READ WRITE CKSUM
	zroot                ONLINE       0     0     0
	  mirror-0           ONLINE       0     0     0
	    gpt/wd_7tys_ryb  ONLINE       0     0     0
	    gpt/wd_old       ONLINE       0     0     0

errors: No known data errors
zfs list
NAME                        USED  AVAIL  REFER  MOUNTPOINT
zroot                      10,2G  2,67T   380M  /
zroot/swap                 4,13G  2,67T    72K  -
zroot/tmp                   176K  2,67T   176K  /tmp
zroot/usr                  5,56G  2,67T  2,58G  /usr
zroot/usr/home              281M  2,67T   281M  /usr/home
zroot/usr/ports            2,21G  2,67T  1,44G  /usr/ports
zroot/usr/ports/distfiles   788M  2,67T   788M  /usr/ports/distfiles
zroot/usr/ports/packages    144K  2,67T   144K  /usr/ports/packages
zroot/usr/src               509M  2,67T   509M  /usr/src
zroot/var                   174M  2,67T  1020K  /var
zroot/var/crash             148K  2,67T   148K  /var/crash
zroot/var/db                171M  2,67T   157M  /var/db
zroot/var/db/pkg           14,6M  2,67T  14,6M  /var/db/pkg
zroot/var/empty             144K  2,67T   144K  /var/empty
zroot/var/log               300K  2,67T   300K  /var/log
zroot/var/mail              148K  2,67T   148K  /var/mail
zroot/var/run               372K  2,67T   372K  /var/run
zroot/var/tmp               152K  2,67T   152K  /var/tmp

как понять, что оно восстановило. я визуально этого не заметил.

Karharot
() автор топика
Ответ на: комментарий от iZEN

В пути /home/iron/1 был смонтирован какой-нибудь датасет ZFS? Датасет может иметь другое имя, не обязательно совпадающее с именем в файловой системе.

нет. крайняя точка /usr/home. глубже ничего не создавал. производилось все вот так:

zfs create zroot/usr
zfs create zroot/usr/home
zfs create zroot/var
zfs create -o compression=on -o exec=on -o setuid=off zroot/tmp
zfs create -o compression=lzjb -o setuid=off zroot/usr/ports
zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/distfiles
zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/packages
zfs create -o compression=lzjb -o exec=off -o setuid=off zroot/usr/src
zfs create -o compression=lzjb -o exec=off -o setuid=off zroot/var/crash
zfs create -o exec=off -o setuid=off zroot/var/db
zfs create -o compression=lzjb -o exec=on -o setuid=off zroot/var/db/pkg
zfs create -o exec=off -o setuid=off zroot/var/empty
zfs create -o compression=lzjb -o exec=off -o setuid=off zroot/var/log
zfs create -o compression=gzip -o exec=off -o setuid=off zroot/var/mail
zfs create -o exec=off -o setuid=off zroot/var/run
zfs create -o compression=lzjb -o exec=on -o setuid=off zroot/var/tmp

Karharot
() автор топика
Ответ на: комментарий от Karharot

7. Создаём симлинк на папку /home и выставляем права
chmod 1777 /mnt/tmp
chmod 1777 /mnt/var/tmp
cd /mnt ; ln -s usr/home home

Не уловил смысл последней команды.

iZEN ★★★★★
()
Ответ на: комментарий от Karharot

как понять, что оно восстановило. я визуально этого не заметил.

Перезагрузиться на всякий случай.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

reboot

zfs list
NAME                        USED  AVAIL  REFER  MOUNTPOINT
zroot                      10,2G  2,67T   380M  /
zroot/swap                 4,13G  2,67T    72K  -
zroot/tmp                   176K  2,67T   176K  /tmp
zroot/usr                  5,56G  2,67T  2,58G  /usr
zroot/usr/home              281M  2,67T   281M  /usr/home
zroot/usr/ports            2,21G  2,67T  1,44G  /usr/ports
zroot/usr/ports/distfiles   788M  2,67T   788M  /usr/ports/distfiles
zroot/usr/ports/packages    144K  2,67T   144K  /usr/ports/packages
zroot/usr/src               509M  2,67T   509M  /usr/src
zroot/var                   174M  2,67T  1020K  /var
zroot/var/crash             148K  2,67T   148K  /var/crash
zroot/var/db                171M  2,67T   157M  /var/db
zroot/var/db/pkg           14,6M  2,67T  14,6M  /var/db/pkg
zroot/var/empty             144K  2,67T   144K  /var/empty
zroot/var/log               308K  2,67T   308K  /var/log
zroot/var/mail              148K  2,67T   148K  /var/mail
zroot/var/run               380K  2,67T   380K  /var/run
zroot/var/tmp               152K  2,67T   152K  /var/tmp

показываю все. мало ли.

Karharot
() автор топика
Ответ на: комментарий от Karharot

На пуле zroot ваших данных (~760 GB) точно нет. Ищите, где ошибка.

Делать «zpool labelclear /dev/ada1 (на всякий случай)» — это надо на 200% быть уверенным, что на диске ничего нет.

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от iZEN

В этих ваших бздях баш хистори есть? Может ему его выложить как он завафлил фсю ситему.
Сорри если не в ту сторону подсказал.

anonymous
()
Ответ на: комментарий от iZEN

Делать «zpool labelclear /dev/ada1 (на всякий случай)» — это надо на 200% быть уверенным, что на диске ничего нет.

до этого шел проход dd if=/dev/zero of=/dev/ada1. на минут 10 включил.

знать бы заранее, что ничего там не должно было быть, вообще...

Karharot
() автор топика
Ответ на: комментарий от anonymous

А что толку? Хомяк, скорее всего, был в это время на диске, на который копировались данные. А когда по диску прошлись dd, то осталось только то, что было в памяти, а после перезагрузки подцепился устаревший (ранее затеняемый) хомяк, с устаревшей историей.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

На пуле zroot ваших данных (~760 GB) точно нет. Ищите, где ошибка.

уже все передумал, что мог. для меня это вообще нло, что такое могло произойти. Логики до сих пор никакой не пойму.
честно. с 2001го года, еще с Mandrake 8.1, с ext2. Потом, red Hat 7.2, с ext3 итд. Ни разу не терял ничего. До этого в 97м году терял данные на fat16, под win95.
была еще проблема с одним макстором. муха цц. тогда шнурками прошивку восстановил и файлы.
Под фрей - два раза подряд. Первый раз, на аптайме в месяц, спустя пол года после самой установки. Захожу с яфона гудридером, а доков нет. Подхожу с машинке, а файликов нет. обрывки. скраббинг ничего тогда не дал. в снимках та же песня, чему я вообще удивился. Забив на все песни про надежность, тиху убежал обратно на слакварь. И захотелось снова попробовать. скинул все на яблоось, на внешний хард и по самбе вернул. сначала один диск, а потом долго пытался найти способ, как второй диск под фрей сделать не зеркалом, а просто бэкап диском под zfs. подергавшись с неделю и не найдя ничего, решил сделать зеркало снова, погрешив на случай (про прошлый раз). А не тут то было. Данные не прожили и суток.

Karharot
() автор топика
Ответ на: комментарий от Karharot

Это-то понятно, что до.

Ошибка могла быть в точке монтирования или в симлинке на домашнюю директорию в момент копирования.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Ошибка могла быть в точке монтирования или в симлинке на домашнюю директорию в момент копирования.

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

Karharot
() автор топика
Ответ на: комментарий от Karharot

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

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от iZEN

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

namezys ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.