Em Falamos sobre os novos recursos na atualização de janeiro Update 4 para Veeam Backup & Replication 9.5 (VBR), onde deliberadamente não mencionamos os backups em fitas magnéticas. Um relato sobre essa área merece um artigo separado, pois realmente houve muitos novos recursos.
– Pessoal do QA, vocês vão escrever um artigo?
– Por que não!
Armazenamento em fita no século XXI
O armazenamento de dados em fitas magnéticas (cartuchos, "fitas", como nós as chamamos na R&D) não se limita ao computador ZX-Spectrum do passado, cujo jogo poderia carregar na memória RAM de 48 kb a partir de em alguns minutos. Em um quarto de século, a velocidade e a capacidade das fitas aumentaram em 6-7 ordens de magnitude. Esta não é uma comparação totalmente precisa, e pela especificação não está acompanhando. No entanto, as tecnologias modernas permitem gravar até 12 terabytes de dados em uma fita de quilômetro de comprimento (até 30 terabytes em modo de compressão), assim, um dispositivo de 160 dólares supera os concorrentes em termos de custo para armazenamento de longo prazo de grandes volumes de dados, mesmo considerando os investimentos em equipamentos para gravação/leitura. Os dados em tais fitas são armazenados com segurança por 15-30 anos.
Vou abordar de outra forma. Recentemente, alcançaram um novo nível. Eles podem esperar sua oportunidade na infraestrutura de uma grande empresa por semanas e meses, e com o surgimento de mais uma vulnerabilidade de dia zero – destruir (não sem a ajuda humana, já que grandes quantias estão em jogo) não apenas todos os dados, mas também todos os backups, até os que conseguem acessar. Aqui está , quando a empresa teve que pagar aos sequestradores. Os chamados air gaps, ou seja, backups fisicamente isolados da infraestrutura tornaram-se, na prática, o único salvaguarda confiável contra tais situações. A fita magnética aqui é uma das soluções que não se tornaram obsoletas.
Mas apenas uma especificação e inovações tecnológicas em hardware de ímãs e bário-ferrite dos principais fabricantes (IBM, HPE, Oracle, Dell) não são suficientes para uma proteção confiável de dados; é necessário um bom software. Na Veeam, temos uma equipe inteira dedicada a backups em fita, cerca de 10 pessoas analisam, planejam, pesquisam, desenvolvem e testam diariamente. Você pode ter visto os resultados desse trabalho em artigos anteriores (, ). O que foi feito no último ano?
Glossário
Surge a escolha entre as liberdades em relação à língua nativa e os jargões que dificultam a leitura. Prefiro a primeira opção, portanto, peço desculpas antecipadamente se algumas gírias da lista abaixo incomodarem alguém. Aqui, relembrando brevemente, está o que significa cada termo.
Os especialistas em VBR podem ignorar esta parte.Job – tarefa – um trabalho de backup. Na verdade, todo o VBR é construído em torno de jobs. Além de backup e replicação, isso pode incluir a cópia em fita magnética (backup to tape job). Devo esclarecer que a restauração de um backup também é um job, mas neste artigo a palavra se referirá especificamente ao backup.
Storage – uma denominação historicamente estabelecida. Esses são arquivos em repositório (repository – repositório), que contêm backups – operações totalmente e incrementais. Em um storage, pode haver uma ou várias máquinas virtuais.
Chain – uma sequência de storages interconectados. Para restaurar dados de um determinado storage incremental, são necessários todos os anteriores, desde o (n-1) até o primeiro, além do storage completo ao qual o primeiro storage incremental se refere.
Source, Target – fonte, destino. Source é a entidade original que é processada pelo job. No caso de backups/replicações, geralmente é uma máquina virtual no hipervisor. No caso de jobs de fita, a source é o próprio job de backup (ou arquivos no caso de file to tape job). O target para um job de backup é o repositório onde os backups são armazenados. Para jobs de fita, é o media pool.
Media pool – – um pool de mídia, no nosso caso, de fitas. Um contêiner lógico, criado pelo usuário, que contém fitas de uma ou mais bibliotecas. Portanto, um job de fita sempre possui um media pool como target, ou seja, os dados não são escritos em uma fita específica nem em qualquer fita na biblioteca, mas em um conjunto definido delas. O media pool tem uma configuração de tempo de retenção de dados, após o qual a fita pode ser regravada. O usuário pode criar pools padrão (standard) e . Cada um desses tipos pode agora ser WORM ou não-WORM, como será discutido a seguir.
Media set – – um conjunto de fitas em um pool de mídia, nas quais backups/files são continuamente gravados. Para pools GFS, os grupos de mídia também estão vinculados a um intervalo (por exemplo, anual – yearly), as fitas são rotacionadas apenas dentro de seu intervalo.
– elementos da biblioteca de fitas. O drive lê e rebobina a fita, o changer – é um robô que move as fitas entre slots de armazenamento, slots de descarregamento e o drive. Existem também drives standalone (standalone – autônomo), onde um humano desempenha o papel de changer. Para o drive, é imprescindível que o driver do fabricante esteja corretamente instalado na máquina Windows à qual a biblioteca está conectada; com o changer, podemos operar sem drivers, usando SCSI nativo.
Tenant to tape. O provedor está protegido – os clientes estão protegidos.
Colocando as cartas na mesa. O maior recurso da nossa atualização, destinado a , que usam VBR em sua infraestrutura. O desenvolvimento começou há dois anos. Logo percebemos que não conseguiríamos cumprir essa tarefa séria até o próximo lançamento, fizemos uma pequena pausa e, por fim, lançamos o recurso na atualização 9.5 Update 4.
Resumo: Agora, os provedores têm a capacidade de copiar os backups de seus clientes para fitas usando jobs de tape em um pool GFS. Isso oferece aos provedores – que são grandes e muito queridos por nosso coração e departamento comercial – duas oportunidades:
- proteger seus clientes (tenants, tenant – locatário) da perda de dados devido a exclusões acidentais ou problemas de infraestrutura ( "inundação no servidor" );
- oferecer aos tenants um serviço adicional de recuperação de dados de um backup antigo que já foi excluído do repositório em nuvem de acordo com a política de retenção de dados, mas que ainda permanece nas fitas.
Do ponto de vista de marketing, a funcionalidade é muito "apetitoso", mas do nosso lado, é igualmente complexa de implementar.
Desenvolvimento
O principal problema surgido – a criptografia de dados. A maioria dos backups em nuvem é criptografada, as estatísticas indicam ⅔ do total. Para nós, esse número foi uma surpresa, supúnhamos que quase tudo fosse criptografado, mas não – muitos clientes parecem ter total confiança em seus provedores.
A paradigma é simples: o provedor não deve ser capaz de decifrar os dados de seus inquilinos. No entanto, na nova funcionalidade, é necessário que o provedor abra os storage com backups. Isso é necessário para transferir blocos de dados, por exemplo, para criar . O principal é que isso deve ser feito independentemente do inquilino, quando as chaves necessárias não são transmitidas para o provedor durante a execução do trabalho.
A solução para esse problema, que, aliás, também está envolvida em outra funcionalidade crucial da atualização proposta – – consiste na adição de uma chave de criptografia adicional. A chave de arquivo (Archive key) é armazenada no banco de dados do provedor de forma cifrada. Por meio de um esquema engenhoso, o provedor pode abrir o storage e mover e recriptografar blocos de dados entre storages (já que cada um tem sua própria chave), mas não pode decifrar os próprios dados.
Um esquema engenhoso (opção funcional)
Adiciono que todos os engenheiros em R&D realmente amam a criptografia em nosso produto, embora ninguém saiba todos os detalhes de como funciona. (Aqui havia ainda uma piada "e por que funciona de fato", mas os editores não a permitiram.)
Testes
Centenas de bugs foram registrados para a funcionalidade. As áreas mais complexas são a criptografia, a interface do usuário e os problemas durante a restauração.
Do ponto de vista de testes, a dificuldade estava na grande variabilidade, a "combinatória" de tipos e formas de trabalhos de inquilinos e repositórios – me refiro tanto à origem quanto ao destino durante a restauração de backups na infraestrutura. Tudo isso se conecta à lógica dentro da (incluindo a nova – paralelismo e conjuntos de mídia diários, sobre isso abaixo), e no geral à especifidade não familiar para trabalhos em nuvem. Não se esqueça de temperar generosamente com criptografia. Se continuarmos a metáfora, nós nos empanturramos desse prato – mas também o experimentamos de todos os lados.
Fragmento do plano de teste
Como resultado
Uma descrição detalhada pode ser encontrada em (por enquanto em inglês): , . Vou me concentrar nos principais pontos.
Backup
O provedor adiciona inquilinos ao trabalho do tipo tape com o pool GFS como destino. Na presença de uma licença em nuvem, na segunda etapa do assistente, a opção está disponível TenantsÉ possível adicionar todos os inquilinos de uma só vez ou separadamente, ou selecionar apenas uma cota específica (mas não uma subcota) de um determinado inquilino. Não é permitido misturar backups de inquilinos com backups locais comuns em um único trabalho.
As outras configurações são quase idênticas a um trabalho normal no pool GFS.
A restauração de dados pode ser feita tanto do lado do provedor quanto do próprio inquilino.
Restauração do lado do provedor
É realizada através de um novo assistente. Aqui é possível descer até um trabalho específico, restaurando toda a cadeia que estava no repositório em um determinado dia.
Existem três opções de restauração:
- Para a localização original. Nesse caso, o backup original, se existir, é deletado; os trabalhos do inquilino são automaticamente reconfigurados para restaurar a cadeia recuperada. Presume-se que essa restauração será totalmente imperceptível para o cliente, que ficará desconectado do repositório em nuvem apenas por um curto período.
- Para uma nova cota/repositório. O provedor pode, por exemplo, criar uma conta temporária separada para esse fim, que será posteriormente excluída. O backup aparece na infraestrutura do inquilino após a sincronização com o banco de dados do provedor.
- Simplesmente para um disco de servidor Linux ou Windows registrado na infraestrutura do provedor. Depois, essa cadeia pode ser gravada em um pen drive e enviada ao inquilino.
Restauração do lado do inquilino
Esta opção pressupõe que o cliente tenha sua própria infraestrutura de fita e um grande volume de dados para restauração. O provedor pode fisicamente enviar a fita com os backups gravados ao cliente por meio de um serviço de entrega, que a catalogará em seu equipamento, descriptografará as fitas e os backups, e trabalhará com as cópias de segurança como se as tivesse gravado na fita. Essa é uma dica para não precisar baixar terabytes pela WAN.
Melhorias substanciais no pool GFS
-media pools apareceram no VBR há dois anos, na versão 9.5. Na atualização lançada, tanto pela introdução da funcionalidade Tenant to tape, quanto a pedido dos usuários, aprimoramos bastante essa funcionalidade.
Conjuntos de mídia diários
Foi introduzido um novo diário (diário) conjunto de mídia. Agora no pool GFS é possível armazenar backups diários, não apenas completos, mas também incrementais. Estes últimos ocupam consideravelmente menos espaço, e isso foi feito para economizar fita. Presume-se que estas fitas sejam rotacionadas continuamente na biblioteca, sem serem levadas para armazenamento remoto. Para a restauração a partir de um ponto incremental, serão necessárias fitas de um dos conjuntos de mídia mais antigos (semanal, mensal, trimestral ou anual). Não é possível ativar o conjunto diário sem ativar o semanal, para que na maioria dos casos os backups incrementais precisem das fitas semanais. Estas estão sempre na biblioteca ou armazenadas em um depósito não tão remoto.
A lógica de trabalho dos jobs de tape no pool de mídia GFS , os redatores técnicos não me deixarão mentir. Resumindo, sem entrar em detalhes, apenas backups completos (incluindo backups completos virtuais) são copiados nos conjuntos semanais e mais antigos, um para cada data, enquanto no diário são todos os backups do repositório no dia atual, pois o job de backup pode ser executado mais de uma vez por dia.
Paralelismo, horário de início e espera nos pools GFS
Agora é possível a gravação paralela de vários jobs em várias unidades da biblioteca também nos pools de mídia GFS (antes, isso era possível apenas nos comuns). É ativado na etapa Opções do pool de mídia.
Uma observação importante: o mesmo arquivo sempre é escrito em um único fluxo, portanto, no caso de várias máquinas virtuais grandes, é recomendável ativar , para que o backup consistisse em várias cadeias.
Além disso, agora é possível escolher o horário de início do próprio job GFS. Muitos usuários não gostavam do início à meia-noite e da espera subsequente durante quase um dia inteiro até que o job de source fosse concluído. Agora esse horário pode ser ajustado, por exemplo, para o final da noite, quando já há o que copiar para a fita. Mais importante, a partir de solicitações de usuários, trouxemos para as configurações avançadas uma opção que antes só podia ser ativada através de uma chave de registro. Basta selecionar Processar o ponto de restauração mais recente em vez de esperar – e o que está no repositório no momento do início do job de tape é copiado para a fita (por exemplo, o ponto de ontem), sem espera alguma.
Trabalho aprimorado com várias bibliotecas
Vamos falar sobre a situação em que mais de uma biblioteca é adicionada a um único pool de mídia. Já suportamos isso antes, mas de tempos em tempos recebíamos reclamações de clientes sobre comportamentos um tanto imprevisíveis.
Foi
Por exemplo, uma job de tape começou, ocupou duas drives da primeira biblioteca, mas as configurações de paralelismo permitem que use quatro drives simultaneamente. Essa job deve alternar para a segunda biblioteca do pool de mídia e também utilizar seus recursos, ou isso seria um desperdício de recursos?
Outro caso. A opção de alternar sob a condição "sem fitas disponíveis" foi escolhida, na primeira biblioteca há apenas uma fita, mas todos os dados podem caber nela. No entanto, as configurações permitem gravar paralelamente em duas fitas. Devemos envolver a segunda biblioteca nesse caso?
Decidimos organizar essa área, permitindo configurar o comportamento de maneira explícita.
Tornou-se
agora têm funções - ativa e passiva. E o próprio pool de mídia tem dois modos: redundante, ou failover (failover) e gravação paralela (paralleling). Agora, dependendo das necessidades, o pool de mídia pode ser configurado de diferentes maneiras.
- Se você tem várias bibliotecas equivalentes e precisa paralelizar a gravação nelas - ativa o modo de gravação paralela, para isso todas as bibliotecas devem receber funções ativas. Nesse caso, novas fitas e drives serão utilizados imediatamente, assim que houver necessidade, independentemente de em qual biblioteca estejam. Ainda existe prioridade - inicialmente tentaremos encontrar recursos na biblioteca listada primeiro.
- Se há uma biblioteca principal e um drive mais antigo ou standalone em reserva, ative o modo failover, colocando a biblioteca principal no topo da lista e escolhendo a função passiva para os dispositivos de reserva. A troca para esse dispositivo ocorrerá apenas quando for realmente necessário, para que a job funcione de alguma forma. Essa situação será considerada uma anomalia, e uma notificação será enviada por e-mail.
Há uma situação mais complexa que ainda não suportamos – várias bibliotecas ativas na presença de passivas. O feedback mostrará se há necessidade de tais configurações e se é necessário 'aprimorar' o recurso no futuro. É uma prática padrão.
Suporte a WORM
WORM – Write Once Read Many – fitas que não podem ser apagadas ou regravadas , só é possível adicionar dados. O uso obrigatório delas é regulamentado por regras de algumas organizações, como as que atuam na área da medicina. O principal problema com essas fitas anteriormente era que o VBR durante ou gravava um cabeçalho que, posteriormente, não podia ser apagado, e os trabalhos de fita falhavam com erro ao tentar essa ação.
Na atualização 9.5 Update 4, foi implementado suporte completo a essas fitas. Foram adicionados pools de mídia WORM, comum e GFS, onde é possível colocar apenas fitas desse tipo.
As novas fitas têm um ícone azul, 'congelado'. Do ponto de vista do usuário, o trabalho com fitas WORM não difere do trabalho com fitas comuns.
A 'Wormidade' das fitas é inicialmente determinada pelo sufixo , se o código de barras for comum ou ilegível, a informação é fornecida pelo driver ao inserir a fita pela primeira vez. Não será possível colocar fitas WORM em um pool de mídia comum e gravar nelas. Curiosamente, alguns usuários já colaram códigos de barras WORM em fitas comuns e ficaram surpresos com as mudanças em sua infraestrutura após a atualização.
O chip da fita
Simultaneamente à implementação de fitas não regraváveis, começamos a trabalhar com o Os atributos padrão no chip anteriormente não eram utilizados por nós, agora escrevemos e lemos alguns deles, mas não os consideramos como a principal fonte de dados. O principal guia continua sendo o cabeçalho da fita. Essa decisão mostrou-se acertada: após um mês do lançamento, vemos como o 'zoológico' de hardware dos usuários apresenta surpresas no que diz respeito ao trabalho com o chip.
Backup de volumes NDMP em fita
Em conclusão – sobre o recurso mais solicitado em termos de feedback nesta atualização. O backup de volumes NDMP em fitas agora está disponível. É necessário adicionar um servidor NDMP à infraestrutura do VBR. , após o que na tarefa de fita será possível escolher volumes deste host. Eles são armazenados em fitas na forma de arquivos com um atributo especial, para diferenciá-los dos comuns durante a catalogação.
Na primeira implementação existem certas limitações: extensões não são suportadas, além disso, é possível fazer backup e restauração apenas do volume completo, não de arquivos individuais. O backup é feito através de (no caso da NetApp – ), aqui há suas particularidades: o número máximo de pontos incrementais é 9, após o que é forçado um backup completo.
Em conclusão
Essas foram apenas as mais significativas inovações na área de backup em fita no VBR 9.5 Update 4. Outras mudanças listarei a seguir:
- possibilidade de definir a ordem das tarefas de fonte e arquivos nas tarefas de fita;
- adicionada a função de Operador de Fita (o usuário pode fazer tudo, exceto a recuperação da fita – para isso existe o Operador de Restauração);
- adicionadas máscaras de inclusão/exclusão completas na tarefa de fita (exceto NDMP);
- melhorada a recuperação na tarefa de fita (a pasta é restaurada com os arquivos que estavam lá no momento do backup, e não com todos os que já estiveram lá durante toda a sua história de backups – uma funcionalidade muito requisitada, aliás);
- aumentada a velocidade de restauração de um grande número de arquivos a partir das fitas;
- melhorado o algoritmo de seleção da próxima fita para gravação, em particular, com parâmetros iguais, levamos em conta o volume de dados gravados/lidos durante toda a sua vida, pegamos a mais recente;
- melhorada a estabilidade do produto.
Links Úteis
Para variar, apresento alguns links para recursos em russo:
- E retornamos ao lugar anterior com vídeos de visão geral «Como funciona» (embora, até agora, em inglês) – podem ser assistidos . A respeito das fitas é falado nos slides 95 – 102.
Fonte: habr.com
