Olá pessoal!
Há algum tempo, mergulhei no mundo das "empresas agressivas", principalmente na área responsável por armazenar e fazer backup de dados. Mais precisamente, nele mais. E durante esse período, acumulei várias regras às quais tento aderir ao projetar ou fazer a manutenção de soluções nessa área. Alguns já sobreviveram aos seus, com o desenvolvimento da tecnologia, e outros estão funcionando bem. E eu decidi compartilhá-los com você.
Não haverá regra 3-2-1, que é frequentemente mencionada sem mim, bem como algumas técnicas diretas para situações específicas e outras coisas na mesma linha. Talvez para a maioria dos que estão lendo este seja o básico e o banal. Esta é apenas a minha modesta experiência e espero que seja útil para alguém. Eu peço gato.
Recursos do "dimensionamento" local
Mais cedo ou mais tarde, é necessário obter mais terabytes e / ou IOPS. E então o dimensionamento começa. Muitas vezes sem sentido e sem piedade. Porque é extremamente raro alguém estabelecer requisitos de RTO para dimensionamento, que geralmente são apresentados para backup. Embora pareça um requisito óbvio para qualquer complexo de hardware. I.e. Ao dimensionar e formar requisitos para novos equipamentos, por algum motivo, os requisitos do sistema de backup, que restauram urgentemente algo no seu hardware, não são levados em consideração. Às vezes, algo é muito grande. Em geral, algum tipo de margem de produtividade e espaço está sendo definido, mas a primeira recuperação de dados mostra que não será suficiente para o ciclo de vida definido para este equipamento.
No ano passado, eu já vi uma situação duas vezes quando o gargalo durante a recuperação de dados era a matriz de discos na qual a recuperação foi executada. Eles se encaixavam no RTO, mas a campainha era alarmante.
Temos uma solução no cluster, por que você precisa de backup ?!
É essa frase proferida “energeticamente” que ouvi ao comunicar
com um desenvolvedor de um software muito útil para uma empresa. O desenvolvedor argumentou que o backup é desnecessário para recuperação pelo fato de a solução ser implantada em um cluster e, portanto, se um nó (ou matriz de discos) cair no site, o cluster será salvo. Nesses casos, ele sem dúvida salvará. Isso geralmente é excelente quando existem pessoas que pensam em tolerância a falhas, mesmo no estágio de desenvolvimento.
No entanto, a perda de dados é alcançada não apenas pela falha do equipamento em um site e, por algum motivo, o desenvolvedor não quer entender isso há algum tempo. Como resultado, a primeira versão do software foi lançada no DBMS da comunidade, cuja mecânica de backup não permitia atender aos requisitos de RTO / RPO ou ao SLA do contratado.
Em geral, ouço essa frase sobre um cluster com bastante frequência.
Primeiro, então isso!
Um dos meus maiores erros foi considerar os objetos de backup como independentes. Aqui está o DBMS, aqui está o software. Isso é backup assim, e é assim. Primeiro, depois outro. E um dia não conseguimos nos recuperar. Mais precisamente, eles poderiam, mas pelos poucos dias que foram gastos na correção de erros no banco de dados. E não fui eu quem os eliminou, pelo qual tenho vergonha. Embora tenhamos usado um mecanismo de backup regular para este DBMS. Já testado em outros sistemas.
A partir desse momento, enfio o nariz e agito o desenvolvedor / proprietário do sistema sobre o assunto de como fazer backup e restaurar corretamente. Por exemplo, em um caso, a única maneira de criar um backup funcional era parar completamente os serviços em 5 servidores, fazer um backup e iniciar os serviços.
Despejar tudo?
Muitas vezes, encontro soluções em DBMSs como MySQL e PostgreSQL. E ainda mais frequentemente me deparei com uma situação em que o despejo banal do banco de dados em / tmp é usado como método de backup e depois para outro meio. Ao mesmo tempo, os sistemas em que esses DBMSs são usados são bastante críticos para o tempo de inatividade em caso de perda de dados e são muito carregados. Eu já estou em silêncio sobre volumes.
Por alguma razão, poucas pessoas leem a documentação desses produtos e não sabem que existem métodos e soluções alternativas para criar backups desses DBMSs.
MySQL Enterprise Backup para MySQL e
pg_basebackup (
pg_start_backup, pg_stop_backup ) respectivamente no PostgreSQL. Ou ele sabe, mas voou fora de sua cabeça. Embora essas soluções não sejam muito mais complicadas e rápidas. Backup mais rápido, restauração mais rápida, teste mais rápido.
Por favor, não atire no pianista.
Ele está fazendo o seu melhor.
Oscar Fingal O'Flahertie quer Wilde