У меня есть iSCSI SAN на основе ZFS, который обслуживает ZVOL для множества серверов виртуальных машин. Сегодня из-за сбоя в сети все тома iSCSI, смонтированные на клиентах, перешли в режим RO. Единственный выход из этого - выключить их все и перезапустить, часто используя fsck, чтобы вернуть тома iSCSI в оперативный режим. Что ж, fsck решил полностью уничтожить один из томов. Так что не похоже, что я смогу исправить беспорядок, созданный fsck.
Я довольно много читал о восстановлении файлов в ZFS, однако в этом случае я имею дело с ZVOL, что в некотором смысле намного проще, но я не видел ничего, связанного с попыткой отката содержимого блочное устройство. Какие-либо предложения?
-TIA-
Некоторые детали набора данных:
Dataset zpool1/vm3 [ZVOL], ID 59, cr_txg 12078, 44.6G, 2 objects, rootbp DVA[0]=<6:6c2c4b1e00:200> DVA[1]=<7:487aa4b200:200> [L0 DMU objset] fletcher4 lz4 LE contiguous unique double size=800L/200P birth=7736596L/7736596P fill=2 cksum=4c78779ec:2049fb2de6c:6f2f6c4a44e9:1042484aee3ded
Deadlist: 1K (512/512 comp)
mintxg 0 -> obj 48
mintxg 1 -> obj 4157
Object lvl iblk dblk dsize lsize %full type
0 7 16K 16K 7.00K 16K 6.25 DMU dnode
dnode flags: USED_BYTES
dnode maxblkid: 0
Object lvl iblk dblk dsize lsize %full type
1 5 16K 8K 44.6G 200G 36.45 zvol object
dnode flags: USED_BYTES
dnode maxblkid: 26214399
Object lvl iblk dblk dsize lsize %full type
2 1 16K 512 0 512 100.00 zvol prop
dnode flags: USED_BYTES
dnode maxblkid: 0
microzap: 512 bytes, 1 entries
size = 214748364800
Система CentOS 7.1
Linux san1srvp01 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Jan 18 13:06:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Нет соответствующего снимка; Я подумал, что это само собой разумеющееся.
Причина, по которой я задаю этот вопрос, и то, что мне нужно, относится к статьям вроде этой из Максимальное горение который углубляется в восстановление объекта с помощью криминалистических методов. Это, конечно, не требует недостатка знаний о внутреннем устройстве ZFS. Тем не менее, большая часть того, что я видел, касается возврата к файловым объектам, которые сильно отличаются от объектов, которые реализуют хранилище сырых блоков, и я почти ничего не видел на внутреннем устройстве, связанном с ZVOL.
Даже если я не могу технически «откатить» изменения, внесенные fsck, было бы полезно вернуться назад и найти некоторые ключевые исходные блоки. Это должно быть возможно, учитывая поведение ZFS COW ... и достаточные знания, которых мне не хватает, но обычно я не позволяю этому останавливать меня.
Нет подходящего снимка; Я подумал, что это само собой разумеющееся.
Таким образом, без моментального снимка, который коррелирует со временем, когда zpool и данные находятся в исправном состоянии, у вас нет простого выхода или возможности отката.
Да, это может быть сделано. Будет грязно.
Как правильно сказал Теро Килканен в комментариях, вам необходимо иметь снимок zvol с того времени, когда он был еще действителен, иначе ваши данные будут потеряны.
Немного предыстории:
Моментальные снимки могут быть созданы из любого набора данных - файловых систем или томов (zvol), и сами они также являются набором данных (доступным только для чтения, зависимым). Они всегда атомарны, поэтому вы получаете состояние в определенный момент времени для всего набора данных (хотя для ваших приложений наверху это может показаться полным сбросом диска или системы в худшем случае), и можете быть уверены, что целостность ваших данных сохраняется (по крайней мере, для синхронной записи, асинхронная запись, конечно, могла быть частично отброшена).
Единственная разница между zvols и файловыми системами в этом отношении заключается в том, что, поскольку каждый снимок всегда ссылается на весь набор данных, вы можете выбрать, какие файлы восстановить из снимка файловой системы (смешать их с текущими или более старыми данными), но вы можете только выберите использование всего zvol, потому что это как действительно большой файл (теоретически вы можете копировать байтовые диапазоны и объединять их самостоятельно, но это было бы довольно неудобно). За исключением этого «представления» о данных (файлы или блоки) поведение такое же.
Проверьте параметр zpool import -T. Осторожно: это на пуле, а не на зволе. Возможно, вы могли бы отправить свой zvol в новый zpool и использовать import -T, чтобы импортировать его, используя другой txg.