Cópia de segurança e reposição

A aplicação chama-se «Ticket System Backup & Restore». Fica ao lado do sistema de tickets e tem o seu próprio atalho no ambiente de trabalho.

Há uma versão para Windows e uma para Linux. É a mesma aplicação, apenas construída para cada sistema operativo.

Tem seis separadores. «Restore» lista as cópias que tens, «Create Backup» faz uma nova, «Schedule» trata dos horários, «Encryption» mostra a chave de recuperação, «Settings» mostra os caminhos e «Log» o protocolo.

As definições já vêm preenchidas. No primeiro arranque, a aplicação descobre sozinha onde está o sistema de tickets.

A pasta das cópias está em «Backup directory». Podes alterá-la, por exemplo para outra unidade.

No Windows, a aplicação pede direitos de administrador ao arrancar. As definições dela valem para todos os administradores do computador e estão em «%ProgramData%\SMITEY\backup-app».

A instalação configura sozinha a cópia diária. Corre às 23:00 no fuso horário do sistema de tickets.

O horário vive no sistema operativo. No Windows é o Agendador de Tarefas, no Linux o serviço cron. Assim não há um serviço extra a correr só para as cópias.

A cópia não precisa de ninguém com sessão iniciada. Num servidor onde nunca ninguém entra, corre na mesma.

A linha por baixo dos botões diz-te se a tarefa existe mesmo no sistema operativo. Uma caixa assinalada diz apenas o que foi guardado.

As cópias são mantidas em cinco escalões: 14 dias, 4 semanas, 12 meses, 4 trimestres e 5 anos. Uma cópia fica enquanto for a mais recente do seu período num desses escalões.

O que conta são dias de calendário, não ficheiros. Duas cópias no mesmo dia são um dia.

As cópias que crias à mão nunca são apagadas automaticamente. É isso que significa o 0 em «Keep manual».

Se alterares o horário, a tua alteração sobrevive a uma atualização. A instalação só o define se nunca tiveres definido um horário. Se desligaste a cópia de segurança, ela continua desligada. «Remove all scheduled tasks» também perdura: uma atualização não volta a criar o horário depois.

Uma cópia de segurança contém tudo o que forma o estado do teu sistema. Ou seja, a base de dados, os ficheiros anexos, o arquivo e as chaves. Só falta uma base de dados fora do SMITEY.

As chaves são a parte que passa facilmente despercebida. Decifram as credenciais guardadas, por exemplo as da tua conta de correio. Sem elas, uma reposição voltaria com credenciais mortas.

Cada cópia nova é um único ficheiro cifrado que termina em «.smbk». Contém um ficheiro por volume, uma lista do conteúdo e, se estiver incluída, a base de dados como ficheiro de texto.

O sistema continua a funcionar enquanto isto acontece. Os teus agentes nem dão pela cópia.

«Estimate size» diz-te à partida qual o tamanho da base de dados. Os volumes com os anexos somam-se a isso. A cópia não é comprimida.

Nunca se sobrescreve nada. Cada cópia é um ficheiro próprio, e só a limpeza remove as antigas.

Só os administradores podem ler as cópias de segurança. O mesmo vale para o ficheiro de configuração e para o ficheiro com o primeiro início de sessão na pasta de instalação. O instalador e cada atualização definem estas permissões automaticamente.

Se a tua base de dados correr num servidor próprio e não no contentor do SMITEY, a aplicação não consegue fazer a cópia dela. Faz então a cópia com as tuas próprias ferramentas. Nesse caso, a cópia contém só os anexos, os arquivos e as chaves, cifrados como de costume. Uma atualização deteta sozinha uma base de dados dessas e reconfigura a aplicação. Até lá, a cópia diária falha numa instalação assim, a não ser que a reconfigures primeiro à mão. Na linha de comandos, também podes fazê-lo à mão com «config --database external». Com «config --database bundled» voltas atrás.

Cada cópia nova é cifrada. Isto vale para as cópias do horário, para as feitas à mão e para as feitas antes de uma atualização. Não tens de ligar nada.

As cópias são cifradas com AES-256. A instalação cria a chave sozinha. Numa instalação existente, ela é criada na primeira atualização para uma versão com cifra. Fica guardada no servidor, protegida. Só os administradores a podem ler.

Isto protege as cópias fora do servidor. Quem encontrar uma cópia numa unidade de rede, numa memória USB ou num armazenamento online não a consegue ler sem a chave. Quem controla o próprio servidor também tem a chave.

A chave de recuperação é a mesma chave numa forma que podes anotar. Começa por «SMBK-». Encontras a chave no separador «Encryption» e no ficheiro «SMITEY-credentials.txt» na pasta de instalação. Se apagaste esse ficheiro, a chave continua no separador «Encryption».

