{"id":29927,"date":"2019-10-31T21:32:42","date_gmt":"2019-10-31T18:32:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bekap-mne-na-lentu-zapili-rasskaz-ot-pervogo-litsa\/"},"modified":"2019-10-31T21:32:42","modified_gmt":"2019-10-31T18:32:42","slug":"bekap-mne-na-lentu-zapili-rasskaz-ot-pervogo-litsa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/bekap-mne-na-lentu-zapili-rasskaz-ot-pervogo-litsa","title":{"rendered":"\"Fa\u00e7a um backup para mim na fita.\" Uma narrativa em primeira pessoa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Em artigo anterior<\/a><\/noindex> Falamos sobre os novos recursos na atualiza\u00e7\u00e3o de janeiro Update 4 para Veeam Backup & Replication 9.5 (VBR), onde deliberadamente n\u00e3o mencionamos os backups em fitas magn\u00e9ticas. Um relato sobre essa \u00e1rea merece um artigo separado, pois realmente houve muitos novos recursos.<\/p>\n

\u2013 Pessoal do QA, voc\u00eas v\u00e3o escrever um artigo?
\n\u2013 Por que n\u00e3o!<\/p>\n

\""Fa\u00e7a
\n
\n<\/a><\/noindex><\/p>\n

Armazenamento em fita no s\u00e9culo XXI<\/h1>\n

\nO armazenamento de dados em fitas magn\u00e9ticas (cartuchos, \"fitas<\/b>\", como n\u00f3s as chamamos na R&D) n\u00e3o se limita ao computador ZX-Spectrum do passado, cujo jogo poderia carregar na mem\u00f3ria RAM de 48 kb a partir de uma fita cassete<\/a><\/noindex> em alguns minutos. Em um quarto de s\u00e9culo, a velocidade e a capacidade das fitas aumentaram em 6-7 ordens de magnitude. Esta n\u00e3o \u00e9 uma compara\u00e7\u00e3o totalmente precisa, e pela lei de Moore<\/a><\/noindex> especifica\u00e7\u00e3o LTO<\/a><\/noindex> n\u00e3o est\u00e1 acompanhando. No entanto, as tecnologias modernas permitem gravar at\u00e9 12 terabytes de dados em uma fita de quil\u00f4metro de comprimento (at\u00e9 30 terabytes em modo de compress\u00e3o), assim, um dispositivo de 160 d\u00f3lares 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\u00e7\u00e3o\/leitura. Os dados em tais fitas s\u00e3o armazenados com seguran\u00e7a por 15-30 anos.<\/p>\n

Vou abordar de outra forma. Recentemente, os ransomware<\/a><\/noindex> alcan\u00e7aram um novo n\u00edvel. 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 \u2013 destruir (n\u00e3o sem a ajuda humana, j\u00e1 que grandes quantias est\u00e3o em jogo) n\u00e3o apenas todos os dados, mas tamb\u00e9m todos os backups, at\u00e9 os que conseguem acessar. Aqui est\u00e1 um exemplo recente<\/a><\/noindex>, quando a empresa teve que pagar aos sequestradores. Os chamados air gaps<\/b>, ou seja, backups fisicamente isolados da infraestrutura tornaram-se, na pr\u00e1tica, o \u00fanico salvaguarda confi\u00e1vel contra tais situa\u00e7\u00f5es. A fita magn\u00e9tica aqui \u00e9 uma das solu\u00e7\u00f5es que n\u00e3o se tornaram obsoletas.<\/p>\n

\""Fa\u00e7a
\n
\nMas apenas uma especifica\u00e7\u00e3o e inova\u00e7\u00f5es tecnol\u00f3gicas em hardware de \u00edm\u00e3s e b\u00e1rio-ferrite dos principais fabricantes (IBM, HPE, Oracle, Dell) n\u00e3o s\u00e3o suficientes para uma prote\u00e7\u00e3o confi\u00e1vel de dados; \u00e9 necess\u00e1rio 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\u00ea pode ter visto os resultados desse trabalho em artigos anteriores (um<\/a><\/noindex>, dois<\/a><\/noindex>). O que foi feito no \u00faltimo ano?<\/p>\n

Gloss\u00e1rio<\/h1>\n

\nSurge a escolha entre as liberdades em rela\u00e7\u00e3o \u00e0 l\u00edngua nativa e os jarg\u00f5es que dificultam a leitura. Prefiro a primeira op\u00e7\u00e3o, portanto, pe\u00e7o desculpas antecipadamente se algumas g\u00edrias da lista abaixo incomodarem algu\u00e9m. Aqui, relembrando brevemente, est\u00e1 o que significa cada termo. <\/p>\n

Os especialistas em VBR podem ignorar esta parte.<\/b>Job <\/b>\u2013 tarefa \u2013 um trabalho de backup. Na verdade, todo o VBR \u00e9 constru\u00eddo em torno de jobs. Al\u00e9m de backup e replica\u00e7\u00e3o, isso pode incluir a c\u00f3pia em fita magn\u00e9tica (backup to tape job). Devo esclarecer que a restaura\u00e7\u00e3o de um backup tamb\u00e9m \u00e9 um job, mas neste artigo a palavra se referir\u00e1 especificamente ao backup.<\/p>\n

Storage <\/b>\u2013 uma denomina\u00e7\u00e3o historicamente estabelecida. Esses s\u00e3o arquivos em reposit\u00f3rio <\/b>(repository \u2013 reposit\u00f3rio), que cont\u00eam backups \u2013 opera\u00e7\u00f5es totalmente <\/b>e incrementais<\/b>. Em um storage, pode haver uma ou v\u00e1rias m\u00e1quinas virtuais.<\/p>\n

Chain <\/b>\u2013 uma sequ\u00eancia de storages interconectados. Para restaurar dados de um determinado storage incremental, s\u00e3o necess\u00e1rios todos os anteriores, desde o (n-1) at\u00e9 o primeiro, al\u00e9m do storage completo ao qual o primeiro storage incremental se refere.<\/p>\n

Source<\/b>, Target <\/b>\u2013 fonte, destino. Source \u00e9 a entidade original que \u00e9 processada pelo job. No caso de backups\/replica\u00e7\u00f5es, geralmente \u00e9 uma m\u00e1quina virtual no hipervisor. No caso de jobs de fita, a source \u00e9 o pr\u00f3prio job de backup (ou arquivos no caso de file to tape job). O target para um job de backup \u00e9 o reposit\u00f3rio onde os backups s\u00e3o armazenados. Para jobs de fita, \u00e9 o media pool.<\/p>\n

Media pool<\/b> \u2013 media pool<\/a><\/noindex> \u2013 um pool de m\u00eddia, no nosso caso, de fitas. Um cont\u00eainer l\u00f3gico, criado pelo usu\u00e1rio, que cont\u00e9m fitas de uma ou mais bibliotecas. Portanto, um job de fita sempre possui um media pool como target, ou seja, os dados n\u00e3o s\u00e3o escritos em uma fita espec\u00edfica nem em qualquer fita na biblioteca, mas em um conjunto definido delas. O media pool tem uma configura\u00e7\u00e3o de tempo de reten\u00e7\u00e3o de dados, ap\u00f3s o qual a fita pode ser regravada. O usu\u00e1rio pode criar pools padr\u00e3o (standard) e GFS pools<\/a><\/noindex>. Cada um desses tipos pode agora ser WORM ou n\u00e3o-WORM, como ser\u00e1 discutido a seguir.<\/p>\n

Media set<\/b> \u2013 media set<\/a><\/noindex> \u2013 um conjunto de fitas em um pool de m\u00eddia, nas quais backups\/files s\u00e3o continuamente gravados. Para pools GFS, os grupos de m\u00eddia tamb\u00e9m est\u00e3o vinculados a um intervalo (por exemplo, anual \u2013 yearly), as fitas s\u00e3o rotacionadas apenas dentro de seu intervalo.<\/p>\n

Drive<\/b>, changer<\/b><\/a><\/noindex> \u2013 elementos da biblioteca de fitas. O drive l\u00ea e rebobina a fita, o changer \u2013 \u00e9 um rob\u00f4 que move as fitas entre slots de armazenamento, slots de descarregamento e o drive. Existem tamb\u00e9m drives standalone<\/b> (standalone \u2013 aut\u00f4nomo), onde um humano desempenha o papel de changer. Para o drive, \u00e9 imprescind\u00edvel que o driver do fabricante esteja corretamente instalado na m\u00e1quina Windows \u00e0 qual a biblioteca est\u00e1 conectada; com o changer, podemos operar sem drivers, usando SCSI nativo.<\/p>\n

<\/p>\n

Tenant to tape. O provedor est\u00e1 protegido \u2013 os clientes est\u00e3o protegidos.<\/h1>\n

\nColocando as cartas na mesa. O maior recurso da nossa atualiza\u00e7\u00e3o, destinado a provedores de nuvem.<\/a><\/noindex>, que usam VBR em sua infraestrutura. O desenvolvimento come\u00e7ou h\u00e1 dois anos. Logo percebemos que n\u00e3o conseguir\u00edamos cumprir essa tarefa s\u00e9ria at\u00e9 o pr\u00f3ximo lan\u00e7amento, fizemos uma pequena pausa e, por fim, lan\u00e7amos o recurso na atualiza\u00e7\u00e3o 9.5 Update 4.<\/p>\n

Resumo: Agora, os provedores t\u00eam a capacidade de copiar os backups de seus clientes para fitas usando jobs de tape em um pool GFS. Isso oferece aos provedores \u2013 que s\u00e3o grandes e muito queridos por nosso cora\u00e7\u00e3o e departamento comercial \u2013 duas oportunidades:<\/p>\n