s3cmd: backup on-the-fly

Question

Para fazer backups eu criei um script que faz um arquivamento de todas as pastas que eu preciso fazer backup, envia para o S3 (através de s3cmd) e depois o apaga depois que o upload for concluído.

Estou procurando uma maneira de evitar a necessidade de criar o arquivo e excluí-lo porque não tenho espaço suficiente para armazenar temporariamente o arquivo! É possível?

Aqui está meu script:

DBLIST='mysql -uMYSQL_USERNAME -pMYSQL_PASSWORD --events -ANe"SELECT GROUP_CONCAT(schema_name) FROM information_schema.schemata WHERE schema_name NOT IN ('information_schema','performance_schema')" | sed 's/,/ /g''
MYSQLDUMP_OPTIONS="-uMYSQL_USERNAME -pMYSQL_PASSWORD --single-transaction --routines --triggers"
BACKUP_DEST="/home/backup/db"
for DB in 'echo "${DBLIST}"'
do
    mysqldump ${MYSQLDUMP_OPTIONS} ${DB} | gzip -f > ${BACKUP_DEST}/${DB}.sql.gz &
done
wait
tar -czvf /home/backup/db2/'date +\%G-\%m-\%d'_db.tar.gz ${BACKUP_DEST}
s3cmd --reduced-redundancy put -r /home/backup/db2/ s3://MY-S3-BUCKET/ --no-encrypt
find /home/backup -type f -delete

Em uma nota, posso apostar que não é uma prática recomendada armazenar nomes de usuário / senhas em texto simples em um arquivo crontab. Como posso resolver isso?

Agradecemos antecipadamente:)

    

Answer 1

Parece que s3cmd pode aceitar entrada de stdin pelo menos de acordo com a resolução de este bug em 06/02/2014. Se o seu s3cmd é mais novo do que você deve ser capaz de fazer:

tar -czvf - ${BACKUP_DEST} | s3cmd --reduced-redundancy put - s3://MY-S3-BUCKET/'date +\%G-\%m-\%d'_db.tar.gz --no-encrypt

A maioria dos utilitários usa - como um nome de arquivo para indicar a gravação em stdout ou leitura de stdin. Isso eliminará ter o arquivo .tar.gz na sua unidade.

No que diz respeito a senhas / chaves / etc, parece que você pode especificar um arquivo de configuração para s3cmd com -c FILENAME , presumivelmente você usaria os comandos gerados adicionando --dump-config a uma linha de comando s3cmd completa para crie o arquivo. Você ainda precisa proteger esse arquivo, no entanto. Da mesma forma, o MySQL tem seu arquivo ~/.my.cnf (veja aqui para um exemplo) onde você pode armazenar informações de conexão.

Além disso, como você já está compactando os dumps de banco de dados individuais, suspeito que gzipar o tar novamente não comprimirá muito mais os dados e fará com que todo o processo demore mais. Considere apenas usar -cvf - e .tar para o nome do arquivo.