проблема mysqldump в файле Crontab и bash - PullRequest
Новая
       23

проблема mysqldump в файле Crontab и bash

0 голосов
/ 28 февраля 2020

Я создал вкладку cron для резервного копирования моей БД каждые 30 минут ... 

*/30 * * * * bash /opt/mysqlbackup.sh > /dev/null 2>&1

Вкладка cron работает хорошо. Каждые 30 минут у меня есть резервная копия с приведенным ниже сценарием. 

#!/bin/sh
find /opt/mysqlbackup -type f -mtime +2 -exec rm {} +
mysqldump --single-transaction --skip-lock-tables --user=myuser -- 
password=mypass mydb | gzip -9 > /opt/mysqlbackup/$(date +%Y-%m-%d-%H.%M)_mydb.sql.gz

Но моя проблема в том, что функция rm для удаления старых данных не работает .. она никогда не удаляется .. Знаете почему?

, а также ... имя моего резервная копия 2020-02-02-12.12_mydb. sql .gz?

У меня всегда есть? в конце моего имени файла .. Вы знаете почему?

Спасибо за вашу помощь

Ответы [ 2 ]

0 голосов
/ 27 апреля 2020

Использование find с mtime не лучший выбор. Если по какой-то причине mysqldump прекращает создавать резервные копии, то через два дня все резервные копии будут удалены.

Вы можете использовать мой скрипт Python rotate-archives для интеллектуальных резервных копий. (https://gitlab.com/k11a/rotate-archives). Скрипт добавляет текущую дату в начало имени файла или каталога. Как 2020-12-31_filename.ext. Впоследствии эта дата используется для принятия решения об удалении.

Запуск сценария по вашему вопросу: 

rotate-archives.py test_mode=off age_from-period-amount_for_last_timeslot=0-0-48 archives_dir=/mnt/archives

В этом случае всегда будут сохранены 48 новых архивов. Старые архивы, превышающие это число, будут удалены.

Пример более гибкого удаления архивов: 

rotate-archives.py test_mode=off age_from-period-amount_for_last_timeslot=7-5,31-14,365-180-5 archives_dir=/mnt/archives

В результате останутся архивы от 7 до 30 дней с интервал времени между архивами 5 дней, от 31 до 364 дней с интервалом времени между архивами 14 дней, с 365 дней с интервалом времени между архивами 180 дней и числом 5.

0 голосов
/ 03 марта 2020

Знак вопроса обычно указывает на символ, который не может быть отображен; тот факт, что он находится в конце строки, заставляет меня думать, что ваш сценарий имеет Windows окончания строки, а не Unix. Это можно исправить с помощью команды dos2unix: dos2unix /path/to/script.sh

Также рекомендуется не разбрасывать пароли MySQL в CLI и не сохранять их в исполняемых скриптах. Вы можете выполнить sh, используя MySQL Файлы опций , в частности, файл, определяющий опции уровня пользователя (~/.my.cnf).

Однако для этого потребуется выяснить, какой пользователь выполняет этот cronjob. Я предполагаю, что вы не сделали это определение внутри системного уровня crontab; если бы вы имели, вы бы на самом деле пытались выполнить /opt/mysqlbackup.sh > /dev/null 2>&1 как пользователь bash. Этот пользователь, скорее всего, не существует (и не должен) существовать, поэтому cron не сможет выполнить скрипт полностью.

Поскольку это не так (вы говорите, что он выполняет mysqldump просто отлично), это делает Мне кажется, у вас есть определение в crontab уровня пользователя. Как только мы выясним, какой пользователь на самом деле является тем, о чем я просил в своем комментарии, мы можем определить проблему с правами доступа к файлу, а также создать вышеупомянутый файл параметров MySQL.

...