Pela tela de monitoramento de gestão da instância é possível realizar o backup dos dados da aplicação.

Executando o processo de backup de instância

Mais especificamente, ao ativar esta função, o autômato Doctor irá executar o serviço backup do stack de containers da instância. Para que o processo funcione corretamente, é necessário que um volume denominado backup esteja devidamente montado e que o serviço tenha sido devidamente implementado no arquivo de configuração do orquestrador.

Por exemplo, abaixo temos o serviço backup implementado no stack de uma aplicação WordPress:

backup:
  image: mariadb:latest
  restart: "no"
  environment:
    MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWD}
    MYSQL_DATABASE: pbc_portal
    MYSQL_USER: wordpress
    MYSQL_PASSWORD: ${DB_PASSWD}
  depends_on:
    - db
  links:
    - db
  volumes:
    - data_backup:/backup
    - data_wp:/var/www/html
  command: >
    sh -c  "set -ex &&
      export BACKUP_DIR=${COMPOSE_PROJECT_NAME}_${VERSION}_$$(date +'%Y-%m-%d_%H-%M-%S') &&
      cd /backup && mkdir $$BACKUP_DIR &&
      mysqldump --host db -uroot -p${DB_ROOT_PASSWD} pbc_portal > $$BACKUP_DIR/db.sql &&
      cp -R /var/www/html $$BACKUP_DIR/ &&
      tar -czf $$BACKUP_DIR.tar.gz $$BACKUP_DIR &&
      rm -rf /backup/$$BACKUP_DIR"
  profiles:
    - cli

Ao ser executado, o serviço backup precisa, necessariamente, gerar um arquivo .tar.gz no volume de backup. Todos os boilerplates já possuem uma implementação prévia do serviço.

Estando configurado corretamente, o serviço irá executar e, ao final, será enviado um e-mail aos mantenedores do projeto com um conteúdo semelhante ao abaixo:

INFO > Starting BACKUP proccess to build 'orcamento-forrageiro/site@alpha' (as requested by 'camilo.carromeu@embrapa.br')...
INFO > Trying to load '.embrapa/settings.json' from remote repository... done!
INFO > Trying to make backup of version '0.22.6-alpha.2' deployed as 'container' using orchestrator 'DockerCompose' at server 'cluster.sede.embrapa.br'!
INFO > Trying to clone app... done!
INFO > Checking SSH connection to host 'cluster.sede.embrapa.br'... ok!
INFO > Trying to execute backup service...
COMMAND > env $(cat .env.sh) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose build --force-rm --no-cache backup
COMMAND > env $(cat .env.sh) DOCKER_HOST="ssh://root@cluster.sede.embrapa.br" /usr/bin/docker-compose run --rm --no-deps backup
SUCCESS > The build was successfully backed up!
INFO > Providing access to maintainers in build backup folder...
INFO > Protecting build backup folder at 'http://backup.embrapa.io/orcamento-forrageiro' with a password... done!
SUCCESS > All done! Access backup files at 'http://backup.embrapa.io/orcamento-forrageiro' with user 'orcamento-forrageiro' and password '************'.
ATTENTION > All backup files are DELETED after ONE WEEK!

Na última linha podem ser vistas as instruções de acesso aos arquivos de backup. Em resumo, eles estarão disponíveis no servidor http://backup.embrapa.io, em uma pasta com o nome unix do projeto.

Atenção! A senha para acesso será alterada a cada nova execução do processo de backup.

Arquivos de backup da instância disponíveis para download

Atenção! Os arquivos gerados permanecerão disponíveis para download por uma semana (7 dias). Findando este prazo, são automaticamente apagados.

Backup de builds em produção

O backup sob demanda descrito acima e o backup diário feito pelo Releaser resolvem a cópia, mas não a guarda. Em ambos os casos o arquivo nasce no mesmo servidor em que a build roda (no cluster ou na VM dedicada), e um incidente nesse servidor, como falha de disco, ransomware ou exclusão acidental da VM, leva a aplicação e o backup juntos.

Atenção! Para builds em estágio release, a equipe do projeto (ou o NTI da Unidade) é responsável por levar os arquivos de backup para fora do servidor, seguindo a regra 3-2-1: três cópias, em dois tipos de mídia, uma delas fora do local. Na prática, isso significa um job que copia periodicamente o diretório de backups do Releaser para um storage de rede, um bucket de objetos ou o serviço de backup da Unidade, além de um teste periódico de restauração. A rotação de backups do Releaser controla apenas o que fica no servidor. Veja também o capítulo sobre publicação de aplicações.