«Copy» põe a chave na área de transferência. «Save to file...» guarda-a num ficheiro de texto, com o ID da chave e a data. Guarda-o, por exemplo, num gestor de palavras-passe ou em papel num cofre.

Enquanto não confirmares que a chave está guardada, a aplicação mostra uma barra amarela no topo. Para confirmar, clica em «I stored the key outside this server» e responde «Yes» à pergunta. A barra desaparece. O separador mostra depois quando confirmaste.

O ID da chave diz-te a que servidor pertence uma cópia. Se uma cópia não pertencer a este servidor, a aplicação indica o ID da chave dela. Depois pede a chave de recuperação correspondente.

Se a aplicação não conseguir ler a chave, não faz cópia nenhuma. Também não faz uma cópia sem cifra. Nesse caso, o separador «Encryption» diz que a chave não pode ser lida. Se o ficheiro da chave faltar de todo, a cópia seguinte cria uma chave nova. A barra amarela volta a aparecer, porque também é preciso guardar a chave nova. As cópias mais antigas continuam a abrir-se só com a chave de recuperação antiga.

As cópias mais antigas em formato ZIP não estão cifradas. Ainda as podes repor. O separador mostra quantas são. A limpeza remove-as pelas mesmas regras que qualquer outra cópia.

Num servidor sem ambiente de trabalho, «key --show» mostra o mesmo na linha de comandos.

No separador «Restore» escolhes a cópia que queres de volta. Depois carregas em «Restore».

A aplicação pergunta primeiro. Diz o que vai acontecer: o estado de hoje é substituído e a aplicação reinicia os contentores. Se houver pessoas anonimizadas no estado de hoje, segue-se uma segunda pergunta. Indica quantas são e pergunta se devem voltar a ser anonimizadas depois da reposição. «Yes» está pré-selecionado. Com «No», a cópia é reposta sem este passo. Se em vez disso fechares a janela, nada é reposto.

O visto «Wipe target volumes before restore» esvazia primeiro os volumes. Assim não fica para trás nenhum ficheiro que não existisse quando a cópia foi feita.

Os passos aparecem no separador «Log». Aí vês um a um o que a aplicação fez. Se respondeste «Yes» à segunda pergunta, uma linha no fim diz quantas anonimizações o sistema de tickets volta a aplicar na noite seguinte. Se não for possível transferi-las, o registo mostra em vez disso um aviso. Se houve avisos, a linha de estado no fundo da janela indica quantos.

Se a cópia contiver a base de dados, volta o estado completo. Os tickets, os comentários, o histórico, os ficheiros anexos, o tempo registado e a base de conhecimento estão todos lá outra vez, tal como estavam no momento da cópia.

Depois disso o sistema volta a estar utilizável. Numa instalação pequena isto demora menos de um minuto.

Se a cópia contiver a base de dados, ela volta completa ou não volta. Os volumes seguem-se depois. Se um volume falhar, a base de dados já voltou, mas podem faltar ficheiros; o separador «Log» mostra que passo falhou. Em todos os casos, a aplicação volta a arrancar os contentores depois, mesmo que a reposição tenha falhado.

Uma cópia de segurança de uma versão mais antiga pode ser reposta numa mais recente. No arranque seguinte, o sistema atualiza a base de dados para a sua própria versão.

Os consentimentos e os cancelamentos da subscrição do inquérito de satisfação são transferidos sem perguntar. Isto vale também se responderes «No» à segunda pergunta. A aplicação lê-os da instalação em execução antes da restauração. Depois, uma linha no separador «Log» indica o número, por exemplo «12 consent and unsubscribe record(s) were carried over.» O sistema de tickets assume-os no primeiro arranque. Um consentimento ou um cancelamento da subscrição feito depois da cópia de segurança continua, por isso, válido. Se a transferência falhar, o registo mostra um aviso. A restauração conta na mesma como bem-sucedida.

A aplicação verifica primeiro por completo uma cópia cifrada. Entretanto, a linha de estado diz «Checking the encrypted backup before anything is changed...». Só depois pára os contentores. Se o ficheiro estiver danificado ou tiver sido alterado, pára e comunica «The backup file is damaged. Nothing was changed.»

Se a cópia vier de outro servidor, a aplicação pede a chave de recuperação desse servidor. Isto acontece depois das perguntas. A janela «Recovery key needed» indica o ID da chave da cópia. A mesma janela aparece se faltar a chave deste servidor.

Um erro de escrita é detetado antes de se alterar o que quer que seja. A linha de estado comunica então «The recovery key has a typing error. Check each character.» Depois a janela pergunta de novo. Se a chave pertencer a outra cópia, a linha de estado comunica «This recovery key does not belong to this backup.» Com «Cancel», a aplicação pára e comunica «Restore cancelled. Nothing was changed.»

