Cópia de segurança do LitArbi Server no Amazon S3, passo a passo

Antes de começar

Precisa de três coisas: uma conta da Amazon Web Services em que possa iniciar sessão como administrador, uma conta de administrador no seu LitArbi Server e um local seguro para o kit de cópia de segurança — o gestor de palavras-passe da sociedade, ou uma impressora e um cofre. Reserve 20 minutos; depois, a primeira cópia faz-se sozinha.

As designações da AWS abaixo são as da consola em inglês; o idioma muda-se nas definições da consola (ícone da roda dentada, em cima). Criará cinco coisas, por esta ordem:

Tudo o que o servidor envia é encriptado antes de sair dele, com uma chave que só a sua sociedade tem. A Amazon guarda dados que não consegue ler; o LitArbi também não.

Custos. A Amazon cobra alguns cêntimos por gigabyte por mês pelo armazenamento em Francoforte, mais montantes mínimos por pedido. Um servidor com 20 GB de documentos custa bem menos de um euro por mês.

Passo 1 — Criar o bucket

1. Inicie sessão na AWS Management Console. No menu de regiões, em cima à direita, escolha Europe (Frankfurt) eu-central-1 — ou outra região da UE; anote qual.
2. Abra o S3 (escreva «S3» na pesquisa) e clique em Create bucket.
3. Bucket type: General purpose. Bucket name: um nome único, por exemplo litarbi-backup-suasociedade — minúsculas, algarismos e hífenes; o nome não pode estar ocupado em nenhum lugar da AWS.
4. Mantenha os valores predefinidos: ACLs disabled, Block all public access assinalado, encriptação predefinida SSE-S3.
5. Abra Advanced settings. Em Object Lock escolha Enable e assinale a caixa que confirma que os objetos podem ser bloqueados de forma permanente. O controlo de versões é ativado com ele.
6. Clique em Create bucket.

O Object Lock só pode ser ativado agora, ao criar o bucket — e nunca mais se desativa. A AWS sugere depois uma «default retention»: ignore-a. O LitArbi bloqueia cada ficheiro por si, durante os dias que indicar no passo 5.

Passo 2 — A regra de limpeza

O Object Lock precisa do controlo de versões e, com ele, apagar um ficheiro apenas o oculta. Quando o LitArbi retira um ponto de restauro antigo, a regra elimina definitivamente a cópia oculta 30 dias depois.

1. Abra o novo bucket, separador 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 assinale a confirmação.
3. Em Lifecycle rule actions assinale Permanently delete noncurrent versions of objects e Delete expired object delete markers or incomplete multipart uploads.
4. Days after objects become noncurrent: 30. Deixe vazio «Number of newer versions to retain».
5. Assinale Delete expired object delete markers e Delete incomplete multipart uploads, Number of days: 7.
6. Clique em Create rule.

Não assinale «Expire current versions of objects»: apagaria as próprias cópias de segurança.

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

1. Abra o IAM (escreva «IAM» na pesquisa), depois Policies e Create policy.
2. Mude o editor de Visual para JSON, selecione tudo e substitua-o pela política abaixo. Coloque o nome do seu bucket nos dois sítios onde diz 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 ficheiros atuais desse único bucket. Não pode eliminar versões antigas — s3:DeleteObjectVersion falta de propósito. Quem se apoderar do servidor só pode ocultar ficheiros, nunca destruí-los; as cópias ocultas continuam recuperáveis durante 30 dias.

Se o editor duplicar chavetas ou aspas enquanto escreve, cole a política em vez de a escrever.

Passo 4 — O utilizador do servidor e a respetiva chave de acesso

1. No IAM abra Users e clique em Create user. User name: litarbi-server-backup. Não assinale o acesso à consola. Next.
2. Permissions options: Attach policies directly. Procure LitArbiServerBackup, assinale-a, Next e depois Create user.
3. Abra o novo utilizador, separador Security credentials, e em Access keys clique em Create access key.
4. Caso de utilização: Application running outside AWS. Next, se quiser a descrição «LitArbi Server», e Create access key.
5. A AWS mostra a Access key (começa por AKIA) e a Secret access key — o segredo apenas desta vez. Deixe a página aberta para o passo 5.

Perdeu o segredo? Elimine a chave de acesso, crie outra e introduza 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; as designações estão em inglês.

1 · Backup key

Clique em Create the backup key. A página mostra o kit de cópia de segurança uma única vez: uma chave LABK-… e a respetiva impressão digital. Imprima-o ou guarde-o no gestor de palavras-passe da sociedade, 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 as consegue abrir — nem a sua sociedade, nem o seu fornecedor de alojamento, nem a Amazon, nem o LitArbi.

2 · Backup place

Escolha S3-compatible storage e preencha:

Confirme com a sua própria palavra-passe do LitArbi e clique em Test and save. O servidor grava, lê e apaga primeiro um ficheiro de teste, pelo que um erro aparece de imediato (ver «Se algo correr mal» mais abaixo). Os dados de acesso são guardados encriptados no servidor.

3 · Keep restore points for

14 dias, 8 semanas e 12 meses é um bom começo: guarda-se o ponto de restauro mais recente de cada dia, semana e mês. Os deveres profissionais de conservação 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 que funciona

• Na página Backups, Last backup mostra a data de hoje e At the backup place o seu bucket com «Object Lock 30 days».
• O resumo já não avisa que não há cópias de segurança configuradas.
• Introduza a chave do seu kit em Check the kit. Abre uma vez o ponto de restauro mais recente e não é guardada — a prova de que o kit funciona antes de precisar dele.
• Check the backups compara o ponto de restauro mais recente com o que foi enviado; o servidor repete-o sozinho todas as semanas.

A cópia faz-se em segundo plano, em pequenas etapas, enquanto o LitArbi está a ser utilizado. Se o seu alojamento oferecer tarefas cron, é mais fiável iniciá-la todas as noites a uma hora fixa — o guia de instalação que acompanha o servidor indica a linha.

Se algo correr mal

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

Outros fornecedores 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, contam três coisas:

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