Robson Cunha wrote: > - Meu amigo eu simplifiquei muito a minha pergunta, e não descrevi > qual era a intenção dessa tarefa totalmente para não complicar o > entendimento do pessoal da lista, eu podia contar todo o meu > histórico de estar implementando isso.
Você pulou um dos passos mais importantes. Não precisa contar todo o histórico, mas é adequado você explicar claramente: - Qual era o seu problema original; - O que você acha que estava errado; - O que você tentou fazer para solucionar; - A partir de que ponto você não conseguiu resolver. Nos quatro pontos o usuário pode ter cometido um equívoco. Muitas vezes o usuário pensa numa solução mirabolante e quase impossível para o seu problema, quando alguém já existe uma solução correta que foi ignorada. O mundo é muito grande, e se você encontrou um problema para o qual não conhece solução, é muito provável que vários outros já tiveram este problema e já inventaram diversas soluções, algumas corretas e algumas incorretas. > Resumindo: Eu quero que o arquivo A(original) se compare com o > B(cópia) e jogo no B somente a diferença ao longo de 2 dias, somando > ao que já exestia antes. Dessa forma terei o arquivo B completo para > os fins a qual desejo. Ou seja, o arquivo B não é nem o arquivo A original, nem o arquivo A novo. Ao contrário do que você diz, você não quer apenas copiar as diferenças. Se você calcular a diferença entre A0 (arquivo original) e A1 (mesmo arquivo 2 dias depois), esse delta conteria todas as diferenças, inclusões *e remoções*. Aplicando este delta ao arquivo A0 resultaria em A1 novamente, e não B. O seu arquivo B que você está sugerindo é uma "soma" as adições de do delta A1-A0 ao arquivo A0, ignorando as remoções. B, neste caso, conteria apenas as adições do *conteúdo lógico* do arquivo. Aí é que você vai se enroscar, de múltiplas maneiras. Você precisaria de uma solução especializada para ler e identificar cada e-mail individual dos arquivos ao longo da história, identificar duplicados, agrupá-los e enfim gerar um arquivo novo. Você não vai conseguir fazer isso só com cat, diff, patch e as outras ferramentas básicas do Linux. Você precisaria de pelo menos um script em Perl, ou usando uma mistura de sed+awk. > Vou deixar o outlook de 16 pessoas para deixar a cópia no servidor > durante 2 dias e no 2º dia as 23:00 horas antes do cara chegar para > trabalhar, copiamos o seu arquivo de e-mail do servidor para uma > partição ext3 montada em outra máquina linux. Dessa forma teremos o > backup dele lá. E daqui a 2 dias, fazemos a mesma coisa copiando o > arquivo A(original) para o B(cópia) acrescentando a diferença. > Teremos os e-mails do cara no arquivo B de forma integral intende. Sua ideia é muito frágil, e não resolve o seu problema. Você depende que as 16 pessoas configurem seus Outlooks da forma como você precisa para a sua solução funcionar... Se um deles perder tal configuração por qualquer razão (reinstalou o Windows, apagou o perfil do Outlook, acessou usando outro cliente de e-mail, etc...), vai apagar todos os e-mails do servidor e sua solução de backup vai imediatamente por água abaixo. Se você ainda acha que deve seguir o seu raciocínio, recomendo fazer de forma bem diferente: Faça cada cópia de segurança de cada dia isolada de todas as outras. Ignore se há e-mails repetidos, cada backup de cada dia vai para um diretório único: backup-20090601/... backup-20090602/... backup-20090603/... backup-20090604/... *SE* você precisar recuperar os e-mails de alguém, recupere o arquivo correspondente de cada um dos diretórios em sequência, fazendo o download de cada um deles pelo Outlook. Assim você deixa o Outlook detectar os e-mails repetidos e não fazer o download deles. Afinal, o Outlook já possui o algoritmo correto para isso. É mais trabalhoso, mas é o mais seguro, pois você não tem que rescrever um arquivo MBOX na mão. Tentar reconstruir o arquivo MBOX na mão não é exatamente trivial. Não dá para simplesmente fazer o que você estava imaginando. E eu não arriscaria fazer alguma coisa errada que resultasse num arquivo B corrompido, e o usuário acabar por perder todos os seus e-mails. > O problema que temos uma solução ampliance montada, cheio de scripts > proprietários da empresa, não podemos mecher nesse linux ampliance, > pois pode dar um problema sério e parar o servidor, o HD nele é de > 40gb, pequeno; Não há possibilidade de deixar os e-mails lá. Então o problema, no fundo mesmo, é que você adquiriu uma solução inadequada. Para resolver o seu problema de fato você precisa rever essa sua estrutura. Não existe essa de "não podemos mecher" [sic]. No mínimo, a empresa precisa fornecer o suporte do produto que ela te vendeu. > A única > boa solução que pensamos foi essa que falei acima. Porque copiar os > arquivos dos outlooks dessas 16 pessoas ia ser difícil pela rede, > cada um tem 4gb de arquivos .DBX; A intenção é fazer o backup somente > desse pessoal diário diretamente pelos arquivos /var/mail/arquivo ; Como eu disse, essa solução é incorreta. É um erro pensar que o arquivo em /var/mail reflete perfeitamente a INBOX do usuário. Aliás, eu sequer consideraria como qualquer tipo de substituto. Se você roda backups todos os dias as 23h, o usuário recebe um e-mail às 15h e faz o download (e apaga) às 15h05, já era. O e-mail não vai estar mais em /var/mail, estará apenas na INBOX no computador dele. Depender que o usuário tenha uma configuração específica em suas estações de trabalho (pedir para o Outlook deixar o e-mail no servidor) para que o servidor funcione corretamente é totalmente fora de qualquer manual de administração de redes que eu conheço. > Amigo como falei esse CPU é um appliance, não podemos alterar nada > porque pode desandar tudo. Bom se você tem essas soluções de script > com diff e patch pode me sugerir que agradeço. Como eu falei, não é simples pegar A0 e A1 e chegar em um arquivo B válido (no formato correto MBOX) sem identidade com os arquivos anteriores. O melhor que você pode fazer é usar fsvs ou svn (ou outro controle de versões) para versionar o diretório de e-mails, e simplificar a cópia de segurança. Você pode considerar cada backup como uma ramificação do controle de versões, e quando quiser recuperar, você cria uma nova ramificação mesclando as ramificações dos dias que você quer juntar. Mas tenha em mente que o controle de versões não conhece o formato MBOX, e ele *não* garante que o resultado será bem-formado. Ele apenas faz a mescla de linhas de texto, e encontrando uma divergência, ele irá jogar nas suas mão para você fazer a mescla (e portanto, você terá que conhecer o formato MBOX). Você pode fazer isso na mão também, fazendo uma primeira cópia integral, e todas as cópias sucessivas com diff. Quando quiser recuperar, utilize o comando merge para remontar todas as diferenças *paralelamente* (não serialmente, senão a única coisa que você irá conseguir é a versão de A como estava no último dia). > A história toda começou porque um usuário desses 16 mandou compactar > a mensagem do outlook, a qual o software sempre pergunta e perdeu > todos os e-mails, pois essa compactação destói os .DBX, ainda mais se > o usuário tiver 4gb de .DBX como esses caras. Você reportou esse defeito ao fabricante do software (Microsoft)? Se eles te vendem um software que não funciona conforme anunciado, é responsabilidade deles corrigir o problema. > E estamos pensando numa > solução de backup, você intendeu agora, se der problema. Copíamos > esse arquivo que guardamos B da pessoa respectiva e o cara baixa os > e-mails de novo. Ps.: Não fui eu que implementei essa solução na > empresa, É difícil migrar isso agora, estamos dando uma solução > paleativa. Construa um novo servidor de e-mails paralelo, com espaço suficiente em disco, pastas armazenadas no servidor, acesso via IMAP, talvez até um WebMail para os funcionários acessarem de fora da empresa, e faça a migração durante uma noite. Depois disso chame a empresa que lhe vendeu o seu equipamento atual e inquira-os o porquê da solução deles ser tão ruim, a ponto de te trazer todos esses problemas. Pergunte o porquê deles venderem uma solução proprietária e fechada que sequer atinge as expectativas que qualquer distro Linux gratuita e aberta oferece. Se for o caso, tente devolver o servidor em troca de parte do seu dinheiro de volta, é um direito seu como consumidor. Minha solução pode parecer drástica, mas é meu estilo: eu não construo soluções em cima de problemas... isso duplica suas dores de cabeça a médio e longo prazo. Em vez disso, eu ataco e destruo o problema pela raiz. Isso me garante mais tranquilidade. Att, Juliano. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. --------------------------------------------------------------------------- Esta lista é patrocinada pela Conectiva S.A. Visite http://www.conectiva.com.br Arquivo: http://bazar2.conectiva.com.br/mailman/listinfo/linux-br Regras de utilização da lista: http://linux-br.conectiva.com.br FAQ: http://www.zago.eti.br/menu.html
