Rsync não copia arquivos com extensão .BAK [RESOLVIDO]

[ericooliveira]

Amigos, estou utilizando um script com o rsync para fazer o backup, porém percebi que os arquivos com extensão .BAK não estão sendo copiados. Não percebi se existem outras extensões com o mesmo problema. Segue abaixo o script.

#!/bin/bash
INICIO=`date +%d/%m/%Y-%H:%M:%S`
LOG=/var/log/rsync/`date +%Y-%m-%d`_BackupArquivosAL.txt
echo " " >> $LOG
echo " " >> $LOG
echo "|-----------------------------------------------" >> $LOG
echo " Sincronização iniciada em $INICIO" >> $LOG

sudo rsync -Cravp --delete /home/administrador/ArquivosAL/ /media/administrador/Seagate\ Expansion\ Drive/Dropbox >> $LOG
FINAL=`date +%d/%m/%Y-%H%:M:%S`

echo " Sincronização Finalizada em $FINAL" >> $LOG
echo "|-----------------------------------------------" >> $LOG
echo " " >> $LOG
echo " " >> $LOG

[druidaobelix]

Esses dois tópicos podem ajudar em alguma coisa:

https://ubuntuforum-br.org/index.php/topic,119920.msg658683.html#msg658683

https://ubuntuforum-br.org/index.php/topic,121063.msg664739.html#msg664739

Mas no geral apenas não é uma boa ideia usar um script para fazer backup.

Tem coisa muito melhor que isso, pra que ficar limitado à pequenas invencionices de script?

No mais, obviamente a obtenção de data da varíavel $FINAL está incorreta, é só copiar como está na variável $INICIO

E o uso do rsync dessa forma tá muito pobre, sem ao menos usar o recurso incremental.

Mas, insisto, esquece isso é usa um programa de backup de verdade.

[ericooliveira]

Esqueci de comentar que utilizo o Linux a pouquíssimo tempo e estou configurando um backup pela primeira vez. Segui o tutorial abaixo:

https://www.vivaolinux.com.br/artigo/Como-programar-backup-com-rsync-e-cron-de-maneira-rapida-e-simples

A minha dúvida surgiu porque em tudo que li até agora agora sobre o RSYNC, informa que o mesmo copia todos os arquivos, inclusive arquivos ocultos. Não sei porque ele está excluindo os arquivos .BAK.

Obrigado pela ajuda.

p.s. o parâmetro -C não torna o backup incremental?

[druidaobelix]

Então, @ericooliveira,

Antes de entrarmos no mérito de tais e quais opções fazem o quê,  é necessário ver que o conceito geral dessa proposta de backup está errada.

Isso não é verdadeiramente um backup e sim, quando muito, uma cópia sincronizada, o que são coisas diferentes.

Um backup para ser minimamente digno do nome precisa ter, pelo menos, um rodízio de arquivos copiados, onde apenas os mais antigos são de fato elimnados.

A sincronização torna o destino igual a origem, mas o backup vai além, ele preserva as cópias por algum tempo, conforme algum critério.

Um exemplo simples para ilustrar o que se está dizendo.

Tenho uma planilha qualquer na qual estou trabalhando.
Faço isso e faço aquilo na planilha e depois, inadvertidamente e sem perceber deleto a tal importante planilha.
O meu script de backup, esse que está aí proposto, está programado no cron para ser executado diariamente a tais horas.
Como o script está usando o parâmetro --delete isso irá ocasionar que ao constatar que na origem a planilha não existe mais, então ela será apagada também no destino, ou seja, feita a sincronização.
Pois bem, daqui a uma semana volto para trabalhar na minha planilha.
Vou lá no meus arquivos e não acho minha planilha, não lembro o que aconteceu, não sei dizer porque ela não está lá.
Então vou ao meu "backup" para recuperar a planilha que não estou encontrando junto aos meus arquivos.
E aí o susto, descubro que ela também não está mais lá no suposto "backup".
Está feita e perfeita e tragédia do backup mal feito!

Um backup precisa ir fazendo uma "pilha" de arquivos, removendo apenas os mais antigos conforme algum critério (uma semana, um mês, um ano, sei lá, depende das necessidades de cada aplicativo/pessoa/organização).

Se vai implementar isso por script, certamente é possível, porém o nível de programação não pode ser algo assim simplório, certamente haverá a necessidade de sofisticar muito mais o que está proposto.

Acontece que todo esse esforço de programação já foi feito por alguém (alguéns), usando uma linguagem de programação mais poderosa e abrangente que um bash script (que também é poderoso, mas nem tanto como, por exemplo, dentre várias outras, um C++), daí a existência de vários e vários programas "profissionais" de backup, já pensados, testados e com manutenção mantida.

O esforço é muito menor ao usar um bom programa de backup e a segurança é muito maior de estar fazendo a coisa certa.

É isso. 

[ericooliveira]

@druidaobelix, de fato seus argumentos fazem total sentido. O problema de apagar um arquivo e só perceber no dia seguinte, tendo um "backup" diário desta forma, é realmente um desastre.

Que software de backup você recomenda para iniciantes? Gostaria apenas que o software não utilizasse um único arquivo de backup compactado.

Mais uma vez, obrigado pela ajuda.

[druidaobelix]

Que software de backup você recomenda para iniciantes? Gostaria apenas que o software não utilizasse um único arquivo de backup compactado.

Pois então, @ericooliveira,

Tudo sempre depende muito da necessidade individual, se é um sistema pessoal, se é empresarial, coorporativo, enfim, o caso concreto é que irá ditar o melhor a fazer e como adequar.

O Ubuntu vem com um programa nativo de Backups, como esse nome mesmo, é só olhar lá no Dash ou ainda na caixa de Configurações do sistema.
É um bom programa, no geral dá pro gasto se não for uma necessidade muito sofisticada.
Muitas vezes não há necessidade de usar bala de canhão pra atirar em mosca, é uma questão de proporcionalidade.

Já o bácula é campeão, atende qualquer necessidade profissional.

[ericooliveira]

Obrigado pelas dicas @druidaobelix.

De qualquer forma descobri o problema dos arquivos .BAK. A opção -C no RSYNC exclui por default diversos tipos de arquivos, inclusive os .BAK.

RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/ .git/ .hg/ .bzr/

[druidaobelix]

[...] Gostaria apenas que o software não utilizasse um único arquivo de backup compactado.

Uma última questão quanto ao formato dos arquivos de backup.

Penso que o importante é não ser refém de um aprisionamento tecnológico.

Tanto no programa de backup nativo do Ubuntu quanto no bácula é utilizado ferramenta de compactação e esse é um padrão nos softwares de backup, porém são gerados arquivos de formatos abetos, isto é, não proprietários, portanto, podem ser lidos em qualquer Linux.
Não há o risco de ficar prisioneiro de um formato proprietário.
Um arquivo gz se abre normalmente em qualquer Linux, sem nenhuma dificuldade, sem nenhum problema.