Sim, isso pode ser feito. Vai ser confuso.
Eu tenho uma SAN iSCSI baseada em ZFS que serve ZVOLs para vários servidores da VM. Hoje, uma falha de rede fez com que todos os volumes iSCSI montados nos clientes fossem RO. A única maneira é desligá-los e reiniciá-los, geralmente executando o fsck para colocar os volumes iSCSI novamente on-line. Bem, o fsck decidiu destruir completamente um dos volumes. Então, não parece que eu consiga consertar a bagunça feita pelo fsck.
Eu li bastante sobre a recuperação de arquivos no ZFS, no entanto, neste caso estou lidando com ZVOLs, que de certa forma é muito mais simples, mas eu não vi nada que lesse a tentativa de reverter arquivos. o conteúdo de um dispositivo de bloco. Alguma sugestão?
-TIA -
Alguns detalhes do conjunto de dados:
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
O sistema é o 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
Não há um instantâneo relevante; Eu percebi que foi sem dizer.
A razão pela qual estou fazendo a pergunta, e o que eu estou procurando agora, refere-se a artigos como este de Max Burning , que investiga a recuperação de objetos através de técnicas forenses. É claro que isso não depende de nenhuma falta de conhecimentos internos do ZFS. A maior parte do que eu vi, no entanto, lida com objetos de arquivos que são muito diferentes dos objetos que implementam o armazenamento de blocos brutos e eu não vi quase nada nos internos relacionados aos ZVOLs.
Mesmo que eu não possa "reverter" tecnicamente as mudanças que o fsck fez, seria no mínimo útil voltar atrás e encontrar alguns dos principais blocos originais. Isso deve ser possível, dado o comportamento da VAC da ZFS ... e conhecimento suficiente que me faltam, mas geralmente não deixo que isso me impeça.
Sim, isso pode ser feito. Vai ser confuso.
There isn't a relevant snapshot; I figured that went without saying.
Portanto, sem um snapshot que se correlacione com um horário em que o zpool e os dados estejam íntegros, você não terá nenhum recurso fácil ou capacidade de reverter.
Como Tero Kilkanen disse corretamente nos comentários, você precisa ter um instantâneo do zvol a partir do momento em que ainda é válido, caso contrário, seus dados serão perdidos.
Alguns antecedentes:
As capturas instantâneas podem ser criadas a partir de qualquer conjunto de dados - sistemas de arquivos ou volumes (zvol) e também são um conjunto de dados (somente leitura, dependente). Eles são sempre atômicos, então você obtém o estado em um determinado ponto de tempo para todo o conjunto de dados (embora para seus aplicativos no topo possa parecer uma reinicialização do disco ou sistema no pior caso), e pode ter certeza que sua integridade de dados é preservada (pelo menos para gravações de sincronização, as gravações assíncronas poderiam, é claro, ter sido descartadas parcialmente).
A única diferença entre zvols e sistemas de arquivos a esse respeito é que - como cada snapshot sempre faz referência a todo o conjunto de dados - você pode escolher quais arquivos restaurar de um snapshot do sistema de arquivos (misturá-los com dados atuais ou antigos), mas você só pode escolher usar o zvol inteiro, porque é como um arquivo realmente grande (teoricamente, você poderia copiar intervalos de bytes e mesclá-los, mas isso seria bastante inconveniente). Além dessa "visão" dos dados (arquivos vs. blocos), o comportamento é o mesmo.
Confira a opção zpool import -T. Cuidado: isso é na piscina, não o zvol. Talvez você possa enviar seu zvol para um novo zpool e usar import -T para importá-lo usando um txg diferente.
Tags data-recovery zfs linux