Fazer o backup de banco de dados é essencial. Afinal, ele contém informações de suma importância para o negócio. Portanto, entender como fazer esse trabalho também é fundamental.
O que são banco de dados?
Bancos de dados são também chamados de dados estruturados. Afinal, consistem numa parte essencial de qualquer data center. Geralmente, os bancos de dados não contam com uma alta porcentagem de terabytes alojados em um determinado data center. Contudo, ainda mantêm uma alta porcentagem de dados de missão crítica. Portanto, compreender sua estrutura e operação exclusivas é a chave para apoiá-los.
Fazer backup de dados não estruturados é simples. Entretanto, fazer backup de banco de dados não. Isso acontece por três motivos:
Primeiro
Os bancos de dados são normalmente armazenados em arquivos de dados que mudam constantemente. Pelo menos, desde que algo esteja fazendo atualizações no banco de dados. Ou seja, você não pode simplesmente fazer o backup como qualquer outro arquivo.
Segundo
A maioria dos bancos de dados tem algum tipo de diário. Este pode ser reproduzido para restaurar transações após uma restauração pontual. Mas também para reverter uma transação parcialmente concluída após um travamento.
Terceiro
Uma restauração típica começa restaurando os arquivos de dados do backup mais recente. Então, é feita uma restauração para um estado o mais recente possível. Este é o objetivo do ponto de recuperação (RPO). Afinal, possibilita restaurações típicas de uma única etapa da maioria dos sistemas de backup. Contudo, ele simplesmente não é bom o suficiente para backup de banco de dados de missão crítica.
Saber disso é a chave para fazer um backup de seu banco de dados correto. Afinal, tudo depende de como seu banco de dados resolve esses desafios.
Modelos de banco de dados
Existem pelo menos 13 modelos de banco de dados diferentes. Portanto, saber como fazer o backup do seu começa sabendo de que tipo de banco de dados você tem..
Esses modelos incluem:
- Relacional (o mais comum);
- Valor-chave;
- Série temporal;
- Documento
- Gráfico;
- Mecanismo de pesquisa;
- Coluna ampla;
- Orientado a objeto;
- RDF;
- Valor múltiplo;
- XML nativo;
- Navegação;
- Evento.
Confira a seguir uma lista dos modelos mais populares de banco de dados:
Relacional
Um sistema de gerenciamento de banco de dados relacional (RDBMS) é o mais comum. Afinal, é o que a maioria das pessoas pensa quando diz a palavra banco de dados. Ou seja, consiste em uma série de tabelas com:
- Esquema definido (layout de tabela);
- Registros (linhas);
- Atributos (valores).
Os exemplos incluem Oracle, SQL Server, MySQL e PostgreSQL. Esses bancos de dados são freqüentemente chamados de bancos de dados SQL. Isso devido à linguagem de consulta que usam.
Valor chave
Trata-se de um DBMS NoSQL (não apenas SQL) muito simples. Afinal, consiste em chaves e valores. Neles, você pode pesquisar o valor se souber a chave. Exemplos populares são Redis e DynamoDB.
Série temporal
Um banco de dados NoSQL projetado especificamente para lidar com dados de tempo. Afinal, cada entrada tem um carimbo de hora. O popular banco de dados Prometheus é um exemplo e é bastante usado no Kubernetes.
Documento
Um SGBD NoSQL sem esquema é projetado especificamente para armazenar documentos. Dessa forma, os registros não precisam estar em conformidade com nenhum padrão uniforme. Portanto, podem armazenar tipos de dados muito diferentes. JSON é frequentemente usado para armazenar documentos em um banco de dados. Contudo, o MongoDB é o mais popular que suporta apenas o modelo de documento.
Coluna larga
É outro SGBD NoSQL sem esquema que pode armazenar um grande número de colunas de dados sem um esquema predefinido. Nomes de colunas e chaves podem ser definidos em todo o banco de dados. Cassandra é o mais conhecido desse tipo.
Dicionário de banco de dados
Saber a terminologia do banco de dados também é importante. Portanto, confira a seguir os termos mais relevantes. Contudo, nem todos os bancos de dados usam os mesmos termos. Entretanto, devem ter um termo semelhante que signifique a mesma coisa.
Ainda assim, bancos de dados NoSQL geralmente usam termos muito diferentes. Portanto, podem não ter algo semelhante ao item em questão.
Arquivo de dados
Um arquivo de dados é onde um banco de dados armazena seus dados. Ou seja, pode ser um dispositivo bruto ou um arquivo “preparado”.
| Dispositivo bruto: dev / hda1 no Linux
Arquivo preparado: sap/datafiles/dbs06.dbf ou c: MySQL datafile.dbf |
A maioria dos bancos de dados usa arquivos processados ou regulares como arquivos de dados. Portanto, boa parte tem mais de um para cada banco de dados.
Mesa
É aqui que as coisas ficam um pouco turvas. Em um banco de dados SQL, relacional, uma tabela é um monte de valores relacionados. Então, estes se comportam como uma planilha virtual. Os bancos de dados NoSQL podem ter algo semelhante ou não.
Tablespace
Um tablespace é um espaço onde você coloca tabelas. Portanto, é uma coleção de um ou mais arquivos de dados. Se seu banco de dados não possui tabelas, provavelmente não possui espaços de tabela.
Partição
Bancos de dados modernos podem dividir, espalhar ou particionar uma tabela em vários recursos, E isso inclui vários espaços de tabela.
Sharding
Sharding leva o particionamento a outro nível. Portanto, é a chave para bancos de dados de grande escala. A fragmentação pode até mesmo colocar fragmentos de uma mesa em nós diferentes.
Banco de dados mestre
Um banco de dados mestre controla o status de todos os bancos de dados e arquivos de dados. Ou seja, se vários bancos de dados forem permitidos, ele também precisará controlá-los.
Transação
Trata-se de uma atividade em um banco de dados que altera um ou mais atributos em uma ou mais tabelas. Ou seja, transações simples mudam um atributo. Contudo, transações complexas mudam muitos atributos como uma ação atômica única. Os bancos de dados NoSQL tendem a usar transações simples.
Log de transações
Um log de transações registra cada transação e quais elementos ela mudou. Essas informações são usadas em caso de falha do sistema. Contudo, também são úteis após uma restauração para desfazer ou refazer transações.
Modelos de consistência
Existem duas formas muito diferentes de os bancos de dados garantirem que as visualizações dos dados sejam iguais para todos os usuários. Eles são chamados de modelos de consistência e afetam o backup de banco de dados e a recuperação.
Consistência forte
A primeira é a consistência imediata, também conhecida como consistência forte. Afinal, garante que todos os usuários vejam os mesmos dados ao mesmo tempo. Isso, independentemente de onde ou como eles visualizam os dados. Portanto, a maioria dos bancos de dados tradicionais e relacionais segue esse modelo.
Consistência fraca
O segundo modelo é um banco de dados eventualmente consistente. Ele também é conhecido como consistência fraca. Isso, porque garante que um determinado atributo será eventualmente consistente para todos os visualizadores. No entanto, isso pode levar algum tempo. Um grande exemplo de consistência eventual está no sistema DNS. Afinal, deve esperar até que o tempo de vida dos registros DNS expire antes de atualizar as informações sobre os nomes de domínio. Isso pode levar até 72 horas.
De que, como e por que você está fazendo backup de banco de dados?
Você é responsável por fazer o backup de banco de dados? Então você precisa entender como ele é construído e como funciona. Ou seja, entender:
- Onde ele armazena seus dados como arquivos de dados;
- Se usa ou não transações complexas ou simples;
- Onde armazena o registro dessas transações;
- Como obter um backup consistente dos dados e do log de transações.
Mas isso não basta. Afinal, você também precisa entender como seu banco de dados está distribuído. Ele é particionado. Ok. Mas está tudo dentro de um host? Ou está tudo fragmentado e espalhado por dezenas ou centenas de hosts? Se for o último, provavelmente você estará lidando com um banco de dados eventualmente consistente. Portanto, obter um instantâneo consistente de um banco de dados espalhado por centenas de nós será bastante desafiador. Isso sem falar em restaurá-lo.
Muitas pessoas pensam que um banco de dados eventualmente consistente que usa replicação em muitos nós não precisa de backup. Contudo, não se engane! Ele definitivamente precisa. Enquanto você está protegido contra falha de nó, você com certeza não está protegido contra erro humano. Ou seja, se uma tabela cair, não importa o quão replicada ela é. Você precisará restaurá-lo.
