Назад | Перейти на главную страницу

s3cmd: резервное копирование на лету

Для создания резервных копий я создал сценарий, который создает архив всех папок, которые мне нужны для резервного копирования, отправляет его на S3 (через s3cmd), а затем удаляет его после завершения загрузки.

Я ищу способ избежать создания архива, а затем его удаления, потому что у меня недостаточно места для временного хранения архива! Является ли это возможным?

Вот мой сценарий:

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

Кстати, могу поспорить, что хранить имена пользователей / пароли в виде простого текста в файле crontab - не лучшая практика ... как я могу решить эту проблему?

Заранее спасибо :)

Это выглядит как s3cmd может принимать ввод от стандартного ввода, по крайней мере, в соответствии с разрешением эта ошибка 06.02.2014. Если ваш s3cmd новее, вы сможете:

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

Большинство утилит используют - в качестве имени файла для обозначения записи в стандартный вывод или чтения из стандартного ввода. Это избавит вас от наличия файла .tar.gz на вашем диске.

Что касается паролей / ключей / и т.д., похоже, вы можете указать файл конфигурации для s3cmd с помощью -c FILENAME, предположительно вы использовали бы команды, сгенерированные добавлением --dump-config к полному s3cmd командная строка для создания файла. Однако вам все равно нужно защитить этот файл. Точно так же у MySQL есть ~/.my.cnf файл (см. Вот для примера), где вы можете хранить информацию о подключении.

Кроме того, поскольку вы уже архивируете отдельные дампы базы данных, я подозреваю, что повторное сжатие tar не приведет к более сильному сжатию данных и заставит весь процесс занять больше времени. Рассмотрим просто использование -cvf - и .tar для имени файла.