Escolher um backup confiável e restaurar o site

Introdução

Uma pequena loja usa um serviço de pedidos para relacionar clientes, produtos e quantidades. Após um incidente preparado, dois pedidos estão ausentes. Sua tarefa é recuperar os dados necessários sem substituir o catálogo público independente. Todas as pessoas e registros são sintéticos; não há malware.

Um backup é uma cópia para recuperação. Um arquivo agrupa arquivos individuais e uma soma de verificação resume seus bytes. Você aprenderá por que a soma só ajuda quando a referência é confiável e restaurará um banco SQLite real usando uma área de preparação. Este é um exercício limitado de recuperação, não um procedimento completo de resposta a incidentes.

Basta saber digitar comandos e trocar de aba. Workstation e App Server são sessões distintas do mesmo host, com diretórios iniciais diferentes; não são máquinas separadas. Use Order Service para a página no navegador.

Preservar os dados danificados do serviço

Nesta etapa, você entenderá os dados de negócio ausentes e preservará uma cópia de reversão antes de modificar o serviço.

Abra Order Service. Normalmente, cada linha relaciona um número de pedido a cliente, status, produto e quantidade. O ponto de recuperação necessário contém estes três pedidos:

Agora só aparece 4101. Clique em Public catalog: canecas, cadernos e bolsas ainda devem estar listados. Esse upload é independente do banco e deve sobreviver à recuperação. Depois volte à página de pedidos.

Uma API é a interface do serviço para programas. Em Workstation, curl solicita a API; -f trata erros do servidor como falhas, -s oculta o progresso e -S continua mostrando erros. 127.0.0.1 indica este mesmo host e 8080 é a porta do serviço.

curl -fsS http://127.0.0.1:8080/api/orders

O resultado é um array JSON, uma lista de linhas entre colchetes. Só existe a linha de Mina. Uma solicitação bem-sucedida não significa que os dados estejam completos.

Mude para App Server. pwd mostra o diretório atual:

pwd

Espere /srv/order-service. SQLite guarda as tabelas em orders.db. Este serviço preparado não possui processos de escrita e reabre o banco a cada solicitação; copiá-lo é seguro aqui. Um banco de produção ativo precisa de um procedimento de backup consistente com a aplicação.

cp recebe a origem e depois o destino. Preserve o banco atual fora do diretório da aplicação para poder reverter uma restauração incorreta:

cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db

A ausência de saída normalmente indica que a cópia terminou. Não repita esse comando após restaurar: isso sobrescreveria a cópia de reversão com o banco recuperado. Você preservou o estado danificado; o serviço ainda precisa ser recuperado.

Selecionar um arquivo de recuperação confiável

Nesta etapa, você rejeitará bytes alterados e colocará o arquivo verificado adequado no diretório de preparação.

Mude para Workstation. cd muda de diretório e ls lista seu conteúdo. Um caminho absoluto começa com / e funciona independentemente do diretório atual.

cd /home/labex/project/recovery/backups

ls

Há três arquivos .tar.gz: tar agrupa arquivos e gzip os comprime. Os nomes descrevem horários de recuperação; o mais recente não é automaticamente seguro ou adequado.

cat exibe um arquivo de texto. Leia os pontos fornecidos separadamente pelo custodiante dos backups:

cat /opt/backup-custodian/recovery-points.txt

O arquivo 0800 é anterior aos pedidos 4102 e 4103. O 0900 inclui o ponto necessário. O candidato 1000 é posterior, mas ainda exige verificação de integridade.

Integridade significa que os bytes não mudaram em relação a uma referência. SHA-256 produz um resumo para comparação. O manifesto do custodiante pertence a root e está fora da pasta de recuperação normalmente editável. O cenário pressupõe entrega por um canal independente protegido; assinaturas e distribuição de chaves não são ensinadas. O administrador pode superar a propriedade local; portanto, este host didático não é uma âncora de confiança inviolável.

sha256sum -c lê pares de nomes e resumos e compara os arquivos no diretório atual. Use o manifesto independente:

sha256sum -c /opt/backup-custodian/SHA256SUMS

0800 e 0900 devem indicar OK, e 1000, FAILED. O código diferente de zero e o aviso são intencionais: ao menos um arquivo mudou. Não extraia esse candidato.

O manifesto adjacente pode ser editado junto com os backups. Compare o resultado:

sha256sum -c SHA256SUMS

Os três indicam OK. Quem muda um arquivo pode substituir a soma ao lado dele. Coincidir com um resumo não confiável não demonstra autenticidade. O 0800 está intacto, mas faltam registros. Escolha 0900, pois está intacto e é adequado.

O diretório de preparação permite inspecionar os dados antes de tocar no serviço ativo. mkdir -p cria o diretório e aceita que já exista:

mkdir -p /home/labex/project/recovery/stage

Copie o candidato verificado para lá:

cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz

Se digitar a origem incorretamente, cp dirá que não encontra o arquivo; use ls e tente de novo. A verificação examina os bytes reais do arquivo preparado, não uma declaração escrita de que foram verificados.

Inspecionar o banco na preparação

Nesta etapa, você examinará os membros do arquivo, extrairá o único arquivo esperado e lerá o banco preparado sem modificá-lo.

Em Workstation, entre na preparação:

cd /home/labex/project/recovery/stage

tar -tvzf lista um arquivo gzip: t lista, v inclui tipo e permissões, z indica gzip e f nomeia o arquivo. Listar não extrai nada.

tar -tvzf orders-0900.tar.gz

O único membro deve ser orders.db, com o campo de permissões iniciado por -, indicando arquivo regular. Pare se houver caminhos absolutos, componentes .., links ou arquivos inesperados. Inspecionar os nomes ajuda aqui porque este arquivo didático confiável contém um arquivo regular; isso não é uma política completa de extração segura para arquivos arbitrários. Nunca execute programas de um backup suspeito.

Para extrair, use x em vez de t e omita o detalhamento v. O orders.db final restringe a extração a esse membro; --no-same-owner mantém sua própria propriedade:

tar -xzf orders-0900.tar.gz --no-same-owner orders.db

SQLite armazena tabelas relacionadas em um arquivo. A ferramenta preparada db-view abre o banco somente para leitura, verifica consistência interna e relacionamentos e imprime as linhas de negócio unidas. Você não precisa escrever SQL ou editar o banco. Informe o caminho preparado:

/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db

Espere Integrity: ok, Relationships: ok e os três pedidos. Um banco válido ainda pode representar o ponto errado; compare também clientes, status e quantidades com a etapa 1.

Um caminho errado causa erro em vez de criar um banco vazio. Confira pwd e ls e tente novamente. Se os dados diferirem, volte ao manifesto independente e selecione o arquivo correto antes de extrair outra vez. O site continua danificado: a preparação sozinha não restaura a aplicação.

Restaurar e testar o serviço ativo

Nesta etapa, você substituirá somente o banco designado e confirmará a recuperação com solicitações reais, preservando o upload público.

Mude para App Server. A cópia de reversão está fora deste diretório e o banco preparado passou pela inspeção. Copie apenas esse banco para o caminho de dados designado:

cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db

Origem e destino são arquivos diferentes. Evite copiar todo o diretório preparado sobre /srv/order-service: ali há uploads independentes que precisam permanecer intactos. Não é necessário reiniciar o daemon porque esta aplicação preparada somente para leitura fecha o banco após cada solicitação. Outras aplicações podem exigir manutenção ou reinício documentado.

Consulte a aplicação em vez de depender da presença de um backup ou arquivo de texto restored:

curl -fsS http://127.0.0.1:8080/api/orders

Espere 4101, 4102 e 4103, com clientes corretos, status packed e quantidades 1, 2, 3. Abra Order Service e atualize a página: a tabela deve mostrar os mesmos registros.

Confira também o upload público independente:

curl -fsS http://127.0.0.1:8080/uploads/catalog.txt

Public catalog: mugs, notebooks, tote bags

Clique em Public catalog no navegador e confirme o mesmo conteúdo. Recuperar significa devolver os dados necessários e preservar o funcionamento normal independente.

Se aparecer Database unavailable, inspecione novamente o banco preparado e repita a cópia de arquivo único com caminhos absolutos corretos. Para voltar ao estado danificado original enquanto investiga um erro, use a cópia preservada:

cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db

O último comando desfaz a recuperação intencionalmente. Se usá-lo, repita a cópia do banco preparado verificado para o caminho ativo antes de concluir. Guarde o arquivo de reversão para revisão posterior.

Resumo

Você preservou uma cópia de reversão, comparou bytes com um manifesto independente confiável, escolheu um ponto adequado e inspecionou um banco SQLite preparado. Depois restaurou o serviço real e conferiu relacionamentos e um upload independente. Recente, intacto e adequado são propriedades distintas; uma recuperação segura precisa combiná-las corretamente.