我有一个新要求,要清除30天以上的MySQL转储文件。这些文件使用“ all-mysql-YYYYMMDD-HHMM.dump”的命名约定。这些文件位于SAN挂载的文件系统上,因此恢复不是问题,但是不幸的是,驱动器空间有限并且很快就会填满,因此需要频繁的人为干预。
文件名示例
- 全部-mysql-20130324-2330.dump
- 全部-mysql-20130325-2330.dump
- 全部-mysql-20130326-2330.dump
我首先想到的是在带有-mtime +30的批处理脚本中使用“查找”,但是,修改时间无法保证,某些较早的归档文件可能会清除清除日期:)
我创建了以下BASH脚本,但我希望有一种更干净的方法来执行此操作。
#!/bin/bash
STARTING_DIR=$(pwd)
FILE_PREFIX=all-mysql-
BACKUP_DIR=/opt/backup/mysql/dumps
ARCHIVE_WINDOW_DAYS=30
cd $BACKUP_DIR
# Create YYYYMMDD datestamp for Today - $ARCHIVE_WINDOW_DAYS
ARCHIVE_WINDOW_IN_SECS=$(echo "$(date +%s) - (${ARCHIVE_WINDOW_DAYS} * 86400)" | bc)
PURGE_BEFORE_DATE=$(date -d @${ARCHIVE_WINDOW_IN_SECS} +%Y%m%d)
for backup_file in $FILE_PREFIX*
do
# Trim prefix, time portion of date stamp, and file extension
# from $backup_file to allow numeric comparison against YYYYMMDD
backup_trim_tmp=${backup_file#${FILE_PREFIX}}
backup_trimmed=${backup_trim_tmp%-****.dump}
if [ ${PURGE_BEFORE_DATE} -gt ${backup_trimmed} ]
then
rm $backup_file
fi
done
cd $STARTING_DIR
3
看起来对我来说已经足够了,而且我看不到比您实际使用的更简单的日期转换方法。:)
—
天衣
@tink-谢谢。不禁想到有一个统一的解决方案。我更关心其他维护者,他们在JavaLand中的生活要比BASHland多。也许唯一的问题是“ 2038年”问题:)
—
TP
这不是
—
ott--
logrotate更清洁的解决方案吗?
对于此类情况,也应采取保护措施(由于某种原因而没有新备份时,请勿删除旧备份)。
—
弗罗斯特斯
@ott-如果它在用户环境中工作良好,则可以选择。不幸的是,我们(应用程序工程师)没有任何root或su特权,因此,如果有任何特权进入syslog或需要任何其他超级用户priv,我们将处于黑暗之中。这真是令人um目结舌,但却是统治政策:(
—
TP