Módulo 8 · 8.1

Um plano de cópias de segurança para o seu servidor

Módulo 8: Cópias de segurança e monitorização · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: No final desta lição, saberá criar um plano de cópias de segurança para o seu próprio servidor: o que guarda, onde, com que frequência e durante quanto tempo, e como garante que a reposição funciona.

Conceitos-chave: regra 3-2-1, snapshot, cópia de segurança do fornecedor, cópia de segurança própria fora do fornecedor, RPO, RTO, dump da base de dados (mariadb-dump, pg_dump), configuração em /etc, volumes Docker, encriptação, ransomware, append-only, teste de reposição

Porquê um plano, e não "há uma cópia de segurança, não há?"

Quase todas as pessoas que perderam um servidor pensavam que havia uma cópia de segurança. Depois descobre-se que esta contém apenas o sistema operativo e não a base de dados, ou que está no mesmo servidor que entretanto desapareceu, ou que foi encriptada pelo mesmo ransomware, ou que ninguém sabe a palavra-passe. Uma cópia de segurança só tem valor se a conseguir repor. Por isso, começa-se com um plano e termina-se com um teste.

Um plano responde a cinco perguntas:

O que tem de poder ser reposto?
Quantos dados pode perder? (RPO)
Com que rapidez tem de voltar a funcionar? (RTO)
Onde estão as cópias, e quantas são?
Como sabe que funciona?

O que tem de poder ser reposto?

Um servidor é composto por camadas. Nem todas as camadas precisam de estar na cópia de segurança:

Camada	Exemplo	Cópia de segurança?
Sistema operativo e pacotes	Debian, nginx, PHP	Não necessariamente: pode ser reinstalado. Mas sim uma lista: `dpkg --get-selections`
Configuração	`/etc` (nginx, SSH, firewall, unidades systemd), os seus ficheiros compose	Sim, é pequena e indispensável
Aplicações e sites	`/var/www`, `/opt/<app>`, `/srv`	Sim, exceto se vierem do Git
Dados	bases de dados, carregamentos, volumes Docker (`/var/lib/docker/volumes`)	Sim, o mais importante
Segredos	palavras-passe, chaves de API, a própria chave da sua cópia de segurança	Sim, mas à parte e encriptados (ver abaixo)
Registos, caches, ficheiros temporários	`/var/log`, `/var/cache`, `/tmp`	Normalmente não

Preste especial atenção às bases de dados. Uma base de dados em execução está constantemente a escrever. Se copiar os ficheiros de um MariaDB ou PostgreSQL em execução, pode obter uma cópia danificada. Por isso, faça primeiro um dump: um instantâneo consistente em forma de ficheiro, que depois inclui na cópia de segurança.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump chamava-se antigamente mysqldump; esse comando normalmente ainda funciona.) Se a base de dados correr num contentor, faz o mesmo com docker compose exec (lição 9.4).

RPO e RTO: quanto pode perder?

Dois conceitos da prática profissional ajudam a tomar decisões:

RPO (recovery point objective): quanto tempo de dados pode perder, no máximo? Uma cópia de segurança diária às 03:00 significa: se o servidor falhar às 22:00, perde quase um dia. Para uma loja online com encomendas, é demasiado; para um blogue que muda uma vez por semana, é perfeitamente aceitável.
RTO (recovery time objective): quanto tempo pode demorar até tudo voltar a funcionar? Repor uma cópia de segurança completa do fornecedor pode levar minutos; montar um novo servidor e repor tudo manualmente pode levar horas.

Anote-os para o seu próprio servidor. Determinam com que frequência faz uma cópia de segurança e como a guarda.

Snapshot, cópia de segurança do fornecedor, cópia de segurança própria

Num VPS, tem normalmente três tipos de rede de segurança. São parecidos, mas protegem contra coisas diferentes.

1. O snapshot. Um instantâneo de todo o disco virtual, criado no painel do seu fornecedor. Rápido de criar, rápido de repor. Ideal imediatamente antes de uma atualização de versão (lição 4.3). Mas: na maioria dos fornecedores, um snapshot fica no mesmo armazenamento que o seu servidor. Se esse armazenamento avariar, ou se perder a sua conta, o snapshot também desaparece. E um snapshot não se guarda durante muito tempo: cresce com todas as alterações feitas depois. Um snapshot não é uma cópia de segurança.

2. A cópia de segurança do fornecedor. Muitos fornecedores fazem (eventualmente como opção) automaticamente, todos os dias, uma cópia de todo o seu servidor noutro armazenamento. Na WebOké, por exemplo, é uma cópia de segurança diária de todo o VPS, guardada durante sete dias; noutros fornecedores funciona de forma semelhante, com prazos próprios. É uma boa segunda camada contra hardware avariado e contra os seus próprios enganos de ontem. Mas continua a ser uma única entidade: a sua conta, o seu pagamento, a avaria deles. E a reposição é normalmente feita para o servidor inteiro de uma só vez.

3. A sua própria cópia de segurança, fora do fornecedor. Uma cópia dos seus dados noutra entidade ou noutro local, que o próprio cria e gere (lição 8.2). Esta é a camada que resta quando tudo o resto falha.

A regra 3-2-1

Uma regra prática comum:

