summaryrefslogtreecommitdiff
path: root/backup/methods.mdwn
blob: 1cc18aa54f44e0e8ec83e0ae6603445c14450ddf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
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>.