Backup automatico [RESOLVIDO]

k666 escreveu:

Prezado, percebi que você está fazendo a compactação para um arquivo .rar. Seria melhor utilizar o .tar.gz por ter uma taxa de compressão melhot. Acredito que o problema deve estar aí.

Outra coisa é fazer um teste enviando o arquivo sem o script para ver se não está havendo perda de conexão durante o envio ocasionando o corrompimento do arquivo. O teste pode ser pela linha de comando ou uma interface gráfica com o filezilla.

paulo1205 escreveu:

Na verdade, geralmente o rar tem taxas de compressão melhores do que o gzip, a não ser, talvez, para alguns conjuntos de dados muito particulares. Além do mais, como ele disse, os arquivos estão OK na origem, só aparecem corrompidos no destino do FTP.

É difícil determinar a causa exata, mas o FTP tem quatro modos de operação que podem afetar os dados transmitidos. Tais modos são: image, também chamado binary, em que os dados são enviados em bytes exatamente como existentes na origem, e o destino é obrigado a salvar esses bytes exatamente como recebidos; ASCII, destinado ao envio de dados em formato de texto, que obriga o remetente a seguir certas convenções de representação na hora de enviar o texto, implicando que o que trafega na rede não necessariamente é idêntico ao que estava no disco na origem, nem tampouco coincide necessariamente com o que o destino guarda; EBCDIC, que é análogo ao ASCII, mas comumente é usado quando pelo menos um dos entes envolvidos utiliza EBCDIC para representar textos (por exemplo: mainframes da IBM), em lugar de ASCII; e o quarto modo que é chamado de local, previsto para ser usado por máquinas que não trabalham com bytes de exatamente oito bits.

Na prática, os modos mais comuns são imagem e ASCII. E um erro muito comum era -- e talvez ainda seja -- especificar modo ASCII para transmitir arquivos que não são de texto. Quando o FTP no UNIX pensa estar trabalhando com texto, ele faz pelo menos uma transformação ao colocar os dados na rede: trocar todas as ocorrências do byte com valor 10 (correspondente à marca de fim de linha no UNIX) pelo par de bytes com valores numéricos 13 e 10, nesta ordem, que é a convenção de marcação de fim de linha usada em vários protocolos da Internet, e também pelo Windows. Desse modo, a transferência em modo ASCII de um arquivo de uma máquina UNIX para uma com Windows necessariamente vai trocar todos os bytes de valor 10 pelo par de bytes com valores 13 e 10. Já de uma máquina com Windows para outra com UNIX, uma transferência em modo ASCII acarretaria a supressão de todos os bytes de valor 13 que fossem seguidos por bytes de valor 10.

Não é um erro de transmissão ou comunicação corrompida. É a consequência perfeitamente previsível da seleção do modo de trabalho.