A aplicação não adota a chave que introduziste. Mantém a sua. As cópias novas continuam a ser feitas com a chave deste servidor. Se repuseres num servidor novo, guarda também a chave de recuperação desse servidor.

Uma cópia sem base de dados repõe só os anexos, os arquivos e as chaves. As chaves existentes mantêm-se. A base de dados fica como está. A aplicação avisa disso antes da reposição e pergunta. Com «No» nada é alterado.

Se a instalação estiver configurada com uma base de dados própria, a aplicação ignora a parte da base de dados mesmo quando a cópia contém uma base de dados. Isto acontece, por exemplo, com uma cópia mais antiga. A aplicação pergunta antes. Com «No» nada é alterado.

Muitas vezes um servidor não tem ambiente de trabalho. Por isso a mesma aplicação também funciona como comando.

No dia a dia precisas de cinco comandos: «backup» guarda, «list» mostra as cópias que tens, «restore» traz uma de volta, «schedule» define o horário e «config» mostra as definições. Para a chave, juntam-se «key» e «decrypt».

Por trás deles está a mesma aplicação da janela. Não há um segundo caminho que faça outra coisa.

A aplicação está em «/opt/smitey/Backup». Chama-la com «sudo» e acrescentas o comando. Os contentores correm como «root», por isso a cópia também precisa desses direitos.

Podes copiar as seis caixas abaixo. Cobrem o que é mesmo preciso no dia a dia.

Também aqui a reposição pergunta. Só corre quando acrescentas «--yes». Transfere então também as anonimizações do estado de hoje, tal como «Yes» na janela. Com «--no-reapply», corre sem este passo.

Há um ficheiro no servidor para leres tudo isto. Chama-se «BACKUP-RESTORE.txt» e está em «/opt/smitey». Percorre o horário, todos os comandos e o caminho de volta mais uma vez, ao teu ritmo. Existe em alemão e em inglês: se escolheste alemão durante a instalação, recebes a versão alemã; caso contrário, a inglesa. As duas versões estão também em «/opt/smitey/docs».

«key --show» mostra a chave de recuperação, o ID da chave e o número de cópias sem cifra. Quando a chave estiver guardada fora do servidor, confirmas isso com «key --confirm-stored».

Uma cópia de outro servidor repões com «--key-file». O ficheiro que indicas contém a chave de recuperação. O ficheiro de «Save to file...» também serve para isto. Em vez do ficheiro, podes usar a variável de ambiente «SMITEY_BACKUP_KEY». Com «sudo» colocas a variável logo antes do programa, ou seja, «sudo SMITEY_BACKUP_KEY=<chave> /opt/smitey/Backup/TicketSystemBackup restore …». A chave fica então no histórico da shell. Se a chave não corresponder, nada é alterado.

«decrypt» escreve o conteúdo de uma cópia como ficheiros não cifrados numa pasta vazia. Estes ficheiros não estão cifrados. Contêm palavras-passe e dados pessoais. Apaga-os assim que acabares.

As cópias são ficheiros na pasta que definiste. Essa pasta está na mesma máquina que o sistema de tickets.

Para os casos mais comuns isso funciona bem. Dados apagados por engano, uma atualização que correu mal ou um erro nos dados estão todos cobertos.

Não ajuda contra a avaria do disco. Se o disco desaparecer, as cópias desaparecem com ele.

Por isso, copia os ficheiros para outro sítio. Uma unidade de rede, um segundo servidor ou um armazenamento na rede são suficientes.

Um ficheiro copiado pode ser recarregado em qualquer servidor. Num servidor diferente precisas para isso da chave de recuperação. Com «Import backup file…» trazes o ficheiro de volta à lista.

As cópias são cifradas. Ninguém as consegue ler sem a chave de recuperação. Por isso, não guardes a chave ao lado das cópias. As cópias mais antigas que terminam em «.zip» não estão cifradas.

Uma atualização faz antes uma cópia própria. Isso acontece independentemente do teu horário e sem teres de assinalar nada.

Guarda o mesmo de sempre: a base de dados, os anexos, os arquivos e as chaves. Se a base de dados correr fora do SMITEY, a atualização guarda só os anexos, os arquivos e as chaves.

Esta cópia é feita pela aplicação «Ticket System Backup & Restore». É cifrada como qualquer outra e fica na mesma pasta. Na lista, o seu tipo é «Update». As três cópias mais recentes deste tipo são mantidas. A aplicação apaga as mais antigas sozinha.

O aviso antes da atualização di-lo. Não tens de te lembrar de guardar primeiro.

Se esta cópia de segurança falhar, a atualização para antes de substituir o que quer que seja. Uma base de dados fora do SMITEY não atrasa a atualização. A atualização reconfigura então a aplicação para que a cópia diária também deixe a base de dados de fora. Faz a cópia desta base de dados com as tuas próprias ferramentas.