Backup automatico [RESOLVIDO]

1. Backup automatico [RESOLVIDO]

rafael c s
tyr

(usa Slackware)

Enviado em 06/03/2015 - 18:50h

Boa Tarde Pessoal

estou fazendo um backup no servidor via ftp usei esse script http://www.vivaolinux.com.br/topico/Shell-Script/Scritp-backup-FTP funcionou certinho, porem quando salva o arquivo no servidor de ftp o arquivo vem corrompido mais no diretorio que ele fina na maquina local esta certo abre todos os arquivos achei que o erro era por usar o ftp na mesma linha de comando ai criei um para o ftp e ficou assim mais continua corrompendo o arquivo alguem sabe o que pode ser.


#!/bin/sh
###############################
# Script de Backup
# Developed by Flexnetsolutions
#
# Security
#
###############################

#Configuracao para data no arquivo de backup
DATAA=`date +%Y-%m-%dx%H-%M`

# diretorio do backup
DIRETORIOFONTE="/db/ti/rafael"

# diretorio aonde sera feito o backup
DIRETORIOARQBCK="/backup/"

# fazendo o backup
echo "Fazendo Backup..."
rar a $DATAA.rar $DIRETORIOFONTE

#Configuracao para data no arquivo de backup
DATA=`date +%Y-%m-%dx%H-%M`

echo "Entrando no diretorio de envio de arquivos"
cd $DIRETORIOARQBCK

echo "execulta o t.sh"

./t.sh

echo "SAINDO"
exit


script do ftp

#!/bin/bash
#
#


# espere por segundos
sleep 5

BKP=/backup
DATAA=`date +%Y-%m-%dx%H-%M`
DATA=`date +%Y-%m-%dx%H-%M`

echo "acessando o bkp"
cd $BKP

FTPSERVER="ip aqui"
USERNAME="user aqui"
PASSWORD="#senha aqui#"
LOCALDIR="/bkp"

# conecte-se ao servidor FTP e envie o arquivo
echo "conectando no servidor FTP..."

ftp -ivn $FTPSERVER << FTP

user $USERNAME $PASSWORD

#Upando Backup
echo "Upando arquivo..."
put $DATA.rar

bye
EOF
FTP



  


2. Re: Backup automatico [RESOLVIDO]

Paulo
paulo1205

(usa Ubuntu)

Enviado em 06/03/2015 - 19:41h

Experimente colocar o comando bin (numa linha separada) antes do comando put.


3. Re: Backup automatico [RESOLVIDO]

Wagner Souza
wagnerfs

(usa Fedora)

Enviado em 06/03/2015 - 21:19h

Boa noite.

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.

_________________________
Wagner F. de Souza
Graduado em Redes de Computadores
"GNU/Linux for human beings."
LPI ID: LPI000297782



4. Re: Backup automatico

Paulo
paulo1205

(usa Ubuntu)

Enviado em 07/03/2015 - 04:00h

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í.


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.

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.


É 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.


5. Backup automatico

rafael c s
tyr

(usa Slackware)

Enviado em 09/03/2015 - 14:18h

VLW pelas respostas pessoal mais acho que o problemas e o que o k666 escreveu pelo que entendi o padrão que tinha colocado no ftp era IIsi vi nesse site parece que e só para acessar os arquivos para upar tem que ser na maquina física não sei se e bem isso mais obrigado pela ajuda

segue o link http://juliobattisti.com.br/tutoriais/gersonkonnus/iis6004.asp


paulo1205 escreveu:

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í.


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.

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.


É 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.











Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts