Backup incremental de aplicação

Artigo originalmente publicado em http://getupcloud.com/blog/backup-incremental-de-aplicacao

 

Neste artigo mostro como podemos criar um mecanismo de backup incremental para suas aplicações, usando o rhc e um simples script agendado na cron.

Antes de mais nada, certifique-se de que seu RHC está devidamente atualizado.

$ sudo gem update rhc

Caso não tenha o RHC instalado, veja aqui como instalá-lo em diversos sistemas.

Snapshot

O comando rhc snapshot save|restore é usado para criar, baixar e restaurar snapshots de suas aplicações. Cada snapshot contém:

  • Repositório git com o código executável da aplicação e dos cartridges instalados
  • Variáveis de ambiente
  • Arquivos de log do gear
  • Conteúdo do diretório local do gear ($OPENSHIFT_DATA_DIR)
  • Dump completo do banco, caso a aplicação possua banco instalado

Com ele, podemos montar um mecanismo de backup incremental, ou seja, apenas com as diferenças entre os snapshots. Assim economizamos espaço em disco e temos maior controle no momento de restauração. Para este artigo vamos utilizar o código em https://github.com/caruccio/openshift-backup.
Baixe-o com o comando:

$ git clone https://github.com/caruccio/openshift-backup.git
$ cd openshift-backup/

Autorizando automaticamente os hosts de suas aplicações

Esta etapa é opcional, mas facilita no momento em que novas aplicações são criadas e usadas para backup. O comando snapshot utiliza uma conexão ssh para fazer seu trabalho. Em função disso é necessário autorizar o servidor ssh na primeira vez que este é acessado. Inclua a linha abaixo em seu arquivo ~/.ssh/config.

Host *.getup.io
   StrictHostKeyChecking no

Agora qualquer host com sufixo .getup.io será automaticamente considerado confiável, evitando que o comando rhc bloqueie com um pedido de autorização.

Gerando o token de autorização

Precisamos de um token de autorização para executar o snapshot. Fazemos isso através do comando rhc authorization. O ideal é que possamos configurar apenas uma vez o mecanismo de backup e deixar que ele execute automaticamente até o fim dos tempos. No entanto, o sistema de autenticação do OpenShift exige que o token de autorização possua um período de validade. Na Getup configuramos o período máximo de 1 ano para tokens com permissão somente-leitura, utilizado por nosso backup. O inconveniente deste mecanismo é que precisamos atualizar o token antes do período de expiração. Do contrário o backup irá fallhar.

## Período de validade do token
$ MESES=12

## Cria token com nome "backup"
$ rhc authorization add --scopes read --note backup --expires-in $((60*60*24*30*$MESES))
Adding authorization ... done

backup
------
  Token:      6a73b511f426af1aa2834470469f0a0f776b11b888f483e81f8acacc7dc02cde
  Scopes:     read
  Created:    10:04 AM
  Expires In: about 12 months

Agora, copie o valor do token (6a73b511f426af1aa2834470469f0a0f776b11b888f483e81f8acacc7dc02cde) para o arquivo /etc/rhc-auth-token. Este arquivo é lido pelo script de backup e usado para autenticar.

$ sudo su -c "echo 6a73b511f426af1aa2834470469f0a0f776b11b888f483e81f8acacc7dc02cde > /etc/rhc-auth-token"

## Assegurar que apenas o root consiga ler o arquivo
$ sudo chmod 600 /etc/rhc-auth-token

Instalação

Antes de colocar em produção, precisamos testar o script. Instale-o em algum local do $PATH (/usr/sbin é um bom candidato).

$ sudo cp -i backup-app /usr/sbin/
$ sudo chmod +x backup-app
$ ./backup-app --dir=/tmp/backup-teste --all

Você pode especificar um ou mais nomes de aplicações para restringir o backup:

$ ./backup-app --dir=/tmp/backup-teste  blog site

Confira se foram criados os diretórios das aplicações em /tmp/backup-teste. A estrutura de diretórios do backup é a seguinte:

/tmp/backup-teste/              <== Diretório raiz
       |
       +-- app1/                <== Diretório do app1
       |     |
       |     +-- [GEAR-ID]/     <== Diretório do Gear
      ...
       |
       +-- appN/                <== Diretório do appN
             |
             +-- [GEAR-ID]/     <== Diretório do Gear

A opçao --list apresenta algumas informações úteis sobre o backup:

$ ./backup-app -l -d=/tmp/backup
App        Gear-Id                     Commit     Ultimo Backup
---        -------                     ------     -------------
app1       52319ea699fc7754b0000211    27a2052    2013-09-12 09:49:16 -0300 (5 hours ago)
site       5231a85799fc7754b0000253    63adceb    2013-09-12 14:31:06 -0300 (5 minutes ago)
blog       517207f6851943c93d000015    9ea0720    2013-09-12 09:52:12 -0300 (5 hours ago)
jenkins    5231aa9699fc771194000028    a7629c6    2013-09-12 09:54:44 -0300 (5 hours ago)

Para inspecionar cada backup podemos usar o comando git:

$ cd /tmp/backup-teste/site/5231a85799fc7754b0000253
$ git log
commit 63adceb3f3a7990af8dc4dad269df4e4221d73a8
Author: Mateus Caruccio <mateus@caruccio.com>
Date:   Thu Sep 12 14:31:06 2013 -0300

    Backup automatico: site - Thu Sep 12 14:30:24 BRT 2013

Conclusões

É muito simples utilizar o rhc para criar um sistema de backup. Contudo, ainda existe espaço para melhorias, como transferir apenas a diferença entre os snapshots - atualmente o snapshot transferido do gear é completo. Se você tem algum dica, jogue ali nos comentários ou envie-me um PR.

Tem mais dúvidas? Envie uma solicitação

0 Comentários

Por favor, entre para comentar.
Powered by Zendesk