можно ли восстановить данные после zfs destroy -r

[HowCast]

Здравствуйте,
случилось то, что случается у всех, кто не делает резервные копии: я удалил датасет (из GUI)

zpool history:
2018-11-17.15:36:01 zfs destroy -r WD2TB_Mirror/dataset_Office

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

-как можно восстановить удаленные данные? и не потерять имеющиеся датасеты!

пул WD2TB_Mirror это RAID1 - два диска WD 2TiB серия YELLOW, есть еще два "таких же" серии GOLD

можно ли (и нужно ли) реплицировать имеющийся пул на эту пару- либо для опытов, либо для сохранности имеющихся данных


в system/boot environment/ - есть "состояние" системы, в котором этот датасет, еще присутствует

Спасибо.

 

[mav@]

Если пул был оперативно экспортирован или сервер вырублен сразу после удаления, то может быть шанс импортировать его по состоянию до удаления, использую один из резервных уберблоков. Если пул был неактивен, то "сразу" может значить пару часов, если активно работал, то может минуту-две. `zdb -ul /dev/...` может показать доступный список уберблоков с временем обновления каждого. Помимо этого полагаю будет сложно.

 

[HowCast]

к сожалению пул в работе третий день, а несчастье приключилось в субботу, но с него только читают, задания на снимки все выключил.
Или это уже не спасет "отца русской демократии"?
как сделать zdb - применительно к пулу из двух девайсов?
на один диск zdb -ul /dev/ada0 - на всех убер блоках сегодняшняя дата ...

Code:

zdb -ul /dev/ada0
------------------------------------
LABEL 0
------------------------------------
failed to unpack label 0
------------------------------------
LABEL 1
------------------------------------
failed to unpack label 1
------------------------------------
LABEL 2
------------------------------------
failed to unpack label 2
Uberblock[64]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978592
	   guid_sum = 17448801606570451042
	   timestamp = 1542619997 UTC = Mon Nov 19 12:33:17 2018
	   checkpoint_txg = 0
Uberblock[68]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978593
	   guid_sum = 17448801606570451042
	   timestamp = 1542620002 UTC = Mon Nov 19 12:33:22 2018
	   checkpoint_txg = 0
Uberblock[72]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978594
	   guid_sum = 17448801606570451042
	   timestamp = 1542620007 UTC = Mon Nov 19 12:33:27 2018
	   checkpoint_txg = 0
Uberblock[76]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978595
	   guid_sum = 17448801606570451042
	   timestamp = 1542620012 UTC = Mon Nov 19 12:33:32 2018
	   checkpoint_txg = 0
Uberblock[80]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978596
	   guid_sum = 17448801606570451042
	   timestamp = 1542620017 UTC = Mon Nov 19 12:33:37 2018
	   checkpoint_txg = 0
Uberblock[84]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978597
	   guid_sum = 17448801606570451042
	   timestamp = 1542620022 UTC = Mon Nov 19 12:33:42 2018
	   checkpoint_txg = 0
Uberblock[88]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978598
	   guid_sum = 17448801606570451042
	   timestamp = 1542620027 UTC = Mon Nov 19 12:33:47 2018
	   checkpoint_txg = 0
Uberblock[92]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978599
	   guid_sum = 17448801606570451042
	   timestamp = 1542620032 UTC = Mon Nov 19 12:33:52 2018
	   checkpoint_txg = 0
Uberblock[96]
	   magic = 0000000000bab10c
	   version = 5000
	   txg = 3978600
	   guid_sum = 17448801606570451042
	   timestamp = 1542620037 UTC = Mon Nov 19 12:33:57 2018
	   checkpoint_txg = 0

там еще данные есть, но наверное, пока нет смысла их все выкладывать

Есть копия удаленных данных, месячной давности на USB харде, т.е. там можно дерево папок и файлов посмотреть,

 

[mav@]

`zdb` надо натравливать на конкретный раздел, а не на весь диск. Посмотри как они отображаются в `zpool status`. Какой именно диск выбирать -- не важно, список должен быть примерно одинаковый. Но учитывая что прошли дни, шансов что хоть один uberblock остался думаю никаких. Как я сказал -- это может сработать минуты или от силы часы. Увы.

 

[HowCast]

Code:

zdb -ul /dev/ada0p2 

все UTC метки показывают только сегодняшние даты.

Т.е. - zfs обновляет эти блоки непрерывно, даже если пользователи не производят запись на диск?
Но ведь эти блоки, по идее, пишутся, в первую очередь, на незанятое пространство пула, а потом уже на место, которое помечено, как "освобожденное" для записи. Или пары-тройки часов достаточно, чтобы уберблоки перезаписались несколько раз?

 

[mav@]

Достаточно одного измененного блока данных на пуле, чтобы ZFS закоммитил группу транзакций спустя максимум пять секунд. Каждая закрытая группа транзакций -- это один перезаписанный uberblock. А если atime не выключен, то каждое чтение файла обновляет его atime, что есть запись.

 

[HowCast]

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

mav@,
Скажите, а какую бы вы предприняли последовательность действий в таком случае, как наш, чтобы давало шансы на успех в восстановлении данных? (Это мне для самообразования, а не как повод не делать резервные копии)

И, чисто, теоретический вопрос (уж простите ламера):
можно ли, и имеет ли смысл сделать экспорт пула на другой носитель, или разъединить этот пул (зеркало) на два идентичных диска, и попытаться в сырых данных поискать известные структуры?

 

[mav@]

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

Для предотвращения такого в первую очередь надо иметь резервные копии данных, так как от всех административных ошибок защититься невозможно. Во вторую очередь, как я сказал в самом начале, как только проблема произошла надо было сразу вывести пул из работы или как минимум выдернуть один из двух дисков чтобы созранить его наиболее целостным. Если бы последнее было сделано быстро -- принцип восстановления я описал. В третьих, для выполнения особо рискованных операций в 11.2 в ZFS добавлена новая функциональность `zpool checkpoint`, которая позволяет создать (правда только один) снапшот для всего пула, и откат до него полностью возвратит пул к состоянию на момент его создания. Но все-таки бакапы, бакапы и еще раз бакапы.

 

[HowCast]

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

 

[mav@]

- а что дает откат к начальному состоянию пула? ведь он пустой

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

 

[HowCast]

mav@, спасибо вам.
Пожалуй, тему можно считать исчерпанной- а то она грозит перерасти в ликбез.