Backup do LitArbi Server no Amazon S3, passo a passo

Antes de começar

Você precisa de três coisas: uma conta da Amazon Web Services na qual possa entrar como administrador, uma conta de administrador no seu LitArbi Server e um local seguro para o kit de backup — o gerenciador de senhas do escritório, ou uma impressora e um cofre. Reserve 20 minutos; depois, a primeira cópia é feita automaticamente.

Os nomes da AWS abaixo são os do console em inglês; o idioma pode ser alterado nas configurações do console (ícone de engrenagem, no alto). Você vai criar cinco coisas, nesta ordem:

Tudo o que o servidor envia é criptografado antes de sair dele, com uma chave que só seu escritório tem. A Amazon armazena dados que não consegue ler; o LitArbi também não.

Custos. A Amazon cobra alguns centavos de euro por gigabyte por mês pelo armazenamento em Frankfurt, mais valores mínimos por solicitação. Um servidor com 20 GB de documentos custa bem menos de um euro por mês.

Passo 1 — Criar o bucket

1. Entre no AWS Management Console. No menu de regiões, no canto superior direito, escolha Europe (Frankfurt) eu-central-1 — ou outra região da UE; anote qual escolheu.
2. Abra o S3 (digite “S3” na busca) e clique em Create bucket.
3. Bucket type: General purpose. Bucket name: um nome único, por exemplo litarbi-backup-seuescritorio — letras minúsculas, números e hífens; o nome não pode estar em uso em nenhum lugar da AWS.
4. Mantenha os valores padrão: ACLs disabled, Block all public access marcado, criptografia padrão SSE-S3.
5. Abra Advanced settings. Em Object Lock escolha Enable e marque a caixa que confirma que os objetos podem ser bloqueados de forma permanente. O controle de versões é ativado com ele.
6. Clique em Create bucket.

O Object Lock só pode ser ativado agora, ao criar o bucket — e não pode mais ser desativado. A AWS sugere depois uma “default retention”: ignore-a. O LitArbi bloqueia cada arquivo por você, pelo número de dias que você indicar no passo 5.

Passo 2 — A regra de limpeza

O Object Lock precisa do controle de versões e, com ele, apagar um arquivo apenas o oculta. Quando o LitArbi retira um ponto de restauração antigo, a regra apaga definitivamente a cópia oculta 30 dias depois.

1. Abra o novo bucket, aba Management, e clique em Create lifecycle rule.
2. Lifecycle rule name: litarbi-cleanup. Choose a rule scope: Apply to all objects in the bucket, e marque a confirmação.
3. Em Lifecycle rule actions marque Permanently delete noncurrent versions of objects e Delete expired object delete markers or incomplete multipart uploads.
4. Days after objects become noncurrent: 30. Deixe “Number of newer versions to retain” em branco.
5. Marque Delete expired object delete markers e Delete incomplete multipart uploads, Number of days: 7.
6. Clique em Create rule.

Não marque “Expire current versions of objects”: isso apagaria os próprios backups.

Passo 3 — A política: o que o servidor pode fazer

1. Abra o IAM (digite “IAM” na busca), depois Policies e Create policy.
2. Mude o editor de Visual para JSON, selecione tudo e substitua pela política abaixo. Coloque o nome do seu bucket nos dois lugares onde aparece litarbi-backup-yourfirm.
3. Clique em Next. Policy name: LitArbiServerBackup. Clique em Create policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheBackupBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::litarbi-backup-yourfirm"
    },
    {
      "Sid": "ReadWriteBackupFiles",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:PutObjectRetention", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::litarbi-backup-yourfirm/*"
    }
  ]
}

Com esta política, o servidor pode listar, ler, gravar e apagar os arquivos atuais desse único bucket. Não pode apagar versões antigas — s3:DeleteObjectVersion ficou de fora de propósito. Quem se apoderar do servidor só pode ocultar arquivos, nunca destruí-los; as cópias ocultas continuam recuperáveis por 30 dias.

Se o editor duplicar chaves ou aspas enquanto você digita, cole a política em vez de digitá-la.

Passo 4 — O usuário do servidor e a respectiva chave de acesso

1. No IAM abra Users e clique em Create user. User name: litarbi-server-backup. Não marque o acesso ao console. Next.
2. Permissions options: Attach policies directly. Procure LitArbiServerBackup, marque-a, Next e depois Create user.
3. Abra o novo usuário, aba Security credentials, e em Access keys clique em Create access key.
4. Caso de uso: Application running outside AWS. Next, opcionalmente a descrição “LitArbi Server”, e depois Create access key.
5. A AWS mostra a Access key (começa com AKIA) e a Secret access key — o segredo só aparece desta vez. Deixe a página aberta para o passo 5.

Perdeu o segredo? Apague a chave de acesso, crie outra e insira o novo par no LitArbi. Nada mais muda.

Passo 5 — A página Backups do LitArbi Server

No LitArbi Web abra Administration ▸ Backups. A página tem três partes numeradas; os nomes estão em inglês.

1 · Backup key

Clique em Create the backup key. A página mostra o kit de backup uma única vez: uma chave LABK-… e a respectiva impressão digital. Imprima-o ou guarde-o no gerenciador de senhas do escritório, separado do servidor, e certifique-se de que uma segunda pessoa sabe onde está. O servidor guarda apenas a metade pública: pode gravar cópias, mas nunca lê-las. Sem o kit, ninguém consegue abri-las — nem seu escritório, nem seu provedor de hospedagem, nem a Amazon, nem o LitArbi.

2 · Backup place

Escolha S3-compatible storage e preencha:

Confirme com sua própria senha do LitArbi e clique em Test and save. O servidor grava, lê e apaga primeiro um arquivo de teste, por isso um erro aparece na hora (veja “Se algo der errado” mais abaixo). Os dados de acesso ficam armazenados criptografados no servidor.

3 · Keep restore points for

14 dias, 8 semanas e 12 meses é um bom começo: fica guardado o ponto de restauração mais recente de cada dia, semana e mês. As obrigações profissionais de guarda de documentos podem exigir mais meses.

Por fim, clique em Back up now. A primeira cópia envia tudo e pode demorar — continua em segundo plano. As seguintes enviam apenas o que é novo.

Passo 6 — Verificar se funciona

• Na página Backups, Last backup mostra a data de hoje e At the backup place seu bucket com “Object Lock 30 days”.
• O resumo não avisa mais que não há backups configurados.
• Insira a chave do seu kit em Check the kit. A chave abre uma vez o ponto de restauração mais recente e não é armazenada — a prova de que o kit funciona antes de você precisar dele.
• Check the backups compara o ponto de restauração mais recente com o que foi enviado; o servidor repete essa verificação sozinho toda semana.

A cópia é feita em segundo plano, em pequenas etapas, enquanto o LitArbi está sendo usado. Se sua hospedagem oferecer tarefas cron, é mais confiável iniciá-la todas as noites em um horário fixo — o guia de instalação que acompanha o servidor indica a linha.

Se algo der errado

Se Test and save falhar, a página mostra o motivo indicado pela Amazon. Os mais comuns:

Outros provedores S3

Qualquer armazenamento compatível com S3 funciona da mesma forma — por exemplo Hetzner Object Storage, IONOS S3 Object Storage, Backblaze B2 ou Wasabi. Em todos, três coisas importam:

• Ativar o Object Lock (e com ele o controle de versões) ao criar o bucket, se o provedor oferecer.
• Criar uma chave de acesso limitada a esse único bucket, se o provedor permitir.
• Obter o endpoint e a região na documentação do provedor e inseri-los no passo 5.