ok se 1 dia fora do ar é suportável eu diria para vc : a) backup do postgresql. b) backup dos dados do servidor. c) usar uma ferramenta de disaster recovery como o rear ou o mondo. d) se tiver um pouco mais de $$ pode-se pensar em um outro servidor menor com master/master do postgresql.
[]s Em 25 de junho de 2015 17:22, S&DeMario <[email protected]> escreveu: > Muito obrigado a todos pelas respostas até agora! > > Um grande problema é o tempo fora do ar, mas digamos que até 1 dia seria > tolerável, mais do que isso implica em prejuízo a vista.... > > Vinicius > > > On 25-06-2015 16:03, Flavio Menezes dos Reis wrote: > > Aliás, em uma rápida pesquisa, pelo menos no caso do postgresql, pode-se > utilizar as funções pg_start_backup e pg_stop_backup para criar um snapshot > sem parar o banco de dados. > > Em 25 de junho de 2015 15:41, Flavio Menezes dos Reis < > [email protected]> escreveu: > >> Aliás, eu estou implementado um ambiente com zfs e drbd para. ao mesmo >> tempo em que faz o espelhamento, utiliza snapshots para backup histórico. >> Sem contar que uma vez criado o snapshot é possível enviá-lo para outro >> meio de armazenamento. O grande "problema" é a necessidade de dar um stop e >> um start no servidor de banco de dados, mas o tempo de criação do snapshot >> é irrisório. >> >> >> Em 25 de junho de 2015 15:37, Flavio Menezes dos Reis < >> [email protected]> escreveu: >> >>> Obrigado Paulo Bruck, escrevi drbl erroneamente, quis dizer drbd. Fiz >>> esta recomandação por ficou claro no problema do Vinícius a perda de dados >>> e a consequente necessidade de recuperação da última posição para >>> continuidade de negócios. >>> >>> Eu evito afirmar que espelhamento não seja backup, pois serve como um >>> em caso de falha e consequente erro no armazenamento principal. >>> >>> Certamente há que se ter clareza de que não permite retornar a uma >>> situação anterior, e neste caso, a política de backup (que não >>> espelhamento) é também essencial. Não adianta eu ter um backup que não me >>> serve. >>> >>> Atte., >>> >>> Em 25 de junho de 2015 15:28, paulo bruck <[email protected]> >>> escreveu: >>> >>>> Olá Vinicius >>>> >>>> Tudo se resume na tecnologia que vc está usando e quanto tempo vc >>>> esta disposto a ficar sem sistema e quanto vc esta disposto a pagar. >>>> >>>> Tem alguns softwares que não necessitam de Alta disponibilidade pois >>>> estes mesmo softwares já tem um esquema de rodar em 2 servidores . exemplo >>>> classico é o dns ( bind) master/slave. >>>> >>>> Pelo que eu me lembro é possivel ter um master/slave ou master/slave >>>> em postgresql. Eu mesmo já fiz o master/master em mysql. >>>> >>>> Quanto aos dados aí sim vc pode pensar em em Alta disponibilidade >>>> com 2 servidores, ou um esquema de maquina virtuais com live migration. >>>> Tudo depende novamente de quanto vc está disposto a pagar e quanto tempo >>>> vc pode ficar fora do ar. >>>> >>>> Apenas um lembrete que muitas pessoas erram de quem um HD como >>>> espelho( seja em RAID1,5,10,6 etc) é backup. NÃO É!!!!! >>>> >>>> Mesmo o drbd ( que seria um rAID1 em rede ) tambem NÃO É um backup. >>>> >>>> São soluções distintas. BAckup != H.A ( Alta Disponibilidade). >>>> >>>> Bem passe na lista o que vc deseja em termos de : >>>> a) quanto tempo posso ficar fora do ar? 5 minutos, 6 horas? 24 horas? >>>> b) quanto a empresa está disposta a pagar? um outro servidor clone? >>>> uma storage? >>>> >>>> Lembrando que quanto menor o tempo que vc deseja ficar parado >>>> normalmente implica em maior custo do projeto. >>>> >>>> []s >>>> >>>> >>>> Em 25 de junho de 2015 15:12, Flavio Menezes dos Reis < >>>> [email protected]> escreveu: >>>> >>>>> Vinícius, >>>>> >>>>> Eu recomandaria, fortemente, a implementação de um servidor de >>>>> failover, utilizando drbl para espelhamento do dispositivo de bloco. >>>>> Assim, >>>>> em caso de falha no servidor primário, basta ativar o secundário, sem >>>>> perda >>>>> de dados. De quebra, ao retornar o primário do conserto, a replicação é >>>>> automática e a solução de failover estará pronta novamente. >>>>> >>>>> Se for o caso de desejar pensar sobre implementar uma solução de >>>>> cluster, nos dê retorno e passamos a aconselhá-lo em como fazer. >>>>> >>>>> >>>>> Em 25 de junho de 2015 12:45, S&DeMario <[email protected]> >>>>> escreveu: >>>>> >>>>>> Sei que este assunto já foi discutido por aqui e não é específico do >>>>>> Debian, mas como se tratam de servidores Debian e por aqui sei que >>>>>> existem >>>>>> pessoas com o mesmo tipo de demanda, peço licença para colocar as >>>>>> dúvidas, >>>>>> agradecendo qualquer opinião a respeito, já esclarecendo que sou >>>>>> desenvolvedor e não estou atualizado quanto a manutenção de sistemas, mas >>>>>> preciso dar alguma ajuda ao cliente, e nada tão bom como a experiência >>>>>> prática para ajudar nestes casos. >>>>>> >>>>>> Temos alguns servidores de arquivo e bases de dados SQL (Postgresql) >>>>>> em nossos clientes e, inevitavelmente, ocorre de tempos em tempos que >>>>>> algum >>>>>> HD apresente defeito, obrigando a restauração do sistema. >>>>>> >>>>>> Coloco então minha dúvida: na opinião de vocês, qual seria o >>>>>> sistema/procedimentos mais adequado para backup dos dados? >>>>>> >>>>>> No caso do servidor SQL, o próprio manual de referência do Postgresql >>>>>> recomenda utilizar uma rotina de dump da base de dados, o que facilitaria >>>>>> seu restauro, ao invés de apenas fazer cópia dos arquivos da base. >>>>>> >>>>>> Quanto aos demais arquivos, uma cópia seria adequada, pois não estão >>>>>> atrelados a uma estrutura, como é o caso de bases SQL. A capacidade de >>>>>> armazenamento hoje é de alguns terabytes (2 ou 3). >>>>>> >>>>>> Usar um software como o bacula para efetuar e gerenciar os backups? >>>>>> Seria adequado para usuários não especializados? >>>>>> >>>>>> Realizar o backup em qual tipo de mídia? Um HD externo, unidade de >>>>>> fita, um servidor tipo storage, uma nuvem? >>>>>> >>>>>> Os servidores já contam com espelhamento, mas já ocorreu (azar!) que >>>>>> um possível surto na alimentação levou o HD com espelho também... >>>>>> >>>>>> Bom, alguém com experiencia em cenários semelhantes a este para dar >>>>>> um pitaco, indicar um caminho das pedras, contar suas aventuras? >>>>>> >>>>>> Agradeço a todos! >>>>>> >>>>>> >>>>>> Vinicius >>>>>> >>>>>> >>>>>> -- >>>>>> To UNSUBSCRIBE, email to >>>>>> [email protected] >>>>>> with a subject of "unsubscribe". Trouble? Contact >>>>>> [email protected] >>>>>> Archive: https://lists.debian.org/[email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Flávio Menezes dos Reis >>>>> Procuradoria-Geral do Estado do RS >>>>> Seção de Infraestrutura de Rede - Assessoria de Informática >>>>> Analista de Informática >>>>> (51) 3288-1764 >>>>> >>>> >>>> >>>> >>>> -- >>>> Paulo Ricardo Bruck consultor >>>> tel 011 3596-4881/4882 011 98140-9184 (TIM) >>>> http://www.contatogs.com.br >>>> http://www.protejasuarede.com.br >>>> gpg AAA59989 at wwwkeys.us.pgp.net >>>> >>> >>> >>> >>> -- >>> Flávio Menezes dos Reis >>> Procuradoria-Geral do Estado do RS >>> Seção de Infraestrutura de Rede - Assessoria de Informática >>> Analista de Informática >>> (51) 3288-1764 >>> >> >> >> >> -- >> Flávio Menezes dos Reis >> Procuradoria-Geral do Estado do RS >> Seção de Infraestrutura de Rede - Assessoria de Informática >> Analista de Informática >> (51) 3288-1764 >> > > > > -- > Flávio Menezes dos Reis > Procuradoria-Geral do Estado do RS > Seção de Infraestrutura de Rede - Assessoria de Informática > Analista de Informática > (51) 3288-1764 > > > -- Paulo Ricardo Bruck consultor tel 011 3596-4881/4882 011 98140-9184 (TIM) http://www.contatogs.com.br http://www.protejasuarede.com.br gpg AAA59989 at wwwkeys.us.pgp.net
