Por que você precisa fazer backups? Afinal, o equipamento é muito, muito confiável e, além disso, existem “nuvens” que são melhores em confiabilidade do que servidores físicos: com configuração adequada, um servidor “nuvem” pode facilmente sobreviver à falha de um servidor físico de infraestrutura, e de Do ponto de vista dos usuários do serviço, haverá um salto pequeno, quase imperceptível, no tempo de atendimento. Além disso, a duplicação de informações muitas vezes exige o pagamento de tempo “extra” de processador, carga de disco e tráfego de rede.
Um programa ideal roda rápido, não vaza memória, não tem falhas e não existe.
-Desconhecido
Como os programas ainda são escritos por desenvolvedores de proteínas e muitas vezes não há processo de teste, e os programas raramente são entregues usando as “melhores práticas” (que também são programas e, portanto, imperfeitas), os administradores de sistema na maioria das vezes têm que resolver problemas que parecem breves, mas sucintamente: “voltar a ser como estava”, “trazer a base para o funcionamento normal”, “funciona devagar - reverter”, e também o meu preferido “não sei o quê, mas conserte”.
Além de erros lógicos que surgem como resultado do trabalho descuidado dos desenvolvedores, ou de uma combinação de circunstâncias, bem como conhecimento incompleto ou mal-entendido de pequenos recursos de construção de programas - incluindo os de conexão e de sistema, incluindo sistemas operacionais, drivers e firmware - também existem outros erros. Por exemplo, a maioria dos desenvolvedores confia no tempo de execução, esquecendo-se completamente das leis físicas, que ainda são impossíveis de contornar com programas. Isso inclui a confiabilidade infinita do subsistema de disco e, em geral, de qualquer subsistema de armazenamento de dados (incluindo RAM e cache do processador!), e tempo de processamento zero no processador, e a ausência de erros durante a transmissão pela rede e durante o processamento no processador e latência de rede, que é igual a 0. Não se deve descuidar do notório prazo, pois se não cumpri-lo a tempo, haverá problemas piores do que as nuances da operação da rede e do disco.
O que fazer com problemas que surgem com força total e pairam sobre dados valiosos? Não há nada que substitua os desenvolvedores vivos, e não é fato que isso será possível em um futuro próximo. Por outro lado, apenas alguns projectos conseguiram provar plenamente que o programa funcionará como pretendido, e não será necessariamente possível recolher e aplicar as provas a outros projectos semelhantes. Além disso, tais evidências levam muito tempo e requerem habilidades e conhecimentos especiais, o que praticamente minimiza a possibilidade de sua utilização levando em consideração os prazos. Além disso, ainda não sabemos como utilizar tecnologia ultrarrápida, barata e infinitamente confiável para armazenar, processar e transmitir informações. Tais tecnologias, se existirem, estão na forma de conceitos ou - na maioria das vezes - apenas em livros e filmes de ficção científica.
Bons artistas copiam, grandes artistas roubam.
—Pablo Picasso.
As soluções mais bem-sucedidas e as coisas surpreendentemente simples geralmente acontecem onde se encontram conceitos, tecnologias, conhecimentos e campos da ciência que são absolutamente incompatíveis à primeira vista.
Por exemplo, pássaros e aviões têm asas, mas apesar da semelhança funcional - o princípio de funcionamento em alguns modos é o mesmo, e os problemas técnicos são resolvidos de forma semelhante: ossos ocos, uso de materiais fortes e leves, etc. os resultados são completamente diferentes, embora muito semelhantes. Os melhores exemplos que vemos na nossa tecnologia também são em grande parte emprestados da natureza: os compartimentos pressurizados de navios e submarinos são uma analogia direta com os anelídeos; construir matrizes de ataque e verificar a integridade dos dados – duplicando a cadeia de DNA; bem como órgãos emparelhados, independência do trabalho de diferentes órgãos do sistema nervoso central (automação do coração) e reflexos - sistemas autônomos na Internet. É claro que adotar e aplicar soluções prontas “de frente” traz muitos problemas, mas quem sabe não existam outras soluções.
Se eu soubesse onde você cairia, teria colocado canudos!
—Provérbio popular bielorrusso
Isso significa que as cópias de segurança são vitais para quem deseja:
- Ser capaz de restaurar a operação dos seus sistemas com tempo de inatividade mínimo ou mesmo sem tempo de inatividade
- Aja com ousadia, pois em caso de erro sempre existe a possibilidade de reversão
- Minimize as consequências da corrupção intencional de dados
Aqui está um pouco de teoria
Qualquer classificação é arbitrária. A natureza não classifica. Classificamos porque é mais conveniente para nós. E classificamos de acordo com dados que também pegamos arbitrariamente.
—Jean Brüler
Independentemente do método de armazenamento físico, o armazenamento lógico de dados pode ser dividido em duas formas de acesso a esses dados: bloco e arquivo. Esta divisão tem sido recentemente muito confusa, porque não existe armazenamento lógico puramente em bloco, assim como puramente em arquivo. No entanto, para simplificar, assumiremos que eles existem.
O armazenamento de dados em bloco implica que existe um dispositivo físico onde os dados são gravados em certas porções fixas, blocos. Os blocos são acessados em um determinado endereço; cada bloco possui seu próprio endereço dentro do dispositivo.
Um backup geralmente é feito copiando blocos de dados. Para garantir a integridade dos dados, a gravação de novos blocos, bem como alterações nos existentes, são suspensas no momento da cópia. Se fizermos uma analogia com o mundo comum, a coisa mais próxima é um armário com células numeradas idênticas.
O armazenamento de dados de arquivos baseado no princípio do dispositivo lógico é próximo ao armazenamento em bloco e geralmente é organizado na parte superior. Diferenças importantes são a presença de uma hierarquia de armazenamento e nomes legíveis por humanos. Uma abstração é alocada na forma de um arquivo - uma área de dados nomeada, bem como um diretório - um arquivo especial no qual são armazenadas descrições e acesso a outros arquivos. Os arquivos podem ser fornecidos com metadados adicionais: hora de criação, sinalizadores de acesso, etc. Os backups geralmente são feitos desta forma: eles procuram os arquivos alterados e depois os copiam para outro armazenamento de arquivos com a mesma estrutura. A integridade dos dados geralmente é implementada pela ausência de arquivos gravados. O backup dos metadados do arquivo é feito da mesma maneira. A analogia mais próxima é uma biblioteca, que possui seções com diferentes livros, e também possui um catálogo com nomes dos livros legíveis por humanos.
Recentemente, às vezes é descrita outra opção, a partir da qual, em princípio, começou o armazenamento de dados de arquivos e que possui as mesmas características arcaicas: o armazenamento de dados de objetos.
Difere do armazenamento de arquivos por não possuir mais de um aninhamento (esquema plano), e os nomes dos arquivos, embora legíveis por humanos, ainda são mais adequados para processamento por máquinas. Ao realizar backups, o armazenamento de objetos geralmente é tratado de forma semelhante ao armazenamento de arquivos, mas ocasionalmente há outras opções.
— Existem dois tipos de administradores de sistema, os que não fazem backups e os que JÁ fazem.
- Na verdade, existem três tipos: há também aqueles que verificam se os backups podem ser restaurados.-Desconhecido
Também vale a pena entender que o próprio processo de backup de dados é realizado por programas, por isso tem as mesmas desvantagens de qualquer outro programa. Para remover (não eliminar!) a dependência do fator humano, bem como de características - que individualmente não têm um efeito forte, mas juntas podem dar um efeito perceptível - os chamados regra 3-2-1. Existem muitas opções de como decifrá-lo, mas gosto mais da seguinte interpretação: 3 conjuntos dos mesmos dados devem ser armazenados, 2 conjuntos devem ser armazenados em formatos diferentes e 1 conjunto deve ser armazenado em um armazenamento geograficamente remoto.
O formato de armazenamento deve ser entendido da seguinte forma:
- Se houver dependência do método de armazenamento físico, alteramos o método físico.
- Se houver dependência do método lógico de armazenamento, alteramos o método lógico.
Para obter o efeito máximo da regra 3-2-1, é recomendável alterar o formato de armazenamento nos dois sentidos.
Do ponto de vista da prontidão de um backup para a finalidade pretendida - restauração da funcionalidade - é feita uma distinção entre backups “quentes” e “frios”. Os quentes diferem dos frios em apenas uma coisa: estão imediatamente prontos para uso, enquanto os frios requerem algumas etapas adicionais para recuperação: descriptografia, extração do arquivo, etc.
Não confunda cópias quentes e frias com cópias online e offline, que implicam isolamento físico dos dados e, na verdade, são mais um sinal da classificação dos métodos de backup. Portanto, uma cópia offline - não conectada diretamente ao sistema onde precisa ser restaurada - pode ser quente ou fria (em termos de prontidão para recuperação). Uma cópia online pode estar disponível diretamente onde precisa ser restaurada e, na maioria das vezes, está quente, mas também existem cópias frias.
Além disso, não esqueça que o próprio processo de criação de cópias de backup geralmente não termina com a criação de uma cópia de backup e pode haver um número bastante grande de cópias. Portanto, é necessário distinguir entre backups completos, ou seja, aquelas que podem ser restauradas independentemente de outros backups, bem como cópias diferenciais (incrementais, diferenciais, decrementais, etc.) - aquelas que não podem ser restauradas de forma independente e requerem a restauração preliminar de um ou mais backups.
Os backups incrementais diferenciais são uma tentativa de economizar espaço de armazenamento de backup. Assim, apenas os dados alterados do backup anterior são gravados na cópia de backup.
Os decrementais diferenciais são criados para o mesmo propósito, mas de uma forma um pouco diferente: um backup completo é feito, mas apenas a diferença entre a cópia nova e a anterior é realmente armazenada.
Separadamente, vale considerar o processo de backup sobre armazenamento, que suporta a ausência de armazenamento de duplicatas. Assim, se você gravar backups completos sobre ele, apenas as diferenças entre os backups serão realmente gravadas, mas o processo de restauração dos backups será semelhante ao de restauração a partir de uma cópia completa e totalmente transparente.
Quis custodiet ipsos custodes?
(Quem protegerá os próprios vigias? - lat.)
É muito desagradável quando não há cópias de segurança, mas é muito pior se uma cópia de segurança parece ter sido feita, mas ao restaurar verifica-se que não pode ser restaurada porque:
- A integridade dos dados de origem foi comprometida.
- O armazenamento de backup está danificado.
- A restauração funciona muito lentamente; você não pode usar dados que foram parcialmente recuperados.
Um processo de backup construído adequadamente deve levar em conta tais comentários, especialmente os dois primeiros.
A integridade dos dados de origem pode ser garantida de diversas maneiras. Os mais comumente usados são os seguintes: a) criação de instantâneos do sistema de arquivos no nível do bloco, b) “congelamento” do estado do sistema de arquivos, c) um dispositivo de bloco especial com armazenamento de versão, d) gravação sequencial de arquivos ou blocos. As somas de verificação também são aplicadas para garantir que os dados sejam verificados durante a recuperação.
A corrupção do armazenamento também pode ser detectada usando somas de verificação. Um método adicional é o uso de dispositivos especializados ou sistemas de arquivos nos quais os dados já gravados não podem ser alterados, mas novos podem ser adicionados.
Para acelerar a recuperação, a recuperação de dados é usada com vários processos de recuperação - desde que não haja gargalos na forma de uma rede lenta ou de um sistema de disco lento. Para contornar a situação com dados parcialmente recuperados, você pode dividir o processo de backup em subtarefas relativamente pequenas, cada uma delas executada separadamente. Assim, torna-se possível restaurar o desempenho de forma consistente e, ao mesmo tempo, prever o tempo de recuperação. Este problema reside na maioria das vezes no plano organizacional (SLA), por isso não nos deteremos neste assunto em detalhes.
Especialista em temperos não é aquele que os acrescenta a todos os pratos, mas sim aquele que nunca acrescenta nada a mais.
-EM. Sinyavsky
As práticas relativas ao software utilizado pelos administradores de sistema podem variar, mas os princípios gerais ainda são, de uma forma ou de outra, os mesmos, em particular:
- É altamente recomendável usar soluções prontas.
- Os programas devem funcionar de forma previsível, ou seja, Não deve haver recursos ou gargalos não documentados.
- A configuração de cada programa deve ser tão simples que você não precise ler o manual ou a folha de dicas todas as vezes.
- Se possível, a solução deverá ser universal, porque os servidores podem variar muito em suas características de hardware.
Existem os seguintes programas comuns para fazer backups de dispositivos de bloco:
- dd, familiar aos veteranos em administração de sistemas, também inclui programas semelhantes (o mesmo dd_rescue, por exemplo).
- Utilitários integrados em alguns sistemas de arquivos que criam um dump do sistema de arquivos.
- Utilitários onívoros; por exemplo, partclone.
- Decisões próprias, muitas vezes proprietárias; por exemplo, NortonGhost e posteriores.
Para sistemas de arquivos, o problema de backup é parcialmente resolvido usando métodos aplicáveis para dispositivos de bloco, mas o problema pode ser resolvido de forma mais eficiente usando, por exemplo:
- Rsync, um programa e protocolo de uso geral para sincronizar o estado dos sistemas de arquivos.
- Ferramentas de arquivamento integradas (ZFS).
- Ferramentas de arquivamento de terceiros; o representante mais popular é o alcatrão. Existem outros, por exemplo, dar - um substituto para o alcatrão voltado para sistemas modernos.
Vale a pena mencionar separadamente as ferramentas de software para garantir a consistência dos dados ao criar cópias de backup. As opções mais comumente usadas são:
- Montar o sistema de arquivos no modo somente leitura (ReadOnly) ou congelar o sistema de arquivos (congelar) - o método tem aplicabilidade limitada.
- Criação de instantâneos do estado de sistemas de arquivos ou dispositivos de bloco (LVM, ZFS).
- Utilização de ferramentas de terceiros para organização de impressões, mesmo nos casos em que os pontos anteriores não possam ser fornecidos por algum motivo (programas como hotcopy).
- A técnica copy-on-change (CopyOnWrite), entretanto, é mais frequentemente vinculada ao sistema de arquivos usado (BTRFS, ZFS).
Portanto, para um servidor pequeno, você precisa fornecer um esquema de backup que atenda aos seguintes requisitos:
- Fácil de usar - nenhuma etapa adicional especial é necessária durante a operação, etapas mínimas para criar e restaurar cópias.
- Universal - funciona em servidores grandes e pequenos; isso é importante ao aumentar o número de servidores ou dimensionar.
- Instalado por um gerenciador de pacotes, ou em um ou dois comandos como “baixar e descompactar”.
- Estável - é usado um formato de armazenamento padrão ou estabelecido há muito tempo.
- Rápido no trabalho.
Candidatos daqueles que atendem mais ou menos aos requisitos:
- rdiff-backup
- rsinstantâneo
- arrotar
- duplicati
- duplicidade
- deixe enganar
- mas
- zbackup
- descanso
- borgbackup
Uma máquina virtual (baseada em XenServer) com as seguintes características será utilizada como bancada de testes:
- 4 núcleos de 2.5 GHz,
- 16 GB de RAM,
- Armazenamento híbrido de 50 GB (sistema de armazenamento com cache em SSD de 20% do tamanho do disco virtual) na forma de um disco virtual separado sem particionamento,
- Canal de Internet de 200 Mbits.
Quase a mesma máquina será usada como servidor receptor de backup, apenas com um disco rígido de 500 GB.
Sistema operacional - Centos 7 x64: partição padrão, partição adicional será usada como fonte de dados.
Como dados iniciais, vamos pegar um site WordPress com 40 GB de arquivos de mídia e um banco de dados mysql. Como os servidores virtuais variam muito em características e também para melhor reprodutibilidade, aqui está
resultados de testes de servidor usando sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 CPU executada
sysbench 1.1.0-18a9f86 (usando LuaJIT 2.1.0-beta3 incluído)
Executando o teste com as seguintes opções:
Número de tópicos: 4
Inicializando o gerador de números aleatórios a partir do horário atual
Limite de números primos: 20000
Inicializando threads de trabalho…
Tópicos iniciados!
Velocidade da cpu:
eventos por segundo: 836.69
Taxa de transferência:
eventos/s (eps): 836.6908
tempo decorrido: 30.0039s
número total de eventos: 25104
Latência (ms):
min: 2.38
média: 4.78
máx: 22.39
95º percentil: 10.46
soma: 119923.64
Equidade de tópicos:
eventos (média/padrão): 6276.0000/13.91
tempo de execução (média/stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=ler execução de memória
sysbench 1.1.0-18a9f86 (usando LuaJIT 2.1.0-beta3 incluído)
Executando o teste com as seguintes opções:
Número de tópicos: 4
Inicializando o gerador de números aleatórios a partir do horário atual
Executando teste de velocidade de memória com as seguintes opções:
tamanho do bloco: 1KiB
tamanho total: 102400 MiB
operação: leia
escopo: global
Inicializando threads de trabalho…
Tópicos iniciados!
Total de operações: 50900446 (1696677.10 por segundo)
49707.47 MiB transferidos (1656.91 MiB/seg)
Taxa de transferência:
eventos/s (eps): 1696677.1017
tempo decorrido: 30.0001s
número total de eventos: 50900446
Latência (ms):
min: 0.00
média: 0.00
máx: 24.01
95º percentil: 0.00
soma: 39106.74
Equidade de tópicos:
eventos (média/padrão): 12725111.5000/137775.15
tempo de execução (média/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=gravar execução de memória
sysbench 1.1.0-18a9f86 (usando LuaJIT 2.1.0-beta3 incluído)
Executando o teste com as seguintes opções:
Número de tópicos: 4
Inicializando o gerador de números aleatórios a partir do horário atual
Executando teste de velocidade de memória com as seguintes opções:
tamanho do bloco: 1KiB
tamanho total: 102400 MiB
operação: escrever
escopo: global
Inicializando threads de trabalho…
Tópicos iniciados!
Total de operações: 35910413 (1197008.62 por segundo)
35068.76 MiB transferidos (1168.95 MiB/seg)
Taxa de transferência:
eventos/s (eps): 1197008.6179
tempo decorrido: 30.0001s
número total de eventos: 35910413
Latência (ms):
min: 0.00
média: 0.00
máx: 16.90
95º percentil: 0.00
soma: 43604.83
Equidade de tópicos:
eventos (média/padrão): 8977603.2500/233905.84
tempo de execução (média/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio executado
sysbench 1.1.0-18a9f86 (usando LuaJIT 2.1.0-beta3 incluído)
Executando o teste com as seguintes opções:
Número de tópicos: 4
Inicializando o gerador de números aleatórios a partir do horário atual
Sinalizadores de abertura de arquivo extra: (nenhum)
128 arquivos, 8 MiB cada
Tamanho total do arquivo de 1 GiB
Tamanho do bloco 4KiB
Número de solicitações de IO: 0
Proporção de leitura/gravação para teste IO aleatório combinado: 1.50
FSYNC periódico habilitado, chamando fsync() a cada 100 solicitações.
Chamando fsync() no final do teste, Enabled.
Usando o modo de E/S síncrona
Fazendo teste r/w aleatório
Inicializando threads de trabalho…
Tópicos iniciados!
Taxa de transferência:
leia: IOPS = 3868.21 15.11 MiB/s (15.84 MB/s)
escrever: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latência (ms):
min: 0.00
média: 0.27
máx: 18.01
95º percentil: 1.08
soma: 238469.45
Esta nota inicia um grande
série de artigos sobre backup
- Backup, parte 1: Por que o backup é necessário, uma visão geral dos métodos, tecnologias
- Parte 2 do backup: revisando e testando ferramentas de backup baseadas em rsync
- Parte 3 do backup: revisando e testando duplicidade, duplicação, deja dup
- Backup Parte 4: Revendo e testando zbackup, restic, borgbackup
- Backup Parte 5: Testando bacula e backup veeam para linux
- Backup Parte 6: Comparando ferramentas de backup
- Backup Parte 7: Conclusões
Fonte: habr.com