RobL escreveu:Qual a confiabilidade de fato da armazenagem na nuvem ? Em caso de conflito (guerra), certamente não vai perder os arquivos, mas pode não conseguir acessar.
depende da guerra... se os estados unidos forem atacados pelo unico pais com condicoes de fazer um ataque bem-sucedido, a vasta maioria dos datacenters vao ser vaporizados por armas termonucleares ou esterilizados por pulsos eletromagneticos. e de qq forma, nao faria diferenca, pq quem nao morrer na guerra vai morrer no inverno nuclear que se segue. acho que nem precisa ir tao longe para perder os dados: as coisas tendem a ser menos eficientes do que se imagina e, no fim das contas, vc pode perder tudo por um problema muito mais simples, como um ataque interno, um ataque externo, etc. nao, nao estou falando em ataques nucleares ou terroristas, estou falando em ataques de hackers mesmo. ou simplesmente problemas operacionais, afinal o google eh como qualquer empresa: um monte de homer simpsons fazendo um monte de cagadas. eh serio, a entrevista do google pode ser forte, mas os caras q entram nao sao necessariamente os melhores, pq os melhores trabalham em lugares que pagam melhor. dropbox eh melhor? aparentemente sim, mas jah ouvi falar sobre senhas que vazaram. e o icloud da apple eh popular por nunca perder os dados, nem quando vc quer (comento minha experiencia mais adiante).
acho que vale aquele lance dos ovos: nunca coloque todos eles na mesma cesta!
a abordagem mais correta, na minha opiniao, seria ter um armazenamento local minimamente confiavel e ter pelo menos um backup bom. um raid 1 jah daria conta para um bom esquema 24x7: se um disco falha, o servidor continua funcionando e vc continua trabalhando. veja, o raid nao eh backup, eh disponibilidade. se um disco falha, ele continua funcionando. se vc troca o disco, ele reconstroi e o nivel de confiabilidade volta a 100%. em ambos os casos, vc continua trabalhando. sobre backup, bom, antigamente era feito em fita e as fitas guardadas em cofres anti-fogo... mas demora para voltar, isso quando volta! entao eu diria que um bom backup seria ter duas maquinas: se a maquina principal pifa, vc coloca no ar o backup e continua trabalhando. dependendo do caso, eh o tempo de detectar a falha, trocar o ip e pronto. se a maquina de backup estiver em outro predio, melhor ainda, se um predio pegar fogo, vc nao perde tudo. e dependendo do caso, um simples rsync todo dia de madrugada seria suficiente para sincronizar a maquina de backup com a maquina principal, pois ele envia apenas os deltas dos diretorios, mantendo o que nao muda inalterado. se vc trabalha por 8h, vc tem 16h/dia para fazer o sincronismo e isso permite ao rsync carregar bastante coisa. ter o backup do ultimo dia eh o melhor: se der um crash, seu trabalho reseta e volta para o dia anterior. nao ter o backup do ultimo dia comeca a dar uma certa dor de cabeca, bom, pensa soh, vc perder tudo que fez a semana toda... eh pessimo. claro, se as maquinas estiverem no mesmo predio, vc pode ter o luxo de fazer rsync de hora em hora e perder a ultima hora de trabalho apenas... mas daih a vida fica facil demais neh? tem que ter um pouco de emocao no trabalho hehehe
eventualmente, se vc quiser ter uma garantia extra, um backup em nuvem seria uma boa. eu acho mais confiavel que em fita, mas eu diria q eh tao ruim quanto. e eh um passo que vc tem que pensar... se o q vc tem armazenado eh sua vida, eh mais ou menos como confiar em um medico para fazer uma cirurgia. bom, vc confiaria sua vida no google? no dropbox? eu nao tenho muita certeza. nunca perdi dados com eles, mas jah ouvi muitas historias de terror, entao eu nao confio cegamente neles... fora isso, tem os detalhes operacionais: nao sei se rola um rsync com a mesma facilidade, tem o problema dos nomes diferentes, e tem o problema q eles tem problemas iguais ao seu: raid que restaura o disco errado, backup q nao funciona, fita que nao volta, funcionario que vomita nas maquinas, etc. e um link para fora nao tem exatamente a mesma performance, em funcao da latencia e tal: para restaurar o backup, volta via rede, ou seja, nao eh algo imediato. entao eu diria que isso seria um extra em relacao ao plano principal: um servidor principal confiavel e um servidor de backup tao confiavel quanto. dah para fazer um extra fazendo backup em fita, nuvem, etc... mas eh isso: um extra. vc nao volta a operar imediatamente, eh melhor do que nada... mas pode ser melhor neh.
RobL escreveu:Com certeza um problema em um cabo óptico pelo atlântico pode tornar a coisa bem lenta, etc.
o problema eh a latencia da fibra optica... eu tenho um servidor na carolina do norte, dah 150ms de latencia para cah. bem na verdade, ateh a porta do router de saida da embratel eu tenho 21ms e daih a outra ponta, na level3 de nova york jah vai para 135ms. somando tudo, chega nos 150ms. e aquele pulo de 21 para 135ms eh em funcao da distancia, portanto nao tem nem como encurtar aquilo. transferindo os arquivos, a latencia nao eh problema pq as transferencias costumam usar pipelines q aproveitam todo o bandwidth disponivel. mas transacoes pequenas, como verificar a existencia de arquivos via rsync, sao em um esquema meio ping-pong, nao tem como nao ser, vc tem um arquivo de um lado, verifica se esta do outro e o outro responde... resultando em uma performance pessima. transferir tudo sem verificar permitiria aproveitar melhor o bandwidth, mas normalmente vc tem muito mais dados do que pode transferir no mesmo dia, o q cria aquele constrangimento de ter q refazer o trabalho da ultima semana e coisas assim.
RobL escreveu:O Aquino já teve um problema. Penso que os arquivos com nomes extensos devem estar lá de alguma forma, ou tem um bug.
pois eh, acredito que estao lah. para nao dizer q nunca tive problema, jah tive problemas com o icloud da apple: arquivos estavam lah, mas nao apareciam como dados, eles ficavam em uma particao especial como backup, que nao se consegue apagar. eu nao tinha perdido os arquivos, entao nao era problema, porem o icloud nao eh muito barato e eu precisava do espaco...mas eu nao conseguia liberar o espaco! e detalhe, aih entra a magia do datacenter ser seguro demais, no aspecto dos funcionarios nao poderem fucar nos seus dados: ninguem de lah de dentro conseguia apagar nada. pelo que entendi, tudo q eu envio, eh criptografado de tal maneira que a unica coisa visivel eh espaco alocado... muita gente teve o mesmo problema e a unica solucao parecia esperar uma falha catrastrofica que perdesse todos os dados em um hipotetico futuro... bom, isso seria esperar muito tempo! entao depois de alguns meses tentando eu consegui fazer um truque que transformava os backups em dados e entao eu conseguia descartar, liberando espaco para o que eu realmente precisava.
uma dica extra muito importante: supondo que vc faz tudo certinho, usando um par de servidores com raid 1 e mais algum backup em cloud ou fita... como realmente usar isso melhor? uma dica que eu dou eh ter controle de versao.
tipo, ao inves do classico servidor de disco, disponibilizar apenas um SVN. ah, mas para armazenar um simples documento vou ter q colocar no SVN? sim. vc vai editar um documento de proposta, vai adicionar ele no SVN. feito isso, quando vc alterar para fazer um update, vc vai sincronizar e vai ter todas as versoes com todas as alteracoes. qualquer empresa minimamente seria tem que ter esse tipo de mecanismo, principalmente para codigo fonte, documentacao, etc. e com isso vc ganha algo muito mais importante: replicas. quando vc trabalha no seu computador, vc tem o arquivo no seu computador. vc sincroniza com o servidor SVN, vc tem uma copia no seu computador e uma replica no servidor. no servidor vc pode analisar o log do SNV e disparar uma replica para o servidor de backup, tao logo o arquivo apareca no log. e lah no servidor de backup, vc pode disparar uma replica para o backup em fita ou cloud. se o servidor principal quebrar, a probabilidade de vc perder algo eh minima, pois provavelmente houve tempo de todas as replicas serem feitas. do contrario, pelo menos a replica na sua maquina existe. parece dificil trabalhar assim, mas com o tempo vc acostuma.
