summaryrefslogtreecommitdiff
path: root/backup/methods.md
diff options
context:
space:
mode:
authorSilvio Rhatto <rhatto@riseup.net>2017-10-01 17:21:16 -0300
committerSilvio Rhatto <rhatto@riseup.net>2017-10-01 17:21:16 -0300
commit07d75df75ada34ef4b7de9cb07770b19251520f1 (patch)
treea3b814eda00e61afbaf9f778edee4ccaba92741d /backup/methods.md
parentef09f1fdae32c8d46b464bb50a85bb69097c211a (diff)
downloadpadrao-07d75df75ada34ef4b7de9cb07770b19251520f1.tar.gz
padrao-07d75df75ada34ef4b7de9cb07770b19251520f1.tar.bz2
Change markdown extension to .md
Diffstat (limited to 'backup/methods.md')
-rw-r--r--backup/methods.md82
1 files changed, 82 insertions, 0 deletions
diff --git a/backup/methods.md b/backup/methods.md
new file mode 100644
index 0000000..1cc18aa
--- /dev/null
+++ b/backup/methods.md
@@ -0,0 +1,82 @@
+[[!toc levels=4]]
+
+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>.