blob: b126224d1238f05e950e2f43c2ff916bbcd57141 (
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
|
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.
|
