В Debian 8.7 у меня был пул zfs. (очевидно, с использованием ZFS в Linux, а не Oracle или Solaris zfs)
Требовалось расширить пул ZFS с зеркала на 2-х дисках до raidz на 4-х дисках. Сделал резервную копию (одна копия данных - это была моя первая ошибка)
я думал что zpool destroy
не будет работать, пока я не удалю все наборы данных (тома), поэтому я сделал zfs destroy
(это была моя вторая ошибка).
После этого я выдал «zpool destroy», переразбил все 4 диска и обнаружил, что резервная копия повреждена.
Итак, я начал свое выздоровление adventure: Первое, что хорошо в ZFS, это то, что она может импортировать уничтоженные пулы. После zpool destroy yourPoolName
вы можете вызвать zpool import -D
чтобы увидеть список уничтоженных пулов. Затем вы можете импортировать его, используя zpool import -D yourPoolName
или если вы уничтожили несколько пулов с одинаковым именем, вы можете импортировать его по идентификатору, который отображается zpool import -D
.
zpool import -D
требует перегородки на прежнем месте. Он должен быть точно до сектора. я использовал fdisk
для создания разделов с точным начальным и конечным номером сектора. я использовал cfdisk
чтобы установить тип раздела (потому что он более удобный :)), а затем вы должны вызвать partprobe
чтобы убедиться, что ОС знает об измененных разделах.
zpool import -D
работал как шарм, и мой бассейн снова был в отличном состоянии! .. Но со всеми последствиями zfs destroy
- все данные отсутствовали.
ZFS сохраняет изменения файлов и файловой системы в транзакциях, которые сохраняются на диск в группах транзакций (TXG). Мои дальнейшие исследования показали, что мне нужно откатить последние группы транзакций.
Есть 2 способа откатить группы транзакций ZFS:
zpool import
с участием -T
вариантzfs_revert-0.1.py
Прежде всего вам нужно найти последний хороший TXG. zpool history -il
помог мне.
Согласно первому способу вы должны вызвать что-то вроде: zpool import -o readonly=on -D -f -T <LAST-GOOD-TXG> poolName
(с дополнительными параметрами, если хотите: -F
, -m
, -R
) К сожалению, эта команда работала только с реальным TXG. Возврат даже к предпоследнему TXG не работал и отображал сообщения об ошибках, такие как «устройство недоступно». Похоже, эта функция работает (или работала) только в Solaris. Жалко.
Я проанализировал код zfs_revert-0.1.py
, это выглядит ясно и многообещающе. Я использовал этот инструмент, но похоже, мне нужно было удалить слишком много TXG. После этого zpool import -D
больше не смог обнаружить пул.
В настоящее время я восстановил одну из старых резервных копий, у меня dd
дампы 2-х дисков, которые были зеркалированы, но после zfs destroy
и zpool destroy
. Похоже, мы просто будем жить с данными из старой резервной копии и остановим дальнейший процесс восстановления. Тем не менее, я буду рад попробовать восстановить данные, если кто-нибудь подскажет, что делать в такой ситуации.
Дальнейшее восстановление будет выполнено на VMWare Workstation, поэтому мне нужно будет найти способ импортировать zpool в виртуальную машину (идентификаторы дисков, вероятно, изменятся)
Вопрос Что я могу попробовать дальше?
Уроки выучены:
zfs destroy
не нужно и очень опасно, если вы собираетесь делать zpool destroy
тем не мение.Комментарии: Очевидно, что при восстановлении следует полностью прекратить запись на диски, на которых хранились поврежденные данные.
Полезные команды: zpool import -D zpool import -o readonly = on -D -f originalPoolName newPoolName zpool status tank
zpool online dozer c2t11d0
zpool scrub tank
zpool history -il
zpool export tank
zpool import dozer zeepool
Ссылки:
инструменты
Информация о поврежденной ZFS
ZFS Импорт