3 cópias dos seus dados (o original mais duas cópias de segurança);
em 2 tipos diferentes de armazenamento ou sistemas;
das quais 1 noutro local.

Para um VPS, isso pode ser: os dados no servidor, a cópia de segurança diária do fornecedor e uma cópia de segurança própria encriptada com restic para um armazenamento noutra entidade. Um complemento moderno é que pelo menos uma cópia não possa ser apagada por quem assumir o controlo do servidor (offline, ou append-only, lição 8.2). O ransomware num servidor procura ativamente cópias de segurança para também as encriptar ou apagar. Uma cópia de segurança que o próprio servidor pode apagar não oferece proteção contra isso.

Encriptação e a palavra-passe da sua cópia de segurança

Uma cópia de segurança noutra entidade tem de estar encriptada: contém dados de clientes, palavras-passe e chaves. O restic (lição 8.2) encripta por predefinição. Mas isso cria um novo risco: a palavra-passe da sua cópia de segurança. Se a perder, a cópia de segurança fica inutilizável. E o mesmo acontece se ela estiver apenas no servidor que perdeu.

Por isso, guarde a palavra-passe também fora do servidor: no seu gestor de palavras-passe e, eventualmente, em papel num cofre. O mesmo se aplica aos dados de acesso do armazenamento onde está a sua cópia de segurança.

Testar a reposição

A parte mais importante do plano. Um teste de reposição significa: repõe efetivamente uma cópia de segurança, num local onde não estrague nada, e verifica se o resultado funciona.

Pequeno e frequente: repor um ficheiro ou uma pasta para /tmp/terug e comparar (diff). Por exemplo, mensalmente.
Grande e ocasional: montar um servidor de teste completamente novo a partir da cópia de segurança, importar a base de dados, iniciar o site. Por exemplo, uma vez por ano, ou a cada alteração importante. Este é também o ensaio para quando algo correr mesmo mal (lição 10.3).

Anote quanto tempo demorou: esse é o seu RTO real.

Prazos de conservação

Não guarde apenas a última cópia de segurança. Se só descobrir ao fim de duas semanas que um ficheiro foi danificado ou apagado, precisa de uma cópia de segurança de há três semanas. Um esquema comum: sete versões diárias, quatro semanais e seis mensais. O restic trata disso com forget (lição 8.2). Pense também no RGPD: os dados pessoais não devem ser guardados mais tempo do que o necessário, nem mesmo em cópias de segurança. Registe os seus prazos de conservação.

Na prática

Utilize o snapshot do seu fornecedor imediatamente antes de alterações arriscadas e elimine-o depois; mantenha ativa a cópia de segurança diária do fornecedor, se existir; e, além disso, faça a sua própria cópia de segurança encriptada dos dados e da configuração para outra entidade. Na WebOké, isto chama-se Snapshots e Backups no ecrã do VPS; noutros fornecedores, os nomes e os prazos são diferentes, mas o princípio é o mesmo. Um pacote de alojamento ou um serviço gerido tem muitas vezes outros acordos: verifique o que está previsto no seu caso.

Resumo

Uma cópia de segurança só tem valor se a reposição funcionar; comece com um plano e termine com um teste.
Faça sobretudo cópia de segurança dos dados e da configuração: bases de dados como dump, /etc, sites, volumes Docker, ficheiros compose.
Defina o RPO (quanto pode perder) e o RTO (com que rapidez tem de funcionar).
O snapshot (mesmo armazenamento, curto prazo), a cópia de segurança do fornecedor (outro armazenamento, mesma entidade) e uma cópia de segurança própria fora do fornecedor são três camadas diferentes; siga a regra 3-2-1 com pelo menos uma cópia que o próprio servidor não consiga apagar.
Encripte, guarde a palavra-passe da cópia de segurança fora do servidor e teste a reposição: em pequeno e com frequência, em grande de vez em quando.

Questionário

Exercício

Exercício O8.1: O seu plano de cópias de segurança. Crie para o seu próprio servidor um plano de cópias de segurança numa só página: o que tem de poder ser reposto (por camada), o seu RPO e RTO, que cópias tem (snapshot, fornecedor, própria) e onde, os seus prazos de conservação, onde está a palavra-passe da cópia de segurança e quando faz um teste de reposição. Preencha o formulário; depois de o enviar, verá um plano de exemplo para comparar com o seu.

Exercício O8.1: O seu plano de cópias de segurança

Este exercício faz você mesmo; ninguém o verifica. Assinale o que já fez e marque o exercício como concluído.

Definido por camada o que guardo: configuração, sites, bases de dados, volumes, segredos
RPO e RTO definidos
Uma cópia num fornecedor diferente do do servidor
Períodos de retenção escolhidos
Sei onde está a palavra-passe das cópias de segurança
Existe uma cópia que o próprio servidor não consegue apagar

Como guarda as suas bases de dados?

Onde estão as suas cópias, e em que fornecedor?

Quando e como testa a reposição?

As suas marcações e notas ficam apenas neste navegador; não as enviamos para lado nenhum. Se tiver sessão iniciada, guardamos em Os meus cursos apenas que concluiu o exercício.

Cookies na WebOké

Definições de cookies

Necessários

Marketing