Canal de fibra: fita LTO sobrescrita na reinicialização do barramento

4

Existe uma situação que tivemos no cliente que eu gostaria de entender melhor.

Veja o que aconteceu:

  • Uma biblioteca com unidades de fita LTO é conectada a um ambiente de canal de fibra
  • O arquivamento de software em execução no Windows Server 2008 está gravando dados nas fitas
  • Em algum momento, a fita foi rebobinada sem que o software soubesse disso e a gravação apagou a fita
  • A situação foi detectada comparando a posição esperada na fita com a real

Eu não tenho detalhes sobre os fornecedores de equipamentos.

Parece que ocorreu uma reinicialização na unidade de fita que causou o retrocesso da fita, mas essa situação não foi reportada como um erro de volta ao driver e ao software, portanto, o software supôs que a gravação foi bem-sucedida.

Eu estava lendo muita documentação para entender por que isso aconteceu, mas não posso tirar conclusões definitivas para ajudar o cliente.

  • Um FC HBA ou um autotransmissor pode retransmitir a gravação SCSI na reinicialização do barramento?
    • Pode algo assim ser configurável?
  • O FC HBA ou o switch ignoraram a unidade relatada?
  • O driver do sistema operacional pode ser o culpado?
  • Este fornecedor é específico?

Eu ficaria muito grato se alguém puder me fornecer algumas instruções para continuar.

    
por matejk 08.04.2016 / 16:12

1 resposta

3

Este é um problema conhecido com unidades de fita e o modo como elas são trivialmente fáceis de retroceder apenas olhando de lado para o dispositivo (isto é, abrindo-o de forma errada - através do dispositivo de rebobinagem - apenas para verificar o status ).

Pelo menos uma parte importante do software de backup UNIX está tão preocupada com isso que simplesmente se recusa a gravar uma fita uma segunda vez até que a fita esteja pronta para ser apagada; isso de o FAQ da amanda (que menciona especificamente redefinições de barramento como uma área problemática):

Why does Amanda not append to a tape?

One run of Amanda = one (set of) tapes. Amanda opens the tape device once, writes all the images and filemarks, and closes the device once. Using that sequence, there is no possibility that other programs interrupt the sequence and rewind the tape, without Amanda noticing.

Doing "mt -f /dev/st0 status" could be enough, or even "amcheck daily". Also, an error like a scsi bus reset implies a rewind.

If Amanda would close and reopen the tape drive for each backup image, there is a window of vulnerability that the tape gets rewound accidentally, and the next image will overwrite all the good backups on the tape. And you wouldn't know unless you tried to restore from the tape.

When appending to a tape, there is the possibility that, between the time that Amanda positions to the last image (that already is not really trivial!), and opening the device for writing, a tape rewind happens, and in that case Amanda would happily erase ALL of the tape, containing possibly many days worth of backup.

Bacula aborda o problema de maneira similar, nunca fechando o dispositivo de fita, para que ninguém mais possa abri-lo incorretamente enquanto uma fita é carregada. Mas isso não resolve o problema do reset do ônibus.

Essencialmente, este é um problema, e é difícil. Eu poderia argumentar que o seu hardware de backup deve ser sólido o suficiente para que isso não aconteça com frequência; Se o FC parecer particularmente propenso a isso, é hora de obter uma unidade de fita SAS, ou pelo menos conectar diretamente o dispositivo de fita ao servidor de backup para remover os comutadores de fibra, etc. do caminho. Além disso, não consigo ver como você pode fazer muito mais do que você, já que pegou o problema antes do ponto comum, ou seja, "nossas restaurações não funcionam, estamos ferradas" .

    
por 12.04.2016 / 10:43