阿里云oss空间清理之奇思妙想
用过阿里云oss的同学，应该都知道上传后的文件名，命名是一串随机字符串：
而且这串bucket，据说开发还是做了优化，才存到一个个叫uuid的目录。不然，最最原始的时候，它们没有自己的“归属”（即上面的子目录），就是一坨字符串杂乱无章地存着。
阿里的oss控制台、还有oss管理工具，都没有做按文件更新时间做排序搜索，导致清理极其困难。
今早手动清理了几个目录发现累死了，因为，清理之前是要先备份的。我昨天拉了850天前的数据，大概几万个文件到公司内网的服务器上，清理之前，我要先对下该bucket目录里面的文件更新时间是否是2018、2019年（开发说保留最近两年数据即可），要先确认更新时间是否对上了，本地备份的对上了才能删。所以我今天在内网的机器不停地运行这几条命令，实属悲催：
[root@ljy bak-某bucket-img]# mkdir 某目录uuid ##因为该目录下文件前缀就是某目录uuid，所以直接移动到 [root@ljy bak-某bucket-img]# mv 某目录uuid* -t 某目录uuid/ mv: 无法将目录"某目录uuid" 移动至自身的子目录"某目录uuid" 下 ##年份：2018或2019 [root@ljy bak-某bucket-img]# mv 某目录uuid /data_bak/bak-某bucket-img]/年份/
说明：
（1）当前目录：bak-某bucket-img : 存有几万个文件， 要 “ls | more” 找到文件前缀，
上面的mkdir uuid 的uuid就是指这人眼甄选出的文件前缀！！！
然后我就把这坨有该uuid的一类文件选出来，放到目录uuid里，
（2）年份确认是从oss控制台搜索这个uuid，点进去看更新时间的 = =
一天下来，搞到眼都花，没错，就是看到重影，我以为视力深了好几百度。
话说做这玩意的时候，我弄了个脚本，未写完，但应该可以减少点人工，利用stat命令去找modify的更新时间，注意不是ctime和atime！
## 1、找到900天前数据 find 挂载到服务器的bucket -mtime +900 -type f > /tmp/file_900 keyword1="2018" keyword2="2019" ## 2、判断修改文件更新时间是否有关键字： 2018,2019 cat /tmp/file_900 | while read line do f1=`stat $line |grep Modify |awk '{print $2}'` result1=$(echo $f1 | grep "${keyword1}") result2=$(echo $f1 | grep "${keyword2}") #stat 2c9220dd6884168843aaefa0000/2c9220dd6884168843aaefa0000_856_1.jpg |grep Modify |awk '{print $2}' # 有关键字（2018年） if [ "$result1" != "" ]; then #截取前缀uuid目录名字，然后准备拷贝文件进去，这里开始没写完。。 ml=`echo $line | awk -F'/' '{print $4}'` [ ! -d ${bakdir}/${keyword1} ] && mkdir -p ${bakdir}/${keyword1} # 有关键字（2019年） elif [ "$result2" != "" ]; ml2=`echo $line | awk -F'/' '{print $4}'` [ ! -d ${bakdir}/${keyword2} ] && mkdir -p ${bakdir}/${keyword2} else continue fi …… done
当我发现find这个查找900天前的数据，跑了3个小时才跑完，彻底绝望，因为清理的bucket是2018年底建的，筛选900天前的数据实际上只是很小一部分，这意味着找出来让人头痛，备份再删除更不用说。。。900天前已经放着一坨没规律的海量数据，何况慢慢缩小范围直到找完2020前数据？！
最后下班的时候，告诉领导难处，他说数据库有记录这些考试id（就是上面的uuid），可以找到2019年前的那批uuid，到时直接拉下备份删除，会减少我这个查找工作 = =。而且并不是所有bucket都需要拉下来备份，有些测试能直接干掉，听完感动流涕，
希望明天一片光明。。。。