Adicionando documentacao sobre backups

3 files changed, 151 insertions, 0 deletions

diff --git a/backup/concepts.mdwn b/backup/concepts.mdwn
new file mode 100644
index 0000000..07c98f9
--- /dev/null
+++ b/backup/concepts.mdwn
@@ -0,0 +1,32 @@
+Da natureza dos backups 
+=======================
+
+Um backup pode ser entendido como qualquer cópia feita para assegurar a existência de uma informação ou configuração em virtude da falta de garantia de que seu "suporte" físico consiga mantê-la.
+
+Podemos fazer uma analogia bem limitada com uma floresta com espécies endêmicas: se ocorrer uma queimada, as espécies se perdem a não ser que exista um banco de sementes intacto que permita o plantio das espécies ameaçadas.
+
+Esse exemplo da floresta é limitado porque no caso de um backup de dados digitais a informação se preserva ao transportá-la para outro suporte físico (isto é, configurar o conjunto de estados possíveis do "suporte" físico, por exemplo disco rígido, DVD, pendrive, de modo a reproduzir uma dada configuração presente anteriormente num outro suporte físico: o backup é a reprodução de um conjunto de estados de um sistema), o que não ocorre num reflorestamento.
+
+Guardar TODA informação existente em uma floresta, numa vizinhança ou mesmo na memória de um povo é uma tarefa inatingível, o que faz qualquer floresta, qualquer vizinhança ou povo insubstituíveis. Vejamos a cultura: ela se reproduz e contamina, quase sempre com mutações...
+
+Nesse sentido, backups de dados digitais são tarefas bem mais simples e possíveis, porque os temos e os conseguimos copiá-los com exatidão. Não há uma receita única para fazer um backup digital: a simples cópia de um arquivo de um suporte a outro já pode ser considerado como um backup.
+Parâmetros dos backups 
+
+Existem diversos parâmetros importantes quando se trata de um backup digital:
+
+1. Periodicidade.
+2. Incrementos.
+3. Largura de banda.
+4. Segurança e integridade dos dados. 
+
+O primeiro deles é a própria modifição realizada pelo uso dos dados. Um sítio em HTML, Wiki ou Drupal nem sempre -- imagino que no caso dos sítios aqui da vizinhana quase nunca -- se mantém estáticos, sem modificações. Por isso, um backup de um sítio há um mês não conterá as alterações de um sítio realizadas nas duas últimas semanas. O primeiro parâmetro então a periodicidade na qual os backups são realizados.
+
+O segundo parâmetro mais ou menos conseqüência do primeiro: se copiarmos um sítio de um disco para outro a cada semana, podemos atualizar o backup com as alterações realizadas num sítio mas ao mesmo tempo, caso não tenhamos cuidado, podemos também estar apagando o estado que o sítio tinha anteriormente, antes dessas últimas modificações. Em outras palavras, o segundo parâmetro de um backup, a quantidade de "incrementos" que teremos: podemos copiar um sítio para um DVD e, daqui a duas semanas, copiar novamente mas para um outro DVD. Se por um acaso precisarmos de uma informação que continha há duas semanas no sítio, basta que a resgatemos do primeiro DVD. Agora, manter esses "incrementos", isto é, um DVD para cada backup, tem um custo físico e nesse caso ecológico muito grande. É preciso então escolher um número de "incrementos" que permita que tenhamos uma boa amostragem das modificações realizadas num sítio sem que gastemos muito tempo, espaço em disco ou mídia física com tal atividade.
+
+Não entraremos em detalhes, mas um backup que queira dar conta de modificações realizadas em intervalos de duas semanas deve ser realizado pelo menos a cada semana (teorema da amostragem de [Nyquist-Shannon](http://en.wikipedia.org/wiki/Nyquist-Shannon)).
+
+O terceiro parâmetro é a largura de banda. Copiar um sítio de um lugar para outro demanda um tempo de transferência. No caso de sítios muito grandes, a cópia pode demorar tempo demais e o backup se torna mais uma dificuldade do que um benefício. Por isso, a largura de banda pode obrigar que façamos alguns truques: a compressão dos dados (arquivo .zip, tar.gz, tar.bz2, etc) e a cóipia apenas dos arquivos que foram modificados. Por exemplo, num sítio que tem vários vídeos nem todos eles precisam ser copiados a cada backup, mas sim os novos ou aqueles que foram modificados.
+
+O quarto parâmetro é a segurança e a integridade dos dados: se você possui informações sensíveis (senhas, contatos e tudo o mais que for delicado para se tornar público ou cair em mãos erradas), tome cuidado para onde vai copiar essas informações e onde as deixar armazenadas. Da mesma forma, a checagem da integridade dos arquivos verifica se estes não sofreram alterações durante o procedimento de backup.
+
+Em resumo, esses são os quatro parâmetros básicos para um backup: periodicidade, incremento, largura de banda e segurança/integridade. 
diff --git a/backup/conventions.mdwn b/backup/conventions.mdwn
new file mode 100644
index 0000000..78e5c1b
--- /dev/null
+++ b/backup/conventions.mdwn
@@ -0,0 +1,38 @@
+Convenções
+==========
+
+Esta página contém esboço para as convenções de intercâmbio de backups entre servidores. Qualquer que seja o método de backup, ele deve satisfazer as seguintes condições:
+
+1. Deve ser incremental para que vários estados diários sejam possíveis de se obter.
+2. Devem ser gerenciados pelo backupninja.
+3. Cada projeto cuida dos seus próprios backups, mesmo que estes estejam sendo enviados para o servidor de outro projeto. 
+
+Armazenamento 
+-------------
+
+1. Backups hospedados em `/var/backups`, mesmo que seja symlink para outro local.
+2. Arquivos de log de backup em `/var/log/{backup,backupninja.log}`, rodando via logrotate.
+3. Backups remotos de servidores e sites em subpastas do tipo `/var/backups/remote/nome-da-camada.projeto.org/handler`.
+4. Backups locais criptografados em `/var/backups/duplicity` e sem backup da pasta `/var/backups/remote`.
+5. Máquinas enviando backups para outros locais enviam apenas o backup local criptografado. 
+
+O que incluir nos backups locais
+--------------------------------
+
+Talvez a convenção mais forte para a inclusão de arquivos seja aquela na qual a inclusão de novos arquivos e pastas nos backups seja automática. Assim, a convenção adotada é a realização de backups das pastas
+
+* `/etc`
+* `/var`
+* `/home` 
+
+Para que a convenção funcione, é indispensável que conteúdos (dados) hospedados sejam armazenados apenas nestas pastas. Como a `/etc` é uma pasta reservada ao armazenamento de configurações, restam apenas `/var` e `/home` para o armazenamento de dados. Assim, a utilização de pastas do tipo `/var/svn`, `/var/www`, etc garantem a inclusão automática de todo o conteúdo hospedado nos backups.
+
+Não incluir em backups locais
+-----------------------------
+
+As seguintes pastas não devem ser incluídas em backups:
+
+* `/var/backups/duplicity`
+* `/var/backups/remote`
+* `/var/vservers`
+* `/vservers`
diff --git a/backup/methods.mdwn b/backup/methods.mdwn
new file mode 100644
index 0000000..b126224
--- /dev/null
+++ b/backup/methods.mdwn
@@ -0,0 +1,81 @@
+Métodos para backup remoto 
+==========================
+
+Esta página contém um estudo dos métodos de produção, transferência e armazenamento de backups, divididos nas partes:
+
+* Métodos de tranferência
+* Métodos de armazenamento 
+
+A discussão aqui não tem caráter prático mas meramente teórico, sem menção às implementações dos métodos. Para isso, veja a página [Convencoes](../conventions).
+
+Métodos de transferência
+-------------------------
+
+# Método 1: rsync + hardlinks 
+
+Vantagens:
+
+* Economiza espaço
+* Simples de configurar 
+
+Desvantagens:
+
+* Precisa rodar como root nas duas máquinas/vservers para preservar permissões
+* Workarround: criar um `FILELIST.TXT` para cada vserver indicando as permissões e os proprietários dos arquivos, juntamente com um script que corrija todas essas permissões no caso de um restauro de backup. 
+
+# Método 2: tar + ssh 
+
+Esse método consiste em criar um `.tar.bz2` num pipe direto para o servidor remoto, sem escrita local em disco, isto é,
+
+    nice -n 19 tar c /mnt/backup/servidor/vservers/vservers.0/ | bzip2 | \
+    ssh servidor-remoto "cat - > servidor-vservers-0.tar.bz2"
+
+Vantagens:
+
+* o arquivo transferido preserva todas as permissões do seu conteúdo
+* no servidor remoto o arquivo fica compactado
+* rodar com um nice alto garante que esse comando não atrapalhará o funcionamento normal do sistema 
+
+Para economizar espaço na máquina remota, podemos operar com backups incrementais:
+
+    nice -n 19 tar cv /mnt/backup/servidor/vservers/vservers.0/ --listed-incremental=/var/log/backup/vservers.snar \ |
+    bzip2 | ssh servidor-remoto "cat - > servidor-vservers-`date +%w`.tar.bz2" >> /var/log/backup/servidor-remoto.log
+
+Nesse caso, uma vez por semana as seguintes operações devem ser feitas:
+
+* Mover todos os arquivos para uma pasta da "semana passada"
+* Iniciar um novo full-dump. 
+
+Desvantagem: full-dump semanal.
+
+# Método 3: GNU backup 
+
+O script backup que acompanha o GNU tar pode ser usado para fazer dumps incrementais locais que depois são enviados aos servidores remotos.
+
+Desvantagem: arquivos não podem ser modificados durante a confecção do backup.
+
+# Método 4: duplicity 
+
+* http://www.nongnu.org/duplicity/
+* backups criptografados 
+
+# Método 5: rdiff-backup 
+
+* http://www.nongnu.org/rdiff-backup/ 
+
+Métodos de armazenamento 
+------------------------
+
+# Método 1: vserver dedicado a backups 
+
+Cada servidor possui um único vserver dedicado a puxar os backups dos outros servidores. Esse vserver não terá acesso externo e por isso é a abordagem mais segura de armazenamento.
+
+Veja uma discussão sobre isso em https://docs.indymedia.org/view/Sysadmin/PullBackupsForParanoiacs.
+
+# Método 2: vservers dedicados a cada servidor 
+
+Cada servidor possui seu próprio vserver em cada máquina remota onde ele fizer backup. Nesse vserver os backups remotos poderão ser feitos como root sem acarretar perda de segurança para a máquina remota, o que faz essa ser a abordagem mais flexível para puxar ou receber backups remotos.
+Backups criptografados 
+
+Veja uma discussão sobre isso em https://wiki.boum.org/TechStdOut/EncryptedBackupsForParanoiacs